draft-ietf-nfsv4-federated-fs-protocol-00.txt   draft-ietf-nfsv4-federated-fs-protocol-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: August 24, 2009 D. Ellard
NetApp BBN Technologies
R. Tewari R. Tewari
M. Naik M. Naik
IBM Almaden IBM Almaden
September 26, 2008 February 20, 2009
NSDB Protocol for Federated Filesystems NSDB Protocol for Federated Filesystems
draft-ietf-nfsv4-federated-fs-protocol-00.txt draft-ietf-nfsv4-federated-fs-protocol-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 August 24, 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
(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 document describes a file system federation protocol that This document describes a file system federation protocol that
enables file access and namespace traversal across collections of enables file access and namespace traversal across collections of
independently administered fileservers. The protocol specifies a set independently administered fileservers. The protocol specifies a set
of interfaces by which fileservers and collections of fileservers of interfaces by which fileservers with different administrators can
with different administrators can form a fileserver federation that form a fileserver federation that provides a namespace composed of
provides a namespace composed of the filesystems physically hosted on the filesystems physically hosted on and exported by the constituent
and exported by the constituent fileservers. fileservers.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Protocol Goals . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Protocol Goals . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of Features and Concepts . . . . . . . . . . . . . . 7 3. Overview of Features and Concepts . . . . . . . . . . . . . . 7
3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Fileset and Fileset Name (FSN) . . . . . . . . . . . . . . 7 3.2. Fileset and Fileset Name (FSN) . . . . . . . . . . . . . . 7
3.3. Fileset Location (FSL) . . . . . . . . . . . . . . . . . . 8 3.3. Fileset Location (FSL) . . . . . . . . . . . . . . . . . . 8
3.3.1. Mutual Consistency across Fileset Locations . . . . . 8 3.3.1. Mutual Consistency across Fileset Locations . . . . . 8
3.4. Namespace Database (NSDB) . . . . . . . . . . . . . . . . 9 3.4. Namespace Database (NSDB) . . . . . . . . . . . . . . . . 9
3.5. Mount Points, Junctions and Referrals . . . . . . . . . . 10 3.5. Mount Points, Junctions and Referrals . . . . . . . . . . 10
3.6. Federation Root FileServers . . . . . . . . . . . . . . . 10 3.6. Unified Namespace and the Root Fileset . . . . . . . . . . 10
3.7. Federation Root FileSet . . . . . . . . . . . . . . . . . 11 3.7. Fileservers . . . . . . . . . . . . . . . . . . . . . . . 11
3.8. Fileservers . . . . . . . . . . . . . . . . . . . . . . . 11 3.8. File-access Clients . . . . . . . . . . . . . . . . . . . 11
3.9. File-access Clients . . . . . . . . . . . . . . . . . . . 11
4. Interaction with client protocols . . . . . . . . . . . . . . 12 4. Interaction with client protocols . . . . . . . . . . . . . . 12
4.1. Interaction with NFSv4 . . . . . . . . . . . . . . . . . . 12 4.1. Interaction with NFSv4 and NFSv4.1 . . . . . . . . . . . . 12
4.2. Interaction with other distributed file system 4.2. Interaction with other distributed file system
protocols . . . . . . . . . . . . . . . . . . . . . . . . 12 protocols . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Finding the local NSDB . . . . . . . . . . . . . . . . . . . . 13 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Create a Fileset and its FSL(s) . . . . . . . . . . . . . 13
6.1. Create a Fileset and its FSL(s) . . . . . . . . . . . . . 14 5.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 13
6.1.1. Creating a Fileset and a FSN . . . . . . . . . . . . . 14 5.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 14
6.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 15 5.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 14
6.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 15 5.3. Example use case for fileset annotations . . . . . . . . . 15
6.3. Example use case for fileset annotations . . . . . . . . . 16 6. Mapping the NSDB onto LDAP . . . . . . . . . . . . . . . . . . 16
7. Error Definitions . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Basic LDAP Configuration . . . . . . . . . . . . . . . . . 16
8. Mapping the NSDB onto LDAP . . . . . . . . . . . . . . . . . . 19 6.2. LDAP Attributes . . . . . . . . . . . . . . . . . . . . . 16
8.1. Basic LDAP Configuration . . . . . . . . . . . . . . . . . 19 6.2.1. fedfsUuid . . . . . . . . . . . . . . . . . . . . . . 16
8.2. LDAP Attributes . . . . . . . . . . . . . . . . . . . . . 19 6.2.2. fedfsNetAddr . . . . . . . . . . . . . . . . . . . . . 17
8.2.1. fedfsUuid . . . . . . . . . . . . . . . . . . . . . . 19 6.2.3. fsnUuid . . . . . . . . . . . . . . . . . . . . . . . 17
8.2.2. fedfsNetAddr . . . . . . . . . . . . . . . . . . . . . 20 6.2.4. nsdbName . . . . . . . . . . . . . . . . . . . . . . . 18
8.2.3. fsnUuid . . . . . . . . . . . . . . . . . . . . . . . 20 6.2.5. fslHost . . . . . . . . . . . . . . . . . . . . . . . 18
8.2.4. nsdbName . . . . . . . . . . . . . . . . . . . . . . . 20 6.2.6. fslPath . . . . . . . . . . . . . . . . . . . . . . . 18
8.2.5. fslHost . . . . . . . . . . . . . . . . . . . . . . . 20 6.2.7. fslUuid . . . . . . . . . . . . . . . . . . . . . . . 19
8.2.6. fslPath . . . . . . . . . . . . . . . . . . . . . . . 20 6.2.8. type . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2.7. fslUuid . . . . . . . . . . . . . . . . . . . . . . . 20 6.2.9. currency . . . . . . . . . . . . . . . . . . . . . . . 19
8.2.8. type . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.2.10. info . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.2.9. currency . . . . . . . . . . . . . . . . . . . . . . . 21 6.2.11. annotation . . . . . . . . . . . . . . . . . . . . . . 20
8.2.10. info . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.2.12. childFsnUuid . . . . . . . . . . . . . . . . . . . . . 20
8.2.11. annotation . . . . . . . . . . . . . . . . . . . . . . 21 6.2.13. childNsdbName . . . . . . . . . . . . . . . . . . . . 21
8.2.12. junctionKey . . . . . . . . . . . . . . . . . . . . . 22 6.3. LDAP Objects . . . . . . . . . . . . . . . . . . . . . . . 21
8.2.13. childFsnUuid . . . . . . . . . . . . . . . . . . . . . 22 6.3.1. FsnObject . . . . . . . . . . . . . . . . . . . . . . 21
8.2.14. childNsdbName . . . . . . . . . . . . . . . . . . . . 22 6.3.2. FslObject . . . . . . . . . . . . . . . . . . . . . . 22
8.3. LDAP Objects . . . . . . . . . . . . . . . . . . . . . . . 22 7. NSDB Protocol Operations . . . . . . . . . . . . . . . . . . . 23
8.3.1. FsnObject . . . . . . . . . . . . . . . . . . . . . . 22 7.1. Administrative NSDB Operations . . . . . . . . . . . . . . 23
8.3.2. FslObject . . . . . . . . . . . . . . . . . . . . . . 22 7.1.1. Creating an FSN . . . . . . . . . . . . . . . . . . . 24
8.3.3. JunctionObject . . . . . . . . . . . . . . . . . . . . 23 7.1.2. Deleting an FSN . . . . . . . . . . . . . . . . . . . 25
9. NSDB Protocol Operations . . . . . . . . . . . . . . . . . . . 24 7.1.3. Create an FSL . . . . . . . . . . . . . . . . . . . . 25
9.1. Administrative NSDB Operations . . . . . . . . . . . . . . 24 7.1.4. Delete an FSL . . . . . . . . . . . . . . . . . . . . 26
9.1.1. Creating an FSN . . . . . . . . . . . . . . . . . . . 25 7.1.5. Update an FSL . . . . . . . . . . . . . . . . . . . . 26
9.1.2. Deleting an FSN . . . . . . . . . . . . . . . . . . . 26 7.2. Fileserver to NSDB Operations . . . . . . . . . . . . . . 27
9.1.3. Mount an FSN . . . . . . . . . . . . . . . . . . . . . 26 7.2.1. Looking up FSLs for an FSN . . . . . . . . . . . . . . 27
9.1.4. Unmount an FSN . . . . . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9.1.5. Create an FSL . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9.1.6. Delete an FSL . . . . . . . . . . . . . . . . . . . . 28 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1.7. Update an FSL . . . . . . . . . . . . . . . . . . . . 28 11. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1.8. Finding the children FSNs of a fileset . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.2. Fileserver to NSDB Operations . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . . 34
9.2.1. Looking up FSLs for an FSN . . . . . . . . . . . . . . 29 12.2. Informational References . . . . . . . . . . . . . . . . . 35
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 36
11. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
12. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 33
13. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
14. Normative References . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 40
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 filesystem federation protocol described below allows fileservers
entity. Fileservers may provide proprietary management tools and in from different vendors and/or with different administrators to
some cases an administrator may be able to use the proprietary tools cooperatively build a namespace.
to build a shared namespace out of the exported filesystems. Relying
on vendor-proprietary tools does not work in larger enterprises or The scope of the filesystem federation protocol is currently limited
when collaborating across enterprises because it is likely that the to NFSv4 [RFC3530] or NFSv4.1 [NFSv4.1] capable fileservers. The
system will contain fileservers running different software, each with federation protocols have been designed to accommodate other file
their own interfaces, with no common protocol to manage the namespace access protocols in the future.
or exchange namespace information. There may also be independently-
administered singleton servers that export some or all of their The requirements for federated namespaces are described in
filesystem resources. A filesystem federation protocol enables the [FEDFS-REQTS].
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.
2.1. Protocol Goals 2.1. Protocol Goals
The objective of this draft is to specify a set of interfaces by The objective of this draft is to specify a set of protocols by which
which fileservers and collections of fileservers with different fileservers, possibly with different administrators, can form a
administrators can form a fileserver federation that provides a fileserver federation that provides a namespace composed of the
namespace composed of the filesystems physically hosted on and filesystems physically hosted on and exported by the fileservers of
exported by the fileservers of the federation. It should be the federation. It should be possible, using systems that implement
possible, using a system that implements the interfaces, to share a the federation protocols, to share a common namespace across all the
common namespace across all the fileservers in the federation. It fileservers in the federation. It should also be possible for the
should also be possible for different fileservers in the federation federation to project multiple namespaces and enable clients to
to project different namespaces and enable clients to traverse them. traverse each one. Such a federation may contain an arbitrary number
Such a federation may contain an arbitrary number of namespace of namespace repositories, each belonging to a different
repositories, each belonging to a different administrative entity, administrative entity, and each rendering a part of the namespace.
and each rendering a part of the namespace. Such a federation may Such a federation may also have an arbitrary number of administrative
also have an arbitrary number of administrative entities responsible entities responsible for administering disjoint subsets of the
for administering disjoint subsets of the fileservers. In the rest fileservers. In the rest of the document the term fileserver implies
of the document the term fileserver implies a fileserver that is part a fileserver that is part of the federation.
of the federation. A fileserver not part of the federation is called
an external fileserver.
3. Overview of Features and Concepts 3. Overview of Features and Concepts
3.1. Namespace 3.1. Namespace
The goal of a unified namespace is to make all managed data available The goal of a unified namespace is to make all managed data available
to all clients via the same path in a common filesystem-like to all clients via the same path in a common filesystem-like
namespace. This should be achieved with minimal or zero client namespace. This should be achieved with minimal or zero client
configuration. In particular, updates to the common namespace should configuration. In particular, updates to the common namespace should
not require configuration changes at the client. Filesets, which are not require configuration changes at the client. Filesets, which are
the unit of data management, are a set of files and directories the unit of data management, are a set of files and directories.
accessible from a single mount. Depending on the implementation, From the perspective of the clients, the common namespace is
they may be anything between an individual directory of an exported constructed by mounting filesets that are physically located on
filesystem to an entire exported filesystem at a fileserver. From
the perspective of the clients, the common namespace is constructed
by logically mounting filesets that are physically located on
different fileservers. The namespace, which is defined in terms of different fileservers. The namespace, which is defined in terms of
fileset definitions, fileset identifiers, the location of each fileset definitions, fileset identifiers, the location of each
fileset in the namespace, and the physical location of the fileset in the namespace, and the physical location of the
implementation(s) of each fileset, is stored in a set of namespace implementation(s) of each fileset, is stored in a set of namespace
repositories, each managed by an administrative entity. The repositories, each managed by an administrative entity. The
namespace schema defines the model used for populating, modifying, namespace schema defines the model used for populating, modifying,
and querying the namespace repositories. It is not required by the and querying the namespace repositories. It is not required by the
federation that the namespace be common across all fileservers. It federation that the namespace be common across all fileservers. It
should be possible to have several independently rooted namespaces should be possible to have several independently rooted namespaces.
that should permit traversal into another namespace at defined
junction points.
3.2. Fileset and Fileset Name (FSN) 3.2. Fileset and Fileset Name (FSN)
A fileset is defined to be a container of data and is the basic unit A fileset is defined to be a container of data and is the basic unit
of data management. It is uniquely represented by the fileset name of data management. Depending on the implementation, they may be
(FSN). An FSN is considered unique across the federation. An FSN anything between an individual directory of an exported filesystem to
contains information sufficient to locate the namespace database an entire exported filesystem at a fileserver. A fileset is uniquely
(NSDB) that holds authoritative information about it and an represented by its fileset name (FSN). An FSN is considered unique
identifier, called fsn_uuid, that identifies it on that NSDB. After across the federation. An FSN contains information sufficient to
an FSN is created, it is associated with a fileset location (FSL) on locate the namespace database (NSDB) that holds authoritative
a fileserver. A fileset can be implemented by one or more FSLs. The information about it and an identifier, called the FsnUuid, that
attributes of an FSN are: identifies it on that NSDB. After an FSN is created, it is
associated with a fileset location (FSL) on a fileserver. A fileset
can be implemented by one or more FSLs. The attributes of an FSN
are:
NsdbName: the fully qualified domain name of an NSDB location that NsdbName: the fully qualified domain name of an NSDB location that
contains authoritative information for this FSN. contains authoritative information for this FSN.
FsnUuid: a 128-bit UUID (universally unique identifier), conforming FsnUuid: a 128-bit UUID (universally unique identifier), conforming
to [RFC4122], that is used to uniquely identify an FSN. An NSDB to [RFC4122], that is used to uniquely identify an FSN. An NSDB
SHOULD ensure that no two FSNs it stores have the same FsnUuid. SHOULD ensure that no two FSNs it stores have the same FsnUuid.
3.3. Fileset Location (FSL) 3.3. Fileset Location (FSL)
An FSL represents the location where the fileset data resides. Each An FSL represents the location where the fileset data resides. Each
FSL contains a host:path pair on a file server. An FSL may also have FSL contains a host:path pair on a file server. An FSL may also have
additional attributes. Each location has an associated type that additional attributes. Each location has an associated type that
determines the protocol(s) that may be used to access its data. Type determines the protocol(s) that may be used to access its data. Type
information can be used to decide the list of locations that will be information can be used to decide the list of locations that will be
returned to the client. Other attributes associated with an FSL are returned to the client. Other attributes associated with an FSL are
based on the NFSv4.1 fs_locations_info attribute[RFCTBD]. based on the NFSv4.1 fs_locations_info attribute [NFSv4.1].
Each FSL consists of: Each FSL consists of:
FslHost: the fully qualified domain name of the host fileserver FslHost: the fully qualified domain name of the host fileserver
storing the physical data storing the physical data
FslPathname: the exported pathname at that host fileserver FslPathname: the exported pathname at that host fileserver
FslUuid: the 128-bit UUID of the FSL FslUuid: the 128-bit UUID of the FSL
Type: the protocol that should be used to access this FSL (e.g. Type: the protocol that should be used to access this FSL (e.g.
NFSv4) NFSv4 or NFSv4.1)
Currency: the time lag of this FSL represented as the number of time Currency: the time lag of this FSL represented as the number of time
units it lags the latest version as defined by the NFSv4.1 units it lags the latest version as defined by the NFSv4.1
fs_locations_server's fls_currency field. A currency value of 0 fs_locations_server's fls_currency field. A currency value of 0
represents the latest version. Currency values are less than or represents the latest version. Currency values are less than or
equal to zero equal to zero
Info: as defined in the NFSv4.1 fs_locations_info attribute Info: as defined in the NFSv4.1 fs_locations_info attribute
Annotations: a list of name/value pairs that can be interpreted by a Annotations: a list of name/value pairs that can be interpreted by a
skipping to change at page 9, line 20 skipping to change at page 9, line 20
location while another is directed to a different location. Since location while another is directed to a different location. Since
updates to each fileset location are not controlled by the federation updates to each fileset location are not controlled by the federation
protocol, it is the responsibility of administrators to guarantee the protocol, it is the responsibility of administrators to guarantee the
functional equivalence of the data. functional equivalence of the data.
The federation protocol does not guarantee that the different The federation protocol does not guarantee that the different
locations are mutually consistent in terms of the currency of the locations are mutually consistent in terms of the currency of the
data. It relies on the client file-access protocol (i.e., NFSv4) to data. It relies on the client file-access protocol (i.e., NFSv4) to
contain sufficient information to help the clients determine the contain sufficient information to help the clients determine the
currency of the data at each location in order to ensure that the currency of the data at each location in order to ensure that the
clients do not revert back in time when switching locations. This clients do not revert back in time when switching locations.
raises a concern for NFSv3 fileservers, which the federation protocol
may support, that may lack such control.
3.4. Namespace Database (NSDB) 3.4. Namespace Database (NSDB)
The NSDB service is a federation-wide service that provides The NSDB service is a federation-wide service that provides
interfaces to define, update, and query FSN information and FSN to interfaces to define, update, and query FSN information and FSN to
FSL mapping information. An individual repository of namespace FSL mapping information. An individual repository of namespace
information is called an NSDB location. Each NSDB location is information is called an NSDB location. Each NSDB location is
managed by a single administrative entity. A single admin entity can managed by a single administrative entity. A single admin entity can
manage multiple NSDB locations. manage multiple NSDB locations.
The difference between the NSDB service and an NSDB location is The difference between the NSDB service and an NSDB location is
analogous to that between the DNS service and a particular DNS analogous to that between the DNS service and a particular DNS
server. server.
The term local NSDB is shorthand for an NSDB location that is known a
priori to a server. It is typically located within the same
federation member as the server, but this is not required. A local
NSDB is not required.
Each NSDB location stores the definition of the FSNs for which it is Each NSDB location stores the definition of the FSNs for which it is
authoritative. It also stores the definitions of the FSLs associated authoritative. It also stores the definitions of the FSLs associated
with those FSNs. An NSDB location is authoritative for the filesets with those FSNs. An NSDB location is authoritative for the filesets
that it defines. An NSDB location can cache information from a peer that it defines. An NSDB location can cache information from a peer
NSDB location. The fileserver can always contact a local NSDB NSDB location. The fileserver can always contact a local NSDB
location (if it has been defined) or directly contact any NSDB location (if it has been defined) or directly contact any NSDB
location to resolve a junction. Each NSDB location supports an LDAP location to resolve a junction. Each NSDB location supports an LDAP
interface and can be accessed by an LDAP client. [RFC4510] interface and can be accessed by an LDAP client.
An NSDB may be replicated throught the federation. The mechanism by An NSDB MAY be replicated throughout the federation. If an NSDB is
which this is acheived is outside the scope of this document. Many replicated, the NSDB MUST exhibit loose, converging consistency as
LDAP implementations support replication. These features MAY be used defined in [RFC3254]. The mechanism by which this is achieved is
to replicate the NSDB. outside the scope of this document. Many LDAP implementations
support replication. These features MAY be used to replicate the
NSDB.
3.5. Mount Points, Junctions and Referrals 3.5. Mount Points, Junctions and Referrals
A mount point is a directory in a parent fileset where a target A mount point is a directory in a parent fileset where a target
fileset may be attached. If a client traverses the path leading from fileset may be attached. If a client traverses the path leading from
the root of the namespace to the mount point of a target fileset it the root of the namespace to the mount point of a target fileset it
should be able to access the data in that target fileset (assuming should be able to access the data in that target fileset (assuming
appropriate permissions). appropriate permissions).
The directory where a fileset is mounted is represented by a junction The directory where a fileset is mounted is represented by a junction
skipping to change at page 10, line 29 skipping to change at page 10, line 26
the target fileset. A junction can be implemented as a special the target fileset. A junction can be implemented as a special
marker on a directory that is interpreted by the fileserver as a marker on a directory that is interpreted by the fileserver as a
mount point, or by some other mechanism in the underlying file mount point, or by some other mechanism in the underlying file
system. system.
What data is used by the underlying file system to represent the What data is used by the underlying file system to represent the
junction is not defined by this protocol. The essential property is junction is not defined by this protocol. The essential property is
that the server must be able to find, given the junction, the FSN for that the server must be able to find, given the junction, the FSN for
the target fileset. The mechanism by which the server maps a the target fileset. The mechanism by which the server maps a
junction to an FSN is outside the scope of this document. The FSN junction to an FSN is outside the scope of this document. The FSN
(as described earlier) contains both the NSDB location of the (as described earlier) contains both the the authoritative NSDB
authoritative NSDB location and the FsnUuid (a UUID for the fileset). location and the FsnUuid (a UUID for the fileset).
When a client traversal reaches a junction, the client is referred to When a client traversal reaches a junction, the client is referred to
a list of FSLs associated with the FSN that was the target of the a list of FSLs associated with the FSN that was the target of the
junction. The client can then redirect its connection to one of the junction. The client can then redirect its connection to one of the
FSLs. This act is called a referral. For NFSv4 clients, the FSL FSLs. This act is called a referral. For NFSv4 clients, the FSL
information is returned in the fs_locations or fs_locations_info information is returned in the fs_locations or fs_locations_info
attributes. attributes.
The federation-fs interfaces do not limit where and how many times a The federation protocols do not limit where and how many times a
fileset is mounted in the namespace. Filesets can be nested -- a fileset is mounted in the namespace. Filesets can be nested; a
fileset can be mounted under another fileset. fileset can be mounted under another fileset.
3.6. Federation Root FileServers 3.6. Unified Namespace and the Root Fileset
A set of designated fileservers that render the common federation-
wide namespace are called the federation root fileservers. The
federation protocol does not mandate that federation root fileservers
be defined. When a client mounts the root of the namespace from a
root fileserver it can traverse the entire federation-wide namespace.
It is not required for a client to mount from one of the root
fileservers. If a client mounts from a non-root fileserver then it
can traverse the part of the namespace that is visible starting from
that fileserver. A client can mount multiple individual filesets
from multiple non-root fileservers and chose to navigate the
namespace in any manner. How the client discovers the root
fileserver(s), if one is defined, is not in the scope of the
federation protocol. Numerous external techniques such as DNS SRV
records can be used for this.
3.7. Federation Root FileSet
The root fileset is the optional, top-level fileset of the The root fileset, when defined, is the top-level fileset of the
federation-wide namespace. The root of the namespace is the top federation-wide namespace. The root of the unified namespace is the
level directory of this fileset. The fileset can contain an top level directory of this fileset. A set of designated fileservers
arbitrary number of virtual directories. The leaf directories of the in the federation can export the root fileset to render the
root fileset serve as the mount points for other filesets. It is federation-wide unified namespace. When a client mounts the root
desirable that the leaf directories not contain data. The root fileset from any of these designated fileservers it can view a common
fileset is a simple combination of internal nodes and leaf nodes federation-wide namespace. The properties and schema definition of
where each leaf node is a junction to a target fileset. The root the root fileset and the protocol details that describe how to
fileset is replicated at all the root fileservers. The recommended configure and replicate the root fileset are available in a companion
replication protocols for root fileset replication are: an external draft [To be Published].
protocol such as rsync or NDMP.
3.8. Fileservers 3.7. Fileservers
Fileservers are NFSv4 servers that store the physical fileset data or Fileservers are NFSv4 or NFSv4.1 servers that store the physical
fileservers that refer the client to other fileservers. fileset data or fileservers that refer the client to other
fileservers. A fileserver can be implemented in a number of
different ways, including a single system, a cluster of systems, or
some other configuration.
3.9. File-access Clients 3.8. File-access Clients
File access clients are standard off-the-shelf NAS clients that File access clients are standard off-the-shelf NAS clients that
access file data using the NFSv4 protocol or some other protocol. access file data using the NFSv4 protocol, the NFSv4.1 protocol, or
some other protocol.
4. Interaction with client protocols 4. Interaction with client protocols
4.1. Interaction with NFSv4 4.1. Interaction with NFSv4 and NFSv4.1
The federation protocol is compatible with the requirements of NFSv4 The federation protocol is compatible with the requirements of NFSv4
referral mechanisms as defined in [RFC3530]. referral mechanisms as defined in [RFC3530] and the NFSv4.1 referral
mechanisms as defined in [NFSv4.1].
4.2. Interaction with other distributed file system protocols 4.2. Interaction with other distributed file system protocols
The federation protocol does not mandate a specific format for The federation protocol does not mandate a specific format for
pathnames. Therefore it is possible to store the pathnames used by a pathnames. Therefore it is possible to store the pathnames used by a
variety of distributed file systems, including CIFS. variety of distributed file systems, including CIFS.
5. Finding the local NSDB 5. Examples
The fed-fs protocol does not mandate how and if a local NSDB is
defined or located. A fileserver's local NSDB configuration could be
specified using a simple text file or some other mechanism.
6. Examples
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.
6.1. Create a Fileset and its FSL(s) 5.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 14, line 36 skipping to change at page 13, 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.
6.1.1. Creating a Fileset and a FSN 5.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 UUID is choosen by the administrator or generated The FSN UUID is chosen by the administrator or generated
automatically by administration software. The former case is automatically by administration software. The former case is
used if the fileset is being restored, perhaps as part of used if the fileset is being restored, perhaps as part of
disaster recovery, and the administrator wishes to specify the disaster recovery, and the administrator wishes to specify the
FSN UUID in order to permit existing junctions that reference FSN UUID in order to permit existing junctions that reference
that FSN to work again. that FSN to work again.
At this point, the FSN exists, but its fileset locations are At this point, the FSN exists, but its fileset locations are
unspecified. unspecified.
3. Send the FSN, the hostname, the export path, the type, the 3. Send the FSN, the hostname, the export path, the type, the
currency, info, and annotations for the fileset to the NSDB node. currency, info, and annotations for the fileset to the NSDB node.
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.
6.1.2. Adding a Replica of a Fileset 5.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 interface
required is the ability to register or remove the registration of required is the ability to register or remove the registration of
replicas for a fileset. replicas for a fileset.
6.2. Junction Resolution 5.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. 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.3. Example use case for fileset annotations 5.3. Example use case for fileset annotations
The fileset annotations can be used to define relationships between The fileset annotations can be used to define relationships between
filesets that can be used by an auxiliary replication protocol. filesets that can be used by an auxiliary replication protocol.
Consider the scenario where a fileset is created and mounted at some Consider the scenario where a fileset is created and mounted at some
point in the namespace. A snapshot of the read-write FSL of that point in the namespace. A snapshot of the read-write FSL of that
fileset is taken periodically at different frequencies say a daily fileset is taken periodically at different frequencies say a daily
snapshot or a weekly snapshot. The different snapshots are mounted snapshot or a weekly snapshot. The different snapshots are mounted
at different locations in the namespace. The daily snapshots are at different locations in the namespace. The daily snapshots are
considered as a different fileset from the weekly ones but both are considered as a different fileset from the weekly ones but both are
related to the source fileset. For this we can define an annotation related to the source fileset. For this we can define an annotation
skipping to change at page 17, line 5 skipping to change at page 16, line 5
write. write.
This follows the traditional AFS model of mounting the read-only This follows the traditional AFS model of mounting the read-only
volume at a path in the namespace different from that of the read- volume at a path in the namespace different from that of the read-
write volume. write volume.
The federation protocol does not control or manage the relationship The federation protocol does not control or manage the relationship
among filesets. It merely enables annotating the filesets with user- among filesets. It merely enables annotating the filesets with user-
defined relationships. defined relationships.
7. Error Definitions 6. Mapping the NSDB onto LDAP
ERR_OK Indicates the operation completed successfully.
ERR_ACCESS Permission denied. The caller does not have the correct
permission to perform the requested operation. Contrast this with
ERR_PERM, which restricts itself to owner or privileged user
permission failures.
ERR_BADCHAR A UTF-8 string contains a character which is not
supported in the context in which it being used.
ERR_BADNAME A name string in a request consists of valid UTF-8
characters supported by the server but the name is not supported
by the server as a valid name for current operation.
ERR_BADTYPE An attempt was made to create an object of a type not
supported by the server.
ERR_DENIED An attempt to lock a file is denied. Since this may be a
temporary condition, the client is encouraged to retry the lock
request until the lock is accepted.
ERR_EXIST Object exists. The object specified already exists.
ERR_INVALID Invalid argument or unsupported argument for an
operation.
ERR_IO I/O error. A hard error (for example, a disk error) occurred
while processing the requested operation.
ERR_NAMETOOLONG The filename in an operation was too long.
ERR_NOENT No such object. The object being accessed does not exist.
ERR_NOTDIR Not a directory. The caller specified a non- directory
in a directory operation.
ERR_NOTEMPTY An attempt was made to remove an object that was not
empty. An FSN which has FSLs still defined for it.
ERR_NOTSUPP Operation is not supported.
ERR_PERM Not owner. The operation was not allowed because the
caller is either not a privileged user (root) or not the owner of
the target of the operation.
ERR_WRONGSEC The security mechanism being used by the client for the
operation does not match the server's security policy. The client
should change the security mechanism being used and retry the
operation.
ERR_WRONGNSDB The NSDB location is not the one to be used for this
operation.
8. Mapping the NSDB onto LDAP
This section describes the LDAP schema used to define the LDAP This section describes the LDAP schema used to define the LDAP
implementation of the NSDB service. The first part of the section implementation of the NSDB service. The first part of the section
describes the basic properties of the LDAP configuration that MUST be describes the basic properties of the LDAP configuration that MUST be
used in order to ensure compatibility between different used in order to ensure compatibility between different
implementations. The second section defines the new LDAP attribute implementations. The second section defines the new LDAP attribute
types and the subsequent sections describe the new object types and types and the subsequent sections describe the new object types and
specify how the distinguished name (DN) of each object instance MUST specify how the distinguished name (DN) of each object instance MUST
be constructed. be constructed.
8.1. Basic LDAP Configuration 6.1. Basic LDAP Configuration
The base name (or suffix) for all DNs used by the NSDB schema is The base name (or suffix) for all DNs used by the NSDB schema is
"dc=fed-fs,dc=com". "dc=fed-fs,dc=com".
The DN of the priviledged LDAP user is, by convention, The DN of the privileged LDAP user is, by convention,
"cn=admin,dc=fed-fs,dc=com". This user is able to modify the "cn=admin,dc=fed-fs,dc=com". This user is able to modify the
contents of the LDAP database. It is permitted to use a different DN contents of the LDAP database. It is permitted to use a different DN
(or add additional priviledged users) but if a different DN is used (or add additional privileged users) but if a different DN is used
then every admin entity that needs to modify the contents of the then every admin entity that needs to modify the contents of the
database or view privilidged information must be made aware of the database or view privileged information must be made aware of the new
new DN. DN.
It MUST be possible for the anonymous (unauthenticated) user to It MUST be possible for the anonymous (unauthenticated) user to
perform LDAP queries that access the NSDB data. perform LDAP queries that access the NSDB data.
All implementations SHOULD use the same schema, or, at minimum, a All implementations SHOULD use the same schema, or, at minimum, a
schema that includes all of the objects, with each of the attributes, schema that includes all of the objects, with each of the attributes,
named in the following sections. named in the following sections.
8.2. LDAP Attributes 6.2. LDAP Attributes
This section describes the required attributes of the NSDB LDAP This section describes the required attributes of the NSDB LDAP
schema. schema.
8.2.1. fedfsUuid 6.2.1. fedfsUuid
A fedfsUuid is the base type for all of the universally unique A fedfsUuid is the base type for all of the universally unique
identifiers (UUIDs) used by the federated file system protocols. identifiers (UUIDs) used by the federated file system protocols.
This SHOULD be defined in terms of the text representation of the This SHOULD be defined in terms of the text representation of the
standard UUID (as defined in [RFC4122]). standard UUID (as defined in [RFC4122]).
It MAY also be useful, for purposes of debugging or annotation, to It MAY also be useful, for purposes of debugging or annotation, to
permit a fedfsUuid to include members of a more general class of permit a fedfsUuid to include members of a more general class of
strings. strings.
A fedfsUuid is a single-valued LDAP attribute. A fedfsUuid is a single-valued LDAP attribute. It is formally
defined as follows:
8.2.2. fedfsNetAddr attributetype (
1.3.6.1.4.1.31103.1.1 NAME 'fedfsUuid'
DESC 'a UUID used by NSDB'
SUP name
SINGLE-VALUE )
6.2.2. fedfsNetAddr
A fedfsNetAddr is the locative name of a network service. It MUST be A fedfsNetAddr is the locative name of a network service. It MUST be
able to express network locations as IPv4, IPv6, and DNS FQDN a UTF-8 string and represent a network location in either IPv4, IPv6,
notations. It may include a port specifier, or the port may be or DNS host name notation. The format is the same as that specified
implicit in context. for an fs_location4's server array elements in section 11.9 of
[NFSv4.1].
There MAY be a special syntax at some point for specifying a SVR This attribute is single-valued. It is formally defined as follows:
record (for a DNS FQDN).
This attribute is single-valued. attributetype (
1.3.6.1.4.1.31103.1.2 NAME 'fedfsNetAddr'
DESC 'a network name of a host or service'
SUP name
SINGLE-VALUE )
8.2.3. fsnUuid 6.2.3. fsnUuid
A fsnUuid represents the fsnUuid component of an FSN. A fsnUuid represents the fsnUuid component of an FSN.
The fsnUuid is a subclass of fedfsUuid. The fsnUuid is a subclass of fedfsUuid.
This attribute is single-valued. This attribute is single-valued.
8.2.4. nsdbName attributetype (
1.3.6.1.4.1.31103.1.3 NAME 'fsnUuid'
DESC 'the FSN UUID component of an FSN'
SUP fedfsUuid
SINGLE-VALUE )
A nsdbName is the NSDB component of an FSN. 6.2.4. nsdbName
An nsdbName is the NSDB component of an FSN.
The nsdbName attribute is a subclass of fedfsNetAddr. The nsdbName attribute is a subclass of fedfsNetAddr.
This attribute is single-valued. This attribute is single-valued.
8.2.5. fslHost attributetype (
1.3.6.1.4.1.31103.1.4 NAME 'nsdbName'
DESC 'the NSDB location component of an FSN'
SUP fedfsNetAddr
SINGLE-VALUE )
A fslHost is the hostname/port component of an FSL. 6.2.5. fslHost
An fslHost is the hostname/port component of an FSL.
The fslHost attribute is a subclass of fedfsNetAddr. The fslHost attribute is a subclass of fedfsNetAddr.
This attribute is single-valued. This attribute is single-valued.
8.2.6. fslPath attributetype (
1.3.6.1.4.1.31103.1.5 NAME 'fslHost'
DESC 'service location for a fileset server'
SUP fedfsNetAddr
SINGLE-VALUE )
6.2.6. fslPath
The path component of an FSL. The path component of an FSL.
This attribute is single-valued. This attribute is single-valued.
8.2.7. fslUuid attributetype (
1.3.6.1.4.1.31103.1.6 NAME 'fslPath'
DESC 'server-local path to a fileset'
SUP name
SINGLE-VALUE )
6.2.7. fslUuid
Each FSL must have a UUID associated with it, which serves as part of Each FSL must have a UUID associated with it, which serves as part of
its DN. its DN.
The fslUuid attribute is a subclass of fedfsUuid. The fslUuid attribute is a subclass of fedfsUuid.
This attribute is single-valued. This attribute is single-valued.
8.2.8. type attributetype (
1.3.6.1.4.1.31103.1.7 NAME 'fslUuid'
DESC 'UUID of an FSL'
SUP fedfsUuid
SINGLE-VALUE )
6.2.8. type
The type of an FSL. The type of an FSL.
This attribute is used to specify the distribute file system protocol This attribute is used to specify the distribute file system protocol
that can be used to access an FSL. The following values are defined that can be used to access an FSL. The following values are defined
for this field: for this field:
nfsv4 : the FSL is accessible via the NFSv4 protocol. nfsv4 : the FSL is accessible via the NFSv4 protocol.
Values for other protocols may be defined at a later time. Values for other protocols may be defined at a later time.
This attribute is single-valued. This attribute is single-valued.
8.2.9. currency attributetype (
1.3.6.1.4.1.31103.1.8 NAME 'type'
DESC 'CIFS, NFS, etc'
SUP name )
6.2.9. currency
The currency of an FSL. The currency of an FSL.
This attribute is used to populate the NFSv4.1 fs_locations_info's This attribute is used to populate the NFSv4.1 fs_locations_info's
currency field. currency field.
This attribute is single-valued. This attribute is single-valued.
8.2.10. info attributetype (
1.3.6.1.4.1.31103.1.9 NAME 'currency'
DESC 'up-to-date measure of the data'
SUP name )
6.2.10. info
Information about the FSL. Information about the FSL.
This attribute is used to populate the NFSv4.1 fs_locations_info's This attribute is used to populate the NFSv4.1 fs_locations_info's
info field. info field.
This attribute is single-valued. This attribute is single-valued.
8.2.11. annotation attributetype (
1.3.6.1.4.1.31103.1.10 NAME 'info'
DESC 'information about the file system'
SUP name )
6.2.11. annotation
An annotation of an NSDB object. An annotation of an NSDB object.
This attribute is multi-valued; an object type that permits This attribute is multi-valued; an object type that permits
annotations may have any number of annotations per instance. annotations may have any number of annotations per instance.
This attribute is a placeholder; it has not been well-defined at the attributetype (
date of this draft. 1.3.6.1.4.1.31103.1.11 NAME 'annotation'
DESC 'annotation of an NSDB object'
8.2.12. junctionKey SUP name )
Each junction has a unique junctionKey that is used to distinguish it
from other junctions that may refer to the same child fileset and/or
appear within the same parent fileset.
The junctionKey attribute is a subclass of fedfsUuid.
This attribute is single-valued.
8.2.13. childFsnUuid 6.2.12. childFsnUuid
The fsnUuid of the target of a junction. The fsnUuid of the target of a junction.
The childFsnUuid attribute is a subclass of fsnUuid. The childFsnUuid attribute is a subclass of fsnUuid.
This attribute is single-valued. This attribute is single-valued.
8.2.14. childNsdbName attributetype (
1.3.6.1.4.1.31103.1.12 NAME 'childFsnUuid'
DESC 'the fsnUuid of a Junction's target'
SUP fsnUuid
SINGLE-VALUE )
6.2.13. childNsdbName
The nsdbName of the target of a junction. The nsdbName of the target of a junction.
The childNsdbName attribute is a subclass of nsdbName. The childNsdbName attribute is a subclass of nsdbName.
This attribute is single-valued. This attribute is single-valued.
8.3. LDAP Objects attributetype (
1.3.6.1.4.1.31103.1.13 NAME 'childNsdbName'
DESC 'the nsdbName of a Junction's target'
SUP nsdbName
SINGLE-VALUE )
8.3.1. FsnObject 6.3. LDAP Objects
6.3.1. FsnObject
An FsnObject represents an FSN. An FsnObject represents an FSN.
The required attributes of an FsnObject are an nsdbName and fsnUuid. The required attributes of an FsnObject are an nsdbName and fsnUuid.
The DN of an FSN is assumed to take the following form: The DN of an FSN is assumed to take the following form:
"fsnUuid=FSNUUID,dc=fed-fs,dc=com", where fsnUuid is the UUID of the "fsnUuid=FSNUUID,dc=fed-fs,dc=com", where fsnUuid is the UUID of the
FSN. FSN.
An FsnObject MAY also have additional attributes, but these An FsnObject MAY also have additional attributes, but these
attributes MUST NOT be referenced by any part of this draft. attributes MUST NOT be referenced by any part of this draft.
8.3.2. FslObject objectclass (
1.3.6.1.4.1.31103.1.1001 NAME 'FsnObject'
DESC 'Representing a Fed-fs Fileset'
SUP top STRUCTURAL
MUST (
fsnUuid
$ nsdbName
)
MAY (
descr
$ annotation
))
6.3.2. FslObject
An FslObject represents an FSL. An FslObject represents an FSL.
The required attributes of an FslObject are an nsdbName, fsnUuid, The required attributes of an FslObject are an nsdbName, fsnUuid,
fslHost, fslPath, fslUuid, type, currency, info, and annotations. fslHost, fslPath, fslUuid, type, currency, info, and annotations.
An FslObject's currency and annotations attributes MAY be null. An FslObject's currency and annotations attributes MAY be null.
The DN of an FSL is required to take the following form: The DN of an FSL is required to take the following form:
"fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com". "fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com".
To find all the FSLs that match a given FSN, query for the children To find all the FSLs that match a given FSN, query for the children
of the object with DN "fsnUuid=FSNUUID,dc=fed-fs,dc=com" with a of the object with DN "fsnUuid=FSNUUID,dc=fed-fs,dc=com" with a
filter for "objectType = fslObject". (If you want to be doubly filter for "objectType = fslObject". (If you want to be doubly
careful, you can also filter by the nsdbName.) careful, you can also filter by the nsdbName.)
8.3.3. JunctionObject objectclass (
1.3.6.1.4.1.31103.1.1002 NAME 'FslObject'
An JunctionObject captures the relationship between a fileset and its DESC 'A physical instance of a fileset'
children (if any). The children FSNs are FSNs that appear in SUP fsnObject STRUCTURAL
junctions in the fileset named by the fsnUuid and nsdbName attributes MUST (
of the parent FSN. fsnUuid
$ nsdbName
The required attributes of a JunctionObject are a junctionKey, $ fslHost
fsnUuid, nsdbName, childFsnUuid, and childNsdbName. $ fslPath
$ fslUuid
A JunctionObject MAY also have descr and annotation attributes, but )
neither is required. MAY (
descr
The required form of a DN for an JunctionObject is: $ annotation
"junctionKey=KEY,fsnUuid=FSNUUID,dc=fed-fs,dc=com" where KEY is a ))
unique key chosen for this relationship (the junctionKey) and FSNUUID
is the fsnUuid of the parent fileset's FSN.
Note that the reason why KEY might be something other than simply the
fsnUuid of the child's FSN is that a child FSN may appear as the
target of several junctions within the same fileset, and we must have
a way to distinguish each of these junctions.
To find all the junctions within a given fileset, query for the
children of the object with DN "fsnUuid=FSNUUID,dc=fed-fs,dc=com" and
filter for "objectType = JunctionObject". (If you want to be doubly
careful, you can also filter by the nsdbName.)
9. NSDB Protocol Operations 7. NSDB Protocol Operations
The operations defined by the protocol can be described as several The operations defined by the protocol can be described as several
sub-protocols that are used by entities within the federation to sub-protocols that are used by entities within the federation to
perform different roles. perform different roles.
The first of these sub-protocols defines how the state of an NSDB The first of these sub-protocols defines how the state of an NSDB
location can be initialized and updated. The primary use of this location can be initialized and updated. The primary use of this
sub-protocol is by an administrator to add, edit, or delete filesets, sub-protocol is by an administrator to add, edit, or delete filesets,
their properties, and their fileset locations. their properties, and their fileset locations.
skipping to change at page 24, line 42 skipping to change at page 23, line 42
The NSDB sub-protocols are defined in the next two sub-sections. The NSDB sub-protocols are defined in the next two sub-sections.
The third sub-protocol defines the queries or other requests that are The third sub-protocol defines the queries or other requests that are
sent to a fileset server in order to get information from it or to sent to a fileset server in order to get information from it or to
modify the state of the fileset server in a manner related to the modify the state of the fileset server in a manner related to the
federation protocols. The primary purpose of this protocol is for an federation protocols. The primary purpose of this protocol is for an
administrator to create or delete a junction or fileset or discover administrator to create or delete a junction or fileset or discover
related information about a particular fileset server. related information about a particular fileset server.
The third sub-protocol is defined as ONC/RPC operations. The reason The third sub-protocol is defined as ONC RPC operations. The reason
for using a different RPC mechanism (instead of mapping these for using a different RPC mechanism (instead of mapping these
operations onto LDAP) is to minimize the changes required to the operations onto LDAP) is to minimize the changes required to the
fileset server. This protocol is described in a separate document. fileset server.
9.1. Administrative NSDB Operations The ONC RPC administration protocol is defined in [FEDFS-ADMIN].
7.1. Administrative NSDB Operations
The admin entity initiates and controls the commands to manage The admin entity initiates and controls the commands to manage
fileset and namespace information. The admin entity, however, is fileset and namespace information. The admin entity, however, is
stateless. All state is maintained at the NSDB locations or at the stateless. All state is maintained at the NSDB locations or at the
fileserver. fileserver.
We require that each NSDB location be able to act as an LDAP server We require that each NSDB location be able to act as an LDAP server
and that the protocol used for communicating between the admin entity and that the protocol used for communicating between the admin entity
and each NSDB is LDAP. and each NSDB is LDAP.
skipping to change at page 25, line 20 skipping to change at page 24, line 22
of exposition in this document, and are not part of the LDAP dialogs. of exposition in this document, and are not part of the LDAP dialogs.
In the description of the LDAP messages and LDIF, we use the In the description of the LDAP messages and LDIF, we use the
following notation: constant strings and literal names are specified following notation: constant strings and literal names are specified
in lower or mixed case, while variables or values are specified in in lower or mixed case, while variables or values are specified in
uppercase. One important exception to this rule is that the names of uppercase. One important exception to this rule is that the names of
the error codes follow the convention (used widely in other the error codes follow the convention (used widely in other
protocols, including NFS) of having names that are entirely protocols, including NFS) of having names that are entirely
uppercase. uppercase.
NEED TO UPDATE THE TEXT HERE TO REFER TO THE OTHER DRAFT. -DJE 7.1.1. Creating an FSN
9.1.1. Creating an FSN
The administrator uses this operation to create a new FSN by The administrator uses this operation to create a new FSN by
requesting the NSDB to create a new FsnObject in its LDAP database requesting the NSDB to create a new FsnObject in its LDAP database
with an fsnUuid of FSNUUID and an NsdbName of NSDB. with an fsnUuid of FSNUUID and an NsdbName of NSDB.
The NSDB location that receives the request SHOULD check that the The NSDB location that receives the request SHOULD check that the
NSDB matches its own value and return an ERR_WRONGNSDB error if it NSDB matches its own value and return an error if it does not. This
does not. This is to ensure that an FSN is always created by the is to ensure that an FSN is always created by the NSDB location
NSDB location encoded within the FSN as its owner. encoded within the FSN as its owner.
The NSDB location that receives the request SHOULD check all of the The NSDB location that receives the request SHOULD check all of the
attributes for validity and consistency, but this is not generally attributes for validity and consistency, but this is not generally
possible for LDAP servers because the consistency requirements cannot possible for LDAP servers because the consistency requirements cannot
be expressed in the LDAP schema (although many LDAP servers can be be expressed in the LDAP schema (although many LDAP servers can be
extended, via plug-ins or other mechanisms, to add functionality extended, via plug-ins or other mechanisms, to add functionality
beyond the strict definition of LDAP). beyond the strict definition of LDAP).
PARAGRAPH DESCRIBING ERRORS 7.1.1.1. LDAP Request
9.1.1.1. LDAP Request
The admin chooses the fsnUuid and NsdbName of the FSN. The fsnUuid The admin chooses the fsnUuid and NsdbName of the FSN. The fsnUuid
is a UUID and should be chosen via a standard process for creating a is a UUID and should be chosen via a standard process for creating a
UUID (described in [RFC4122]). The NsdbName is the name of the NSDB UUID (described in [RFC4122]). The NsdbName is the name of the NSDB
location that will serve as the source of definitive information location that will serve as the source of definitive information
about an FSN for the life of that FSN. In the example below, the about an FSN for the life of that FSN. In the example below, the
admin server chooses a fsnUuid of FSNUUID and the NsdbName of NSDB admin server chooses a fsnUuid of FSNUUID and the NsdbName of NSDB
and then sends an LDAP ADD request, described by the LDIF below, to and then sends an LDAP ADD request, described by the LDIF below, to
the NSDB location NSDB. This will create a new FsnObject on that the NSDB location NSDB. This will create a new FsnObject on that
NSDB location with the given attributes in the LDAP database. NSDB location with the given attributes in the LDAP database.
dn: fsnUuid=FSNUUID,dc=fed-fs,dc=com dn: fsnUuid=FSNUUID,dc=fed-fs,dc=com
changeType: add changeType: add
objectClass: FsnObject objectClass: FsnObject
fsnUuid: FSNUUID fsnUuid: FSNUUID
nsdbName: NSDB nsdbName: NSDB
9.1.2. Deleting an FSN 7.1.2. Deleting an FSN
Deletes the given fileset name. This assumes that all the FSLs Deletes the given fileset name. This assumes that all the FSLs
related to that FSN have already been deleted. If FSL records for related to that FSN have already been deleted. If FSL records for
this FSN still exist in the database of the NSDB that receives this this FSN still exist in the database of the NSDB that receives this
request, then this function MUST return with an ERR_NOTEMPTY error. request, then this function MUST return an error.
Note that the FSN delete function only removes the fileset from the Note that the FSN delete function only removes the fileset from the
namespace (by removing the records for that FSN from the NSDB namespace (by removing the records for that FSN from the NSDB
location that receives this request). The fileset and its data are location that receives this request). The fileset and its data are
not deleted. Any junction that has this FSN as its target may not deleted. Any junction that has this FSN as its target may
continue to point to this non-existent FSN. A dangling reference may continue to point to this non-existent FSN. A dangling reference may
be detected when a client tries to resolve the target of a junction be detected when a client tries to resolve the target of a junction
that refers to the deleted FSN and the NSDB returns ERR_NOTFOUND. that refers to the deleted FSN and the NSDB returns an error.
PARAGRAPH DESCRIBING ERRORS
9.1.2.1. LDAP Request 7.1.2.1. LDAP Request
The admin sends an LDAP DELETE request to the NSDB server to remove The admin sends an LDAP DELETE request to the NSDB server to remove
the FsnObject from the NSDB server. An example LDIF for the delete the FsnObject from the NSDB server. An example LDIF for the delete
request is shown below. request is shown below.
dn: fsnUuid=FSNUUID,dc=fed-fs,dc=com dn: fsnUuid=FSNUUID,dc=fed-fs,dc=com
changeType: delete changeType: delete
9.1.3. Mount an FSN 7.1.3. Create an FSL
NOTE: the semantics of this operation have changed significantly, and
"mount" might be a quite unintuitive name at this point.
The mount operation records that a given fileset (called the parent
fileset) contains a junction. The target of that fileset is called
the child fileset.
The NSDB of the parent fileset (as identified by the FSN of the
parent) maintains this information.
The parent/child relation is used to indicate how the filesets in the
federation are related. The names "parent" and "child" should not be
taken literally. A fileset can have no parent (if it is a root
fileset). A fileset may also have any number of parents. In theory,
the parent of a fileset may also be its child, although in practice
this is deprecated.
A fileset may be mounted in multiple places, and may have the same
parent multiple times. For example, /home/ellard and /home/
daniel.ellard might both be junctions from the /home fileset to the
fileset that represents the home directory of user Daniel Ellard. In
order to be able to distinguish each mount, each mount is given a
unique identifier (in addition to the fsnUuids of the parent and
child).
PARAGRAPH DESCRIBING ERRORS
9.1.3.1. LDAP Request
On fileset mount operation the admin will generate an LDAP ADD
request to the NSDB server using the example LDIF below. This
creates a new FsnJunctionObject that establishes the mount
relationship between the parent and target FSNs.
dn: key=KEY,fsnUuid=FSNUUID,dc=fed-fs,dc=com
changeType: add
objectClass: JunctionObject
fsnUuid: FSNUUID
nsdbName: NSDBNAME
childFsnUuid: CHILDFSNUUID
childNsdbName: CHILDNSDB
9.1.4. Unmount an FSN
Removes the record of a junction between a parent and child fileset.
PARAGRAPH DESCRIBING ERRORS
9.1.4.1. LDAP Request
In case a target_FSN is to be unmmounted, the associated
JunctionObject is deleted from the NSDB maintaining the parent
fileset. An example delete request is shown below.
dn: key=KEY,fsnUuid=FSNUUID,dc=fed-fs,dc=com
changeType: delete
9.1.5. Create an FSL
Creates a new Fileset location at the given location denoted by HOST Creates a new Fileset location at the given location denoted by HOST
and PATH for the given FSN. Normally an FSL is identified by the and PATH for the given FSN. Normally an FSL is identified by the
HOST:PATH pair. A UUID is an optional way to identify an FSL if it HOST:PATH pair. A UUID is an optional way to identify an FSL if it
is recovered to a different HOST:PATH after a backup/restore. If the is recovered to a different HOST:PATH after a backup/restore.
FSL belongs to an FSN that has another FSN mounted under it then
there would be a related junction_create operation.
PARAGRAPH DESCRIBING ERRORS
The FSL create command will result in the admin server sending an The FSL create command will result in the admin server sending an
LDAP ADD request to create a new FslObject at the NSDB maintaining LDAP ADD request to create a new FslObject at the NSDB maintaining
the given FSN. The example LDIF is shown below. The PATH is the the given FSN. The example LDIF is shown below. The PATH is the
pathname where the fileset is located on that host. pathname where the fileset is located on that host.
9.1.5.1. LDAP Request 7.1.3.1. LDAP Request
The admin sends an LDAP ADD request to the NSDB server to add the
FLS.
dn:fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com dn:fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com
changeType: add changeType: add
objectClass: FslObject objectClass: FslObject
fsnUuid: FSNUUID fsnUuid: FSNUUID
nsdbName: NSDB nsdbName: NSDB
fslUuid: UUID fslUuid: UUID
fslHost: HOST fslHost: HOST
fslPath: PATH fslPath: PATH
type: file access protocol type (e.g. nfs4) type: file access protocol type (e.g. nfs4)
currency: CURRENCY currency: CURRENCY
info: INFO info: INFO
annotation: ANNOTATION annotation: ANNOTATION
9.1.6. Delete an FSL 7.1.4. Delete an FSL
Deletes the given Fileset location. The admin requests the NSDB Deletes the given Fileset location. The admin requests the NSDB
location storing the FslObject to delete it from its database. This location storing the FslObject to delete it from its database. This
operation does not result in the fileset location's data being operation does not result in the fileset location's data being
deleted at the fileserver. deleted at the fileserver.
PARAGRAPH DESCRIBING ERRORS 7.1.4.1. LDAP Request
9.1.6.1. LDAP Request The admin sends an LDAP DELETE request to the NSDB server to remove
the FLS.
dn: fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com dn: fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com
changeType: delete changeType: delete
9.1.7. Update an FSL 7.1.5. Update an FSL
Update the attributes of a given FSL. This command results in a Update the attributes of a given FSL. This command results in a
change in the attributes of the FslObject at the NSDB server change in the attributes of the FslObject at the NSDB server
maintaining this FSL. The attributes that must not change are the maintaining this FSL. The attributes that must not change are the
fslUuid and the fsnUuid of the fileset this FSL implements. fslUuid and the fsnUuid of the fileset this FSL implements.
PARAGRAPH DESCRIBING ERRORS 7.1.5.1. LDAP Request
9.1.7.1. LDAP Request The admin sends an LDAP MODIFY request to the NSDB server to update
the FLS.
dn: fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com dn: fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com
changeType: modify changeType: modify
replace: ATTRIBUTE-TYPE replace: ATTRIBUTE-TYPE
9.1.8. Finding the children FSNs of a fileset 7.2. Fileserver to NSDB Operations
The NSDB also tracks information about which filesets are "children"
of others. A fileset X is a child of fileset Y if there is a
junction in fileset Y referencing fileset X. (note that this
definition permits a fileset to be its own child, although this use
is deprecated)
In addition to keeping track of whether one fileset has another as
its child, the NSDB also records additional information to simplify
management -- each parent/child relation is associated with an
additional key that is used to disambiguate the relationship. For
example, one fileset may have several junctions targeting the same
child, but each has a seperate key that can be used to differentiate
them. This permits junctions to be removed without necessarily
removing the underlying relationship.
NOTE: if it is decided to require that there can only be one junction
from one fileset to a second, then the key should simply be the FSN
of the target. This restriction would greatly simplify some aspects
of the implementation (but it may also eliminate some very useful
functionality).
LDAP Request
Search base: fsnUuid=FSNUUID, dc=fed-fs, dc=com
Search scope: onelevel
Search filter: (objectClass=JunctionObject)
9.2. Fileserver to NSDB Operations
9.2.1. Looking up FSLs for an FSN 7.2.1. Looking up FSLs for an FSN
Return the list of FSLs for the FSN with an fsnUuid that matches the This operation returns the list of FSLs for the given FSN. The FSN's
filter. The fileserver will convert the list of FSLs to the NFSv4 fsnUuid is used as the search key. The fileserver will convert the
fs_locations. list of FSLs to the NFSv4 fs_locations or NFSv4.1 fs_locations_info.
The filter may also specify the type of protocol (v4, v3), or type of The filter may also specify the type of protocol (v4, v4.1), or type
data access (ro, rw). of data access (ro, rw).
ERRORS: ERR_OK ERR_NOTFOUND ERR_INVALID ERR_PERM <figure>
<artwork>
LDAP Request LDAP Request
Search base: fsnUuid=FSNUUID, dc=fed-fs, dc=com Search base: fsnUuid=FSNUUID, dc=fed-fs, dc=com
Search scope: onelevel Search scope: onelevel
Search filter: (objectClass=FslObject) Search filter: (objectClass=FslObject)
The server can scan through the results and find results whose type The server can scan through the results and find results whose type
corresponds to the type of the client on whose behalf the server is corresponds to the type of the client on whose behalf the server is
performing the request, extracting the fslHost and fslPath (and performing the request, extracting the fslHost and fslPath (and
possibly additional attributes) and using them to create a list of possibly additional attributes) and using them to create an
fs_locations that the client can use. fs_locations list or fs_locations_info list that the client can use.
10. Security Considerations 8. Security Considerations
Both LDAP and NFSv4 provide security mechanisms. When used in Both LDAP and NFSv4/NFSv4.1 provide security mechanisms. When used
conjunction with the federated file system protocols described in in conjunction with the federated file system protocols described in
this document, the use of these mechanisms is RECOMMENDED. this document, the use of these mechanisms is RECOMMENDED.
Specifically, the use of RPCSEC_GSS [RFC2203] [RFC2743] is Specifically, the use of RPCSEC_GSS [RFC2203] [RFC2743] is
RECOMMENDED on all connections between a client and filerserver. For RECOMMENDED on all connections between a client and fileserver. For
all LDAP connections established by the federated file system all LDAP connections established by the federated file system
protocols, TLS [RFC4346] [RFC4513] is RECOMMENDED. protocols, TLS [RFC5246] [RFC4513] is RECOMMENDED.
11. IANA Requirements Within a federation, there are two components that an attacker may be
able to compromise: a fileserver and an NSDB. If an attacker
compromises a fileserver, the attacker can interfere with the
client's file system I/O operations (e.g. by returning fictitious
data in the response to a read request) or fabricating a referral.
The attackers abilities are the same regardless of whether or not the
federation protocols are in use. If an attacker compromises an NSDB,
the attacker will be able to forge FSL information and thus poison
the fileserver's referral information. Therefore an NSDB should be
as secure as the fileservers which query it.
It should be noted that the federation protocols do not directly
provide access to file system data. The federation protocols only
provide a mechanism for building a namespace. All data transfers are
occur between a client and server just as they would if the
federation protocols were not in use. As a result, the federation
protocols do not require new user authentication and authorization
mechanisms or require a file server to act as a proxy for a client.
9. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
12. Conclusions 10. 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.
13. Glossary 11. Glossary
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 35, line 16 skipping to change at page 32, 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 37, line 5 skipping to change at page 34, 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.
14. Normative References 12. References
[RFC1094] Nowicki, B., "NFS: Network File System Protocol 12.1. Normative References
specification", RFC 1094, March 1989.
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS [FEDFS-ADMIN]
Version 3 Protocol Specification", RFC 1813, June 1995. J. Lentini, et al., "Administration Protocol for Federated
Filesystems (Work In Progress)",
draft-ietf-nfsv4-federated-fs-admin , 2008.
[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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997. Specification", RFC 2203, September 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(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
Text on Security Considerations", BCP 72, RFC 3552,
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 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (LDAP): Technical Specification Road Map", RFC 4510,
June 2006.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(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.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
12.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.
[RFC3254] Alvestrand, H., "Definitions for talking about
directories", RFC 3254, April 2002.
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. 120 change blocks. 
503 lines changed or deleted 424 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/