draft-ietf-nfsv4-federated-fs-protocol-08.txt   draft-ietf-nfsv4-federated-fs-protocol-09.txt 
NFSv4 Working Group J. Lentini NFSv4 Working Group J. Lentini
Internet-Draft C. Everhart Internet-Draft C. Everhart
Intended status: Standards Track NetApp Intended status: Standards Track NetApp
Expires: February 19, 2011 D. Ellard Expires: March 6, 2011 D. Ellard
Raytheon BBN Technologies Raytheon BBN Technologies
R. Tewari R. Tewari
M. Naik M. Naik
IBM Almaden IBM Almaden
August 18, 2010 September 2, 2010
NSDB Protocol for Federated Filesystems NSDB Protocol for Federated Filesystems
draft-ietf-nfsv4-federated-fs-protocol-08 draft-ietf-nfsv4-federated-fs-protocol-09
Abstract Abstract
This document describes a filesystem federation protocol that enables This document describes a filesystem federation protocol that enables
file access and namespace traversal across collections of 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 with different administrators can of interfaces by which fileservers with different administrators can
form a fileserver federation that provides a namespace composed of form a fileserver federation that provides a namespace composed of
the filesystems physically hosted on and exported by the constituent the filesystems physically hosted on and exported by the constituent
fileservers. fileservers.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 19, 2011. This Internet-Draft will expire on March 6, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview of Features and Concepts . . . . . . . . . . . . . . 5 2. Overview of Features and Concepts . . . . . . . . . . . . . . 6
2.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. File-access Protocol . . . . . . . . . . . . . . . . . . . 6
2.2. Fileset . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. File-access Client . . . . . . . . . . . . . . . . . . . . 6
2.3. Fileset Name (FSN) . . . . . . . . . . . . . . . . . . . . 5 2.3. Fileserver . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Fileset Location (FSL) . . . . . . . . . . . . . . . . . . 6 2.4. Referral . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1. Mutual Consistency across Fileset Locations . . . . . 6 2.5. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.2. Caching of Fileset Locations . . . . . . . . . . . . . 7 2.6. Fileset . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.3. Generating A Referral from Fileset Locations . . . . . 8 2.7. Fileset Name (FSN) . . . . . . . . . . . . . . . . . . . . 7
2.5. Namespace Database (NSDB) . . . . . . . . . . . . . . . . 9 2.8. Fileset Location (FSL) . . . . . . . . . . . . . . . . . . 7
2.6. Mount Points, Junctions and Referrals . . . . . . . . . . 9 2.8.1. Mutual Consistency across Fileset Locations . . . . . 8
2.7. Unified Namespace and the Root Fileset . . . . . . . . . . 10 2.8.2. Caching of Fileset Locations . . . . . . . . . . . . . 9
2.8. Fileservers . . . . . . . . . . . . . . . . . . . . . . . 10 2.8.3. Generating A Referral from Fileset Locations . . . . . 9
2.9. File-access Clients . . . . . . . . . . . . . . . . . . . 10 2.9. Namespace Database (NSDB) . . . . . . . . . . . . . . . . 10
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.10. Mount Points, Junctions and Referrals . . . . . . . . . . 11
3.1. Creating a Fileset and its FSL(s) . . . . . . . . . . . . 11 2.11. Unified Namespace and the Root Fileset . . . . . . . . . . 12
3.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 11 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 12 3.1. Creating a Fileset and its FSL(s) . . . . . . . . . . . . 12
3.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 12 3.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 13
3.3. Example Use Cases for Fileset Annotations . . . . . . . . 13 3.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 13
4. NSDB Configuration and Schema . . . . . . . . . . . . . . . . 13 3.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 13
4.1. LDAP Configuration . . . . . . . . . . . . . . . . . . . . 14 3.3. Example Use Cases for Fileset Annotations . . . . . . . . 14
4.2. LDAP Schema . . . . . . . . . . . . . . . . . . . . . . . 15 4. NSDB Configuration and Schema . . . . . . . . . . . . . . . . 15
4.2.1. LDAP Attributes . . . . . . . . . . . . . . . . . . . 16 4.1. LDAP Configuration . . . . . . . . . . . . . . . . . . . . 15
4.2.2. LDAP Objects . . . . . . . . . . . . . . . . . . . . . 34 4.2. LDAP Schema . . . . . . . . . . . . . . . . . . . . . . . 16
5. NSDB Operations . . . . . . . . . . . . . . . . . . . . . . . 37 4.2.1. LDAP Attributes . . . . . . . . . . . . . . . . . . . 17
5.1. NSDB Operations for Administrators . . . . . . . . . . . . 38 4.2.2. LDAP Objects . . . . . . . . . . . . . . . . . . . . . 35
5.1.1. Create an FSN . . . . . . . . . . . . . . . . . . . . 39 5. NSDB Operations . . . . . . . . . . . . . . . . . . . . . . . 38
5.1.2. Delete an FSN . . . . . . . . . . . . . . . . . . . . 40 5.1. NSDB Operations for Administrators . . . . . . . . . . . . 39
5.1.3. Create an FSL . . . . . . . . . . . . . . . . . . . . 40 5.1.1. Create an FSN . . . . . . . . . . . . . . . . . . . . 40
5.1.4. Delete an FSL . . . . . . . . . . . . . . . . . . . . 44 5.1.2. Delete an FSN . . . . . . . . . . . . . . . . . . . . 41
5.1.5. Update an FSL . . . . . . . . . . . . . . . . . . . . 44 5.1.3. Create an FSL . . . . . . . . . . . . . . . . . . . . 41
5.2. NSDB Operations for Fileservers . . . . . . . . . . . . . 45 5.1.4. Delete an FSL . . . . . . . . . . . . . . . . . . . . 45
5.2.1. NSDB Container Entry (NCE) Enumeration . . . . . . . . 45 5.1.5. Update an FSL . . . . . . . . . . . . . . . . . . . . 45
5.2.2. Lookup FSLs for an FSN . . . . . . . . . . . . . . . . 45 5.2. NSDB Operations for Fileservers . . . . . . . . . . . . . 46
6. Security Considerations . . . . . . . . . . . . . . . . . . . 47 5.2.1. NSDB Container Entry (NCE) Enumeration . . . . . . . . 46
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 5.2.2. Lookup FSLs for an FSN . . . . . . . . . . . . . . . . 46
7.1. LDAP Descriptor Registration . . . . . . . . . . . . . . . 48 5.3. NSDB Operations and LDAP Referrals . . . . . . . . . . . . 48
8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6. Security Considerations . . . . . . . . . . . . . . . . . . . 48
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
9.1. Normative References . . . . . . . . . . . . . . . . . . . 53 7.1. LDAP Descriptor Registration . . . . . . . . . . . . . . . 49
9.2. Informative References . . . . . . . . . . . . . . . . . . 55 8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 56 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 9.1. Normative References . . . . . . . . . . . . . . . . . . . 55
9.2. Informative References . . . . . . . . . . . . . . . . . . 57
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58
1. Introduction 1. 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 or across multiple enterprises. fileservers within an enterprise or across multiple enterprises.
This document specifies a set of protocols that allow fileservers, This document specifies a set of protocols that allow fileservers,
possibly from different vendors and with different administrators, to possibly from different vendors and with different administrators, to
cooperatively form a federation containing one or more federated cooperatively form a federation containing one or more federated
skipping to change at page 4, line 48 skipping to change at page 5, line 48
information. information.
The federated filesystem protocols in this document define how to The federated filesystem protocols in this document define how to
construct a namespace accessible by an NFSv4 [3530bis] or NFSv4.1 construct a namespace accessible by an NFSv4 [3530bis] or NFSv4.1
[RFC5661] client and have been designed to accommodate other file [RFC5661] client and have been designed to accommodate other file
access protocols in the future. access protocols in the future.
The requirements for federated filesystems are described in The requirements for federated filesystems are described in
[RFC5716]. A protocol for administering a fileserver's namespace is [RFC5716]. A protocol for administering a fileserver's namespace is
described in [FEDFS-ADMIN]. The mechanism for discovering the root described in [FEDFS-ADMIN]. The mechanism for discovering the root
of an NFSv4 namespace is described in [FEDFS-DNS-SRV]. In the rest of an NFSv4 namespace is described in [FEDFS-DNS-SRV].
of the document, the term fileserver denotes a fileserver that is
part of a federation. In the rest of the document, the term fileserver denotes a fileserver
that is part of a federation.
2. Overview of Features and Concepts 2. Overview of Features and Concepts
2.1. Namespace 2.1. File-access Protocol
A file-access protocol is a network protocol for accessing data. The
NFSv4 protocol and the NFSv4.1 protocol are both examples of a file-
access protocol.
2.2. File-access Client
File-access clients are standard off-the-shelf network attached
storage (NAS) clients that communicate with fileservers using the
NFSv4 protocol, the NFSv4.1 protocol, or some other file-access
protocol.
2.3. Fileserver
Fileservers are servers that store the physical fileset data or 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. A fileserver provides access
to a federated filesystem via NFSv4, NFSv4.1, or some other file-
access protocol.
2.4. Referral
A referral is a mechanism by which a fileserver redirects a file-
access protocol client to a different fileserver. The exact
information contained in a referral varies from one file-access
protocol to another. The NFSv4 protocol defines the fs_locations
attribute for referral information. The NFSv4.1 protocol defines the
fs_locations_info attribute for referral information.
2.5. 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.
From the perspective of the clients, the common namespace is From the perspective of the clients, the common namespace is
constructed by mounting filesets that are physically located on constructed by 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.
2.2. Fileset 2.6. Fileset
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. Depending on the configuration, they may be of data management. Depending on the configuration, they may be
anything between an individual directory of an exported filesystem to anything between an individual directory of an exported filesystem to
an entire exported filesystem at a fileserver. an entire exported filesystem at a fileserver.
2.3. Fileset Name (FSN) 2.7. Fileset Name (FSN)
A fileset is uniquely represented by its fileset name (FSN). An FSN A fileset is uniquely represented by its fileset name (FSN). An FSN
is considered unique across the federation. After an FSN is created, is considered unique across the federation. After an FSN is created,
it is associated with one or more fileset locations (FSLs) on a it is associated with one or more fileset locations (FSLs) on a
fileserver. fileserver.
The attributes of an FSN are: The attributes of an FSN are:
NsdbName: the network location of the NSDB node that contains NsdbName: the network location of the NSDB node that contains
authoritative information for this FSN. authoritative information for this FSN.
FsnUuid: a 128-bit UUID (universally unique identifier), FsnUuid: a 128-bit UUID (universally unique identifier),
conforming to [RFC4122], that is used to uniquely identify an conforming to [RFC4122], that is used to uniquely identify an
FSN. FSN.
2.4. Fileset Location (FSL) 2.8. Fileset Location (FSL)
An FSL describes the location where the fileset data resides. An FSL An FSL describes the location where the fileset data resides. An FSL
contains generic and type specific information which together contains generic and type specific information which together
describe how to access the fileset. An FSL's type indicates which describe how to access the fileset. An FSL's type indicates which
protocol(s) may be used to access its data. An FSL's attributes can protocol(s) may be used to access its data. An FSL's attributes can
be used by a fileserver to decide which locations it will return to a be used by a fileserver to decide which locations it will return to a
client. client.
All FSLs have the following attributes: All FSLs have the following attributes:
skipping to change at page 6, line 46 skipping to change at page 8, line 27
This document defines an FSL subtype for NFS. An NFS FSL contains This document defines an FSL subtype for NFS. An NFS FSL contains
information suitable for use in an NFSv4 fs_locations [3530bis] or information suitable for use in an NFSv4 fs_locations [3530bis] or
NFSv4.1 fs_locations_info attribute [RFC5661]. NFSv4.1 fs_locations_info attribute [RFC5661].
A fileset MAY be accessible by protocols other than NFS. For each A fileset MAY be accessible by protocols other than NFS. For each
such protocol, a corresponding FSL subtype SHOULD be defined. The such protocol, a corresponding FSL subtype SHOULD be defined. The
contents and format of such FSL subtypes are not defined in this contents and format of such FSL subtypes are not defined in this
document. document.
2.4.1. Mutual Consistency across Fileset Locations 2.8.1. Mutual Consistency across Fileset Locations
All of the FSLs that have the same FSN (and thereby reference the All of the FSLs that have the same FSN (and thereby reference the
same fileset) are equivalent from the point of view of client access; same fileset) are equivalent from the point of view of client access;
the different locations of a fileset represent the same data, though the different locations of a fileset represent the same data, though
potentially at different points in time. Fileset locations are potentially at different points in time. Fileset locations are
equivalent but not identical. Locations may either be read-only or equivalent but not identical. Locations may either be read-only or
read-write. Typically, multiple read-write locations are backed by a read-write. Typically, multiple read-write locations are backed by a
clustered filesystem while read-only locations are replicas created clustered filesystem while read-only locations are replicas created
by a federation-initiated or external replication operation. Read- by a federation-initiated or external replication operation. Read-
only locations may represent consistent point-in-time copies of a only locations may represent consistent point-in-time copies of a
skipping to change at page 7, line 27 skipping to change at page 9, line 8
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 (e.g., NFSv4) to data. It relies on the client file-access protocol (e.g., 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. clients do not revert back in time when switching locations.
2.4.2. Caching of Fileset Locations 2.8.2. Caching of Fileset Locations
To resolve an FSN to a set of FSL records, the fileserver queries the To resolve an FSN to a set of FSL records, the fileserver queries the
appropriate NSDB for the FSL records. A fileserver MAY cache these appropriate NSDB for the FSL records. A fileserver MAY cache these
FSL records for a limited period of time. The period of time, if FSL records for a limited period of time. The period of time, if
any, during which FSL records MAY be cached is indicated by the FSL's any, during which FSL records MAY be cached is indicated by the FSL's
TTL field. TTL field.
The combination of FSL caching and FSL migration presents a The combination of FSL caching and FSL migration presents a
challenge. For example, suppose there are three fileservers named A, challenge. For example, suppose there are three fileservers named A,
B, and C and fileserver A contains a junction to fileset X stored on B, and C and fileserver A contains a junction to fileset X stored on
skipping to change at page 8, line 19 skipping to change at page 9, line 48
Each FSL contains a TTL field, a count in seconds of the time Each FSL contains a TTL field, a count in seconds of the time
interval the FSL MAY be cached. This is an upper bound for the interval the FSL MAY be cached. This is an upper bound for the
lifetime of the cached information and a lower bound for the lifetime lifetime of the cached information and a lower bound for the lifetime
of the supplemental junctions. For example, suppose this field of the supplemental junctions. For example, suppose this field
contains the value 3600 seconds (one hour). In such a case, contains the value 3600 seconds (one hour). In such a case,
administrators MUST keep the supplemental junctions in place for at administrators MUST keep the supplemental junctions in place for at
least one hour after the fileset move has taken place, and FSL data least one hour after the fileset move has taken place, and FSL data
MUST NOT be cached by a referring fileserver for more than one hour MUST NOT be cached by a referring fileserver for more than one hour
without a refresh. without a refresh.
2.4.3. Generating A Referral from Fileset Locations 2.8.3. Generating A Referral from Fileset Locations
After resolving an FSN to a set of FSL records, the fileserver can After resolving an FSN to a set of FSL records, the fileserver can
generate a referral to redirect the client to one or more of the generate a referral to redirect the client to one or more of the
FSLs. The fileserver will convert the FSL records to a referral FSLs. The fileserver will convert the FSL records to a referral
format understood by the client, such as an NFSv4 fs_locations format understood by the client, such as an NFSv4 fs_locations
attribute or NFSv4.1 fs_locations_info attribute. attribute or NFSv4.1 fs_locations_info attribute.
In order to give the client as many options as possible, the In order to give the client as many options as possible, the
fileserver SHOULD include the maximum possible number of FSL records fileserver SHOULD include the maximum possible number of FSL records
in a referral. However, the fileserver MAY omit some of the FSL in a referral. However, the fileserver MAY omit some of the FSL
skipping to change at page 9, line 7 skipping to change at page 10, line 36
converts or reduces FSL data, the fileserver SHOULD attempt to converts or reduces FSL data, the fileserver SHOULD attempt to
maintain the original meaning where possible. For example, an NFS maintain the original meaning where possible. For example, an NFS
FSL record contains the rank and order information that is included FSL record contains the rank and order information that is included
in an NFSv4.1 fs_locations_info attribute (see NFSv4.1's in an NFSv4.1 fs_locations_info attribute (see NFSv4.1's
FSLI4BX_READRANK, FSLI4BX_READORDER, FSLI4BX_WRITERANK, and FSLI4BX_READRANK, FSLI4BX_READORDER, FSLI4BX_WRITERANK, and
FSLI4BX_WRITEORDER). While this rank and order information is not FSLI4BX_WRITEORDER). While this rank and order information is not
explicitly expressible in an NFSv4 fs_locations attribute, the explicitly expressible in an NFSv4 fs_locations attribute, the
fileserver can arrange the NFSv4 fs_locations attribute's locations fileserver can arrange the NFSv4 fs_locations attribute's locations
list base on the rank and order values. list base on the rank and order values.
2.5. Namespace Database (NSDB) 2.9. 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, FSL interfaces to define, update, and query FSN information, FSL
information, and FSN to FSL mapping information. An individual information, and FSN to FSL mapping information. An individual
repository of namespace information is called an NSDB node. Each repository of namespace information is called an NSDB node. Each
NSDB node is managed by a single administrative entity. A single NSDB node is managed by a single administrative entity. A single
admin entity can manage multiple NSDB nodes. admin entity can manage multiple NSDB nodes.
The difference between the NSDB service and an NSDB node is analogous The difference between the NSDB service and an NSDB node is analogous
to that between the DNS service and a particular DNS server. to that between the DNS service and a particular DNS server.
skipping to change at page 9, line 35 skipping to change at page 11, line 16
junction. Each NSDB node supports an LDAP [RFC4510] interface and junction. Each NSDB node supports an LDAP [RFC4510] interface and
can be accessed by an LDAP client. can be accessed by an LDAP client.
An NSDB MAY be replicated throughout the federation. If an NSDB is An NSDB MAY be replicated throughout the federation. If an NSDB is
replicated, the NSDB MUST exhibit loose, converging consistency as replicated, the NSDB MUST exhibit loose, converging consistency as
defined in [RFC3254]. The mechanism by which this is achieved is defined in [RFC3254]. The mechanism by which this is achieved is
outside the scope of this document. Many LDAP implementations outside the scope of this document. Many LDAP implementations
support replication. These features MAY be used to replicate the support replication. These features MAY be used to replicate the
NSDB. NSDB.
2.6. Mount Points, Junctions and Referrals 2.10. 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
in the underlying filesystem. In other words, a junction can be in the underlying filesystem. In other words, a junction can be
viewed as a reference from a directory in one fileset to the root of viewed as a reference from a directory in one fileset to the root of
skipping to change at page 10, line 22 skipping to change at page 12, line 5
a list of FSLs associated with the FSN targeted by the junction. The a list of FSLs associated with the FSN targeted by the junction. The
client can then redirect its connection to one of the FSLs. This act client can then redirect its connection to one of the FSLs. This act
is called a referral. For NFSv4 and NFSv4.1 clients, the FSL is called a referral. For NFSv4 and NFSv4.1 clients, the FSL
information is returned in the fs_locations and fs_locations_info information is returned in the fs_locations and fs_locations_info
attributes respectively. attributes respectively.
The federation protocols 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.
2.7. Unified Namespace and the Root Fileset 2.11. Unified Namespace and the Root Fileset
The root fileset, when defined, is the top-level fileset of the The root fileset, when defined, is the top-level fileset of the
federation-wide namespace. The root of the unified namespace is the federation-wide namespace. The root of the unified namespace is the
top level directory of this fileset. A set of designated fileservers top level directory of this fileset. A set of designated fileservers
in the federation can export the root fileset to render the in the federation can export the root fileset to render the
federation-wide unified namespace. When a client mounts the root federation-wide unified namespace. When a client mounts the root
fileset from any of these designated fileservers it can view a common fileset from any of these designated fileservers it can view a common
federation-wide namespace. The root fileset could be implemented federation-wide namespace. The root fileset could be implemented
either as an exported NFS file system or as data in the NSDB itself. either as an exported NFS file system or as data in the NSDB itself.
The properties and schema definition of an NSDB-based root fileset The properties and schema definition of an NSDB-based root fileset
and the protocol details that describe how to configure and replicate and the protocol details that describe how to configure and replicate
the root fileset are not defined in this document. the root fileset are not defined in this document.
2.8. Fileservers
Fileservers are servers that store the physical fileset data or 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. A fileserver provides access
to a federated filesystem via NFSv4, NFSv4.1, or some other protocol.
2.9. File-access Clients
File access clients are standard off-the-shelf network attached
storage (NAS) clients that access file data using the NFSv4 protocol,
the NFSv4.1 protocol, or some other protocol.
3. Examples 3. 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 filesystem protocol: creating operations facilitated by the federated filesystem protocol: creating
a fileset, adding a replica of a fileset, resolving a junction, and a fileset, adding a replica of a fileset, resolving a junction, and
creating a junction. creating a junction.
3.1. Creating a Fileset and its FSL(s) 3.1. Creating a Fileset and its FSL(s)
A fileset is the abstraction of a set of files and the directory tree A fileset is the abstraction of a set of files and the directory tree
skipping to change at page 38, line 32 skipping to change at page 39, line 32
therefore we define in these sections the minimum level of LDAP therefore we define in these sections the minimum level of LDAP
functionality required to implement an NSDB node. functionality required to implement an NSDB node.
The NSDB sub-protocols are defined in the next two sub-sections. The The NSDB sub-protocols are defined in the next two sub-sections. The
descriptions of LDAP messages in these sections use the LDAP Data descriptions of LDAP messages in these sections use the LDAP Data
Interchange Format (LDIF) [RFC2849]. In order to differentiate Interchange Format (LDIF) [RFC2849]. In order to differentiate
constant and variable strings in the LDIF specifications, variables constant and variable strings in the LDIF specifications, variables
are prefixed by a $ character and use all upper case characters. For are prefixed by a $ character and use all upper case characters. For
example, a variable named FOO would be specified as $FOO. example, a variable named FOO would be specified as $FOO.
This document uses the term NSDB client to refer to an LDAP client
that uses either of the NSDB sub-protocols
The third sub-protocol defines the queries and other requests that The third sub-protocol defines the queries and other requests that
are sent to a fileserver in order to get information from it or to are sent to a fileserver in order to get information from it or to
modify the state of the fileserver in a manner related to the modify the state of the fileserver 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 discover related administrator to create or delete a junction or discover related
information about a particular fileserver. information about a particular fileserver.
The third sub-protocol is defined as an ONC RPC protocols. The The third sub-protocol is defined as an ONC RPC protocols. The
reason for using ONC RPC instead of LDAP is that all fileservers reason for using ONC RPC instead of LDAP is that all fileservers
support ONC RPC but some do not support an LDAP Directory server. support ONC RPC but some do not support an LDAP Directory server.
skipping to change at page 41, line 8 skipping to change at page 42, line 8
fedfsFsl entry in the NSDB's LDAP directory. fedfsFsl entry in the NSDB's LDAP directory.
A fedfsFsl entry contains a fedfsFslUuid, fedfsFsnUuid, A fedfsFsl entry contains a fedfsFslUuid, fedfsFsnUuid,
fedfsNsdbName, fedfsFslHost, and fedfsFslTTL. The administrator fedfsNsdbName, fedfsFslHost, and fedfsFslTTL. The administrator
chooses the fedfsFslUuid. The process for choosing the fedfsFslUuid chooses the fedfsFslUuid. The process for choosing the fedfsFslUuid
is described in Section 4.2.1.1. The fedfsFsnUuid is the UUID of the is described in Section 4.2.1.1. The fedfsFsnUuid is the UUID of the
FSL's FSN. The fedfsNsdbName is the name of the NSDB node that FSL's FSN. The fedfsNsdbName is the name of the NSDB node that
stores definitive information about the FSL's FSN. The fedfsFslHost stores definitive information about the FSL's FSN. The fedfsFslHost
value is the network location of the fileserver that stores the FSL. value is the network location of the fileserver that stores the FSL.
The fedfsFslTTL is chosen by the administrator as described in The fedfsFslTTL is chosen by the administrator as described in
Section 2.4.2. Section 2.8.2.
The administrator will also set additional attributes depending on The administrator will also set additional attributes depending on
the FSL type. the FSL type.
5.1.3.1. LDAP Request 5.1.3.1. LDAP Request
This operation is implemented using the LDAP ADD request described by This operation is implemented using the LDAP ADD request described by
the LDIF below (NOTE: the LDIF shows the creation of an NFS FSL) the LDIF below (NOTE: the LDIF shows the creation of an NFS FSL)
dn:fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE dn:fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE
skipping to change at page 43, line 9 skipping to change at page 44, line 9
fedfsNfsWriteRank: 5 fedfsNfsWriteRank: 5
fedfsNfsWriteOrder: 6 fedfsNfsWriteOrder: 6
fedfsNfsVarSub: FALSE fedfsNfsVarSub: FALSE
fedfsNfsValidFor: 300 fedfsNfsValidFor: 300
fedfsAnnotation: "foo" = "bar" fedfsAnnotation: "foo" = "bar"
fedfsDescr: This is a description. fedfsDescr: This is a description.
5.1.3.2. Selecting fedfsNfsFsl Values 5.1.3.2. Selecting fedfsNfsFsl Values
The fedfsNfsFSl object class is used to describe NFSv4 and NFSv4.1 The fedfsNfsFSl object class is used to describe NFSv4 and NFSv4.1
accessible filesets. For the reasons described in Section 2.4.3, accessible filesets. For the reasons described in Section 2.8.3,
administrators SHOULD choose reasonable values for all LDAP administrators SHOULD choose reasonable values for all LDAP
attributes of an NFSv4 accessible fedfsNfsFsl even though some of attributes of an NFSv4 accessible fedfsNfsFsl even though some of
these LDAP attributes are not explicitly contained in the NFSv4 these LDAP attributes are not explicitly contained in the NFSv4
fs_locations attribute returned to an NFSv4 client. fs_locations attribute returned to an NFSv4 client.
When the administrator is unable to choose reasonable values for the When the administrator is unable to choose reasonable values for the
LDAP attributes not explicitly contained in a NFSv4 fs_locations LDAP attributes not explicitly contained in a NFSv4 fs_locations
attribute, the values in the following table are RECOMMENDED. attribute, the values in the following table are RECOMMENDED.
+-------------------------+----------+------------------------------+ +-------------------------+----------+------------------------------+
skipping to change at page 45, line 46 skipping to change at page 46, line 46
* *
*/ */
if a fedfsNcePrefix value is found if a fedfsNcePrefix value is found
nce = prepend the fedfsNcePrefix value to $BAR nce = prepend the fedfsNcePrefix value to $BAR
add nce to the nce_list add nce to the nce_list
5.2.2. Lookup FSLs for an FSN 5.2.2. Lookup FSLs for an FSN
Using an LDAP search, the fileserver can obtain all of the FSLs for a Using an LDAP search, the fileserver can obtain all of the FSLs for a
given FSN. The FSN's fedfsFsnUuid is used as the search key. The given FSN. The FSN's fedfsFsnUuid is used as the search key. The
following examples use the LDAP URI format defined in [RFC4516]. following examples use the LDAP Universal Resource Identifier (URI)
format defined in [RFC4516].
To obtain a list of all FSLs for $FSNUUID on the NSDB named To obtain a list of all FSLs for $FSNUUID on the NSDB named
$NSDBNAME, the following search can be used (for readability the URI $NSDBNAME, the following search can be used (for readability the URI
is split into two lines): is split into two lines):
for each $NCE in nce_list for each $NCE in nce_list
ldap://$NSDBNAME/fsnUuid=$FSNUUID,$NCE??one? ldap://$NSDBNAME/fsnUuid=$FSNUUID,$NCE??one?
(objectClass=fedfsFsl) (objectClass=fedfsFsl)
This search is for the children of the object with DN This search is for the children of the object with DN
skipping to change at page 47, line 7 skipping to change at page 48, line 7
For example if $NSDBNAME is nsdb.example.com, $FSNUUID is f81d4fae- For example if $NSDBNAME is nsdb.example.com, $FSNUUID is f81d4fae-
7dec-11d0-a765-00a0c91e6bf6, and $NCE is "o=fedfs",the search would 7dec-11d0-a765-00a0c91e6bf6, and $NCE is "o=fedfs",the search would
be (for readability the URI is split into three lines): be (for readability the URI is split into three lines):
ldap://nsdb.example.com/ ldap://nsdb.example.com/
fsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs fsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs
??one?(objectClass=fedfsNfsFsl) ??one?(objectClass=fedfsNfsFsl)
The fileserver will generate a referral based on the set of FSLs The fileserver will generate a referral based on the set of FSLs
returned by these queries using the process described in returned by these queries using the process described in
Section 2.4.3. Section 2.8.3.
5.3. NSDB Operations and LDAP Referrals
The LDAPv3 protocol defines an LDAP referral mechanism that allows an
LDAP server to redirect an LDAP client. LDAPv3 defines two types of
LDAP referrals: the Referral type defined in Section 4.1.10 of
[RFC4511] and the SearchResultReference type defined in Section 4.5.3
of [RFC4511]. In both cases, the LDAP referral lists one or more
URIs for services that can be used to complete the operation. In the
remainder of this document, the term LDAP referral is used to
indicate either of these types.
If an NSDB operation results in an LDAP referral, the NSDB client MAY
follow the LDAP referral. An NSDB client's decision to follow an
LDAP referral is implementation and configuration dependent. For
example, an NSDB client might be configured to follow only those LDAP
referrals that were received over a secure channel, or only those
that target an NSDB that supports encrypted communication. If an
NSDB client chooses to follow an LDAP referral, the NSDB client MUST
process the LDAP referral and prevent looping as described in Section
4.1.10 of [RFC4511].
6. Security Considerations 6. Security Considerations
Both NFSv4/NFSv4.1 and LDAP provide security mechanisms. When used Both NFSv4/NFSv4.1 and LDAP provide security mechanisms. When used
in conjunction with the federated filesystem protocols described in in conjunction with the federated filesystem 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], which is built on the Specifically, the use of RPCSEC_GSS [RFC2203], which is built on the
GSS-API [RFC2743], is RECOMMENDED on all NFS connections between a GSS-API [RFC2743], is RECOMMENDED on all NFS connections between a
client and fileserver. The "Security Considerations" sections of the client and fileserver. The "Security Considerations" sections of the
the NFSv4 [3530bis] and NFSv4.1 [RFC5661] specifications contain the NFSv4 [3530bis] and NFSv4.1 [RFC5661] specifications contain
special considerations for the handling of GETATTR operations for the special considerations for the handling of GETATTR operations for the
fs_locations and fs_locations_info attributes. For all LDAP fs_locations and fs_locations_info attributes. For all LDAP
connections established by the federated filesystem protocols, the connections established by the federated filesystem protocols, the
use of TLS [RFC5246], as described in [RFC4513], is RECOMMENDED. use of TLS [RFC5246], as described in [RFC4513], is RECOMMENDED.
If an NSDB client chooses to follow an LDAP referral, the NSDB client
SHOULD authenticate the LDAP referral's target NSDB using the target
NSDB's credentials (not the credentials of the NSDB that generated
the LDAP referral). The NSDB client SHOULD NOT follow an LDAP
referral that targets an NSDB for which it does not know the NSDB's
credentials.
Within a federation, there are two types of components an attacker Within a federation, there are two types of components an attacker
may compromise: a fileserver and an NSDB. may compromise: a fileserver and an NSDB.
If an attacker compromises a fileserver, the attacker can interfere If an attacker compromises a fileserver, the attacker can interfere
with the client's filesystem I/O operations (e.g. by returning with the client's filesystem I/O operations (e.g. by returning
fictitious data in the response to a read request) or fabricating a fictitious data in the response to a read request) or fabricating a
referral. The attacker's abilities are the same regardless of referral. The attacker's abilities are the same regardless of
whether or not the federation protocols are in use. While the whether or not the federation protocols are in use. While the
federation protocols do not give the attacker additional federation protocols do not give the attacker additional
capabilities, they are additional targets for attack. The LDAP capabilities, they are additional targets for attack. The LDAP
skipping to change at page 48, line 7 skipping to change at page 49, line 33
It should be noted that the federation protocols do not directly It should be noted that the federation protocols do not directly
provide access to filesystem data. The federation protocols only provide access to filesystem data. The federation protocols only
provide a mechanism for building a namespace. All data transfers provide a mechanism for building a namespace. All data transfers
occur between a client and server just as they would if the occur between a client and server just as they would if the
federation protocols were not in use. As a result, the federation federation protocols were not in use. As a result, the federation
protocols do not require new user authentication and authorization protocols do not require new user authentication and authorization
mechanisms or require a fileserver to act as a proxy for a client. mechanisms or require a fileserver to act as a proxy for a client.
7. IANA Considerations 7. IANA Considerations
The LDAP attributes and object classes defined in this document are Using the process described in [RFC2578], one of the authors was
assigned object identifier (OID) values from the 1.3.6.1.4.1.31103.x assigned the Internet Private Enterprise Numbers range
range. This is an Internet Private Enterprise Numbers range and was 1.3.6.1.4.1.31103.x. Within this range, the subrange
assigned to the authors using the process described in [RFC2578]. 1.3.6.1.4.1.31103.1.x is permanently dedicated for use by the
federated file system protocols. All of the LDAP attributes and
object classes defined in this document are assigned object
identifier (OID) values within the range 1.3.6.1.4.1.31103.1.x.
In accordance with Section 3.4 and Section 4 of [RFC4520], the object In accordance with Section 3.4 and Section 4 of [RFC4520], the object
identifier descriptors defined in this document (listed below) will identifier descriptors defined in this document (listed below) will
be registered via the Expert Review process. be registered via the Expert Review process.
7.1. LDAP Descriptor Registration 7.1. LDAP Descriptor Registration
Subject: Request for LDAP Descriptor Registration Subject: Request for LDAP Descriptor Registration
Person & email address to contact for further information: See Person & email address to contact for further information: See
"Author/Change Controller" "Author/Change Controller"
Specification: draft-ietf-nfsv4-federated-fs-protocol Specification: draft-ietf-nfsv4-federated-fs-protocol
Author/Change Controller: [document authors] Author/Change Controller: [document authors]
Object Identifier: 1.3.6.1.4.1.31103.1.1 Object Identifier: 1.3.6.1.4.1.31103.1.1
Descriptor (short name): fedfsUuid Descriptor (short name): fedfsUuid
Usage: attribute type Usage: attribute type
skipping to change at page 56, line 42 skipping to change at page 58, line 30
NetApp NetApp
1601 Trapelo Rd, Suite 16 1601 Trapelo Rd, Suite 16
Waltham, MA 02451 Waltham, MA 02451
US US
Phone: +1 781-768-5359 Phone: +1 781-768-5359
Email: jlentini@netapp.com Email: jlentini@netapp.com
Craig Everhart Craig Everhart
NetApp NetApp
7301 Kit Creek Rd 800 Cranberry Woods Drive
Research Triangle Park, NC 27709 Cranberry Township, PA 16066
US US
Phone: +1 919-476-5320 Phone: +1 724-741-5101
Email: everhart@netapp.com Email: Craig.Everhart@netapp.com
Daniel Ellard Daniel Ellard
Raytheon BBN Technologies Raytheon BBN Technologies
10 Moulton Street 10 Moulton Street
Cambridge, MA 02138 Cambridge, MA 02138
US US
Phone: +1 617-873-8004 Phone: +1 617-873-8004
Email: dellard@bbn.com Email: dellard@bbn.com
Renu Tewari Renu Tewari
IBM Almaden IBM Almaden
650 Harry Rd 650 Harry Rd
San Jose, CA 95120 San Jose, CA 95120
US US
Email: tewarir@us.ibm.com Email: tewarir@us.ibm.com
Manoj Naik Manoj Naik
IBM Almaden IBM Almaden
 End of changes. 28 change blocks. 
89 lines changed or deleted 144 lines changed or added

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