draft-ietf-nfsv4-federated-fs-protocol-04.txt   draft-ietf-nfsv4-federated-fs-protocol-05.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: April 29, 2010 D. Ellard Expires: July 25, 2010 D. Ellard
BBN Technologies BBN Technologies
R. Tewari R. Tewari
M. Naik M. Naik
IBM Almaden IBM Almaden
October 26, 2009 January 21, 2010
NSDB Protocol for Federated Filesystems NSDB Protocol for Federated Filesystems
draft-ietf-nfsv4-federated-fs-protocol-04 draft-ietf-nfsv4-federated-fs-protocol-05
Abstract
This document describes a filesystem federation protocol that enables
file access and namespace traversal across collections of
independently administered fileservers. The protocol specifies a set
of interfaces by which fileservers with different administrators can
form a fileserver federation that provides a namespace composed of
the filesystems physically hosted on and exported by the constituent
fileservers.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 April 29, 2010. This Internet-Draft will expire on July 25, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document describes a filesystem federation protocol that enables described in the BSD License.
file access and namespace traversal across collections of
independently administered fileservers. The protocol specifies a set
of interfaces by which fileservers with different administrators can
form a fileserver federation that provides a namespace composed of
the filesystems physically hosted on and exported by the constituent
fileservers.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document may contain material from IETF Documents or IETF
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Contributions published or made publicly available before November
document are to be interpreted as described in [RFC2119]. 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Features and Concepts . . . . . . . . . . . . . . 5 2. Overview of Features and Concepts . . . . . . . . . . . . . . 5
2.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Fileset . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Fileset . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Fileset Name (FSN) . . . . . . . . . . . . . . . . . . . . 5 2.3. Fileset Name (FSN) . . . . . . . . . . . . . . . . . . . . 5
2.4. Fileset Location (FSL) . . . . . . . . . . . . . . . . . . 6 2.4. Fileset Location (FSL) . . . . . . . . . . . . . . . . . . 6
2.4.1. Mutual Consistency across Fileset Locations . . . . . 6 2.4.1. Mutual Consistency across Fileset Locations . . . . . 6
2.4.2. Caching of Fileset Locations . . . . . . . . . . . . . 7 2.4.2. Caching of Fileset Locations . . . . . . . . . . . . . 7
2.5. Namespace Database (NSDB) . . . . . . . . . . . . . . . . 8 2.4.3. Generating A Referral from Fileset Locations . . . . . 8
2.5. Namespace Database (NSDB) . . . . . . . . . . . . . . . . 9
2.6. Mount Points, Junctions and Referrals . . . . . . . . . . 9 2.6. Mount Points, Junctions and Referrals . . . . . . . . . . 9
2.7. Unified Namespace and the Root Fileset . . . . . . . . . . 9 2.7. Unified Namespace and the Root Fileset . . . . . . . . . . 10
2.8. Fileservers . . . . . . . . . . . . . . . . . . . . . . . 10 2.8. Fileservers . . . . . . . . . . . . . . . . . . . . . . . 10
2.9. File-access Clients . . . . . . . . . . . . . . . . . . . 10 2.9. File-access Clients . . . . . . . . . . . . . . . . . . . 10
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Creating a Fileset and its FSL(s) . . . . . . . . . . . . 10 3.1. Creating a Fileset and its FSL(s) . . . . . . . . . . . . 11
3.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 11 3.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 11
3.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 11 3.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 12
3.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 11 3.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 12
3.3. Example Use Cases for Fileset Annotations . . . . . . . . 12 3.3. Example Use Cases for Fileset Annotations . . . . . . . . 13
4. NSDB Configuration and Schema . . . . . . . . . . . . . . . . 13 4. NSDB Configuration and Schema . . . . . . . . . . . . . . . . 13
4.1. LDAP Configuration . . . . . . . . . . . . . . . . . . . . 13 4.1. LDAP Configuration . . . . . . . . . . . . . . . . . . . . 14
4.2. LDAP Schema . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. LDAP Schema . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. LDAP Attributes . . . . . . . . . . . . . . . . . . . 14 4.2.1. LDAP Attributes . . . . . . . . . . . . . . . . . . . 15
4.2.2. LDAP Objects . . . . . . . . . . . . . . . . . . . . . 30 4.2.2. LDAP Objects . . . . . . . . . . . . . . . . . . . . . 32
5. NSDB Operations . . . . . . . . . . . . . . . . . . . . . . . 33 5. NSDB Operations . . . . . . . . . . . . . . . . . . . . . . . 35
5.1. NSDB Operations for Administrators . . . . . . . . . . . . 34 5.1. NSDB Operations for Administrators . . . . . . . . . . . . 36
5.1.1. Create an FSN . . . . . . . . . . . . . . . . . . . . 35 5.1.1. Create an FSN . . . . . . . . . . . . . . . . . . . . 37
5.1.2. Delete an FSN . . . . . . . . . . . . . . . . . . . . 36 5.1.2. Delete an FSN . . . . . . . . . . . . . . . . . . . . 38
5.1.3. Create an FSL . . . . . . . . . . . . . . . . . . . . 36 5.1.3. Create an FSL . . . . . . . . . . . . . . . . . . . . 38
5.1.4. Delete an FSL . . . . . . . . . . . . . . . . . . . . 39 5.1.4. Delete an FSL . . . . . . . . . . . . . . . . . . . . 41
5.1.5. Update an FSL . . . . . . . . . . . . . . . . . . . . 39 5.1.5. Update an FSL . . . . . . . . . . . . . . . . . . . . 41
5.2. NSDB Operations for Fileservers . . . . . . . . . . . . . 40 5.2. NSDB Operations for Fileservers . . . . . . . . . . . . . 42
5.2.1. Lookup FSLs for an FSN . . . . . . . . . . . . . . . . 40 5.2.1. Lookup FSLs for an FSN . . . . . . . . . . . . . . . . 42
6. Security Considerations . . . . . . . . . . . . . . . . . . . 41 6. Security Considerations . . . . . . . . . . . . . . . . . . . 43
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
7.1. LDAP Descriptor Registration . . . . . . . . . . . . . . . 42 7.1. LDAP Descriptor Registration . . . . . . . . . . . . . . . 44
8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.1. Normative References . . . . . . . . . . . . . . . . . . . 48 9.1. Normative References . . . . . . . . . . . . . . . . . . . 50
9.2. Informational References . . . . . . . . . . . . . . . . . 49 9.2. Informative References . . . . . . . . . . . . . . . . . . 51
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 50 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
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 6, line 11 skipping to change at page 6, line 11
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.4. 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 be returned be used by a fileserver to decide which locations it will return to a
to a client. client.
All FSLs have the following attributes: All FSLs have the following attributes:
FslUuid: a 128-bit UUID, conforming to [RFC4122], that is used to FslUuid: a 128-bit UUID, conforming to [RFC4122], that is used to
uniquely identify an FSL. uniquely identify an FSL.
FsnUuid: the 128-bit UUID of the FSL's FSN. FsnUuid: the 128-bit UUID of the FSL's FSN.
NsdbName: the NSDB node that contains authoritative information NsdbName: the network location of the NSDB node that contains
for this FSL. authoritative information for this FSL.
NsdbContainerEntry: the location within the NSDB below which NsdbContainerEntry: the location within the NSDB below which
federation objects are stored. federation objects are stored.
FslHost: the network location of the host fileserver storing the FslHost: the network location of the host fileserver storing the
physical data physical data
FslTTL: the time in seconds during which the FSL may be cached FslTTL: the time in seconds during which the FSL may be cached
Annotations: optional name/value pairs that can be interpreted by Annotations: optional name/value pairs that can be interpreted by
skipping to change at page 8, line 22 skipping to change at page 8, line 22
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
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
FSLs. The fileserver will convert the FSL records to a referral
format understood by the client, such as an NFSv4 fs_locations
attribute or NFSv4.1 fs_locations_info attribute.
In order to give the client as many options as possible, the
fileserver SHOULD include the maximum possible number of FSL records
in a referral. However, the fileserver MAY omit some of the FSL
records from the referral. For example, the fileserver might omit an
FSL record with a different file access protocol from the one in use
between the fileserver and client, or the fileserver might omit an
FSL record because of limitations in the file access protocol's
referral format, or the fileserver might omit an FSL record based on
some other criteria.
For a given FSL record, the fileserver MAY convert or reduce the FSL
record's contents in a manner appropriate to the referral format.
For example, an NFS FSL record contains all the data necessary to
construct an NFSv4.1 fs_locations_info attribute, but an NFSv4.1
fs_locations_info attribute contains several pieces of information
that are not found in an NFSv4 fs_locations attribute. A fileserver
will construct entries in an NFSv4 fs_locations attribute using the
relevant contents of an NFS FSL record. Whenever the fileserver
converts or reduces FSL data, the fileserver SHOULD attempt to
maintain the original meaning where possible. For example, an NFS
FSL record contains the rank and order information that is included
in an NFSv4.1 fs_locations_info attribute (see NFSv4.1's
FSLI4BX_READRANK, FSLI4BX_READORDER, FSLI4BX_WRITERANK, and
FSLI4BX_WRITEORDER). While this rank and order information is not
explicitly expressible in an NFSv4 fs_locations attribute, the
fileserver can arrange the NFSv4 fs_locations attribute's locations
list base on the rank and order values.
2.5. Namespace Database (NSDB) 2.5. 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
skipping to change at page 10, line 28 skipping to change at page 11, line 14
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 their containing A fileset is the abstraction of a set of files and the directory tree
directory tree. The fileset abstraction is the fundamental unit of that contains them. The fileset abstraction is the fundamental unit
data management in the federation. This abstraction is implemented of data management in the federation. This abstraction is
by an actual directory tree whose root location is specified by a implemented by an actual directory tree whose root location is
fileset location (FSL). specified by a 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
creating a fileset requires any transformation of the files or the creating a fileset requires any transformation of the files or the
directory hierarchy. The only thing that is required by this process directory hierarchy. The only thing that is required by this process
is assigning the fileset a fileset name (FSN) and expressing the is assigning the fileset a fileset name (FSN) and expressing the
location of the implementation of the fileset as an FSL. location of the implementation of the fileset as an FSL.
There are many possible variations to this procedure, depending on There are many possible variations to this procedure, depending on
skipping to change at page 12, line 15 skipping to change at page 12, line 46
2. The fileserver does a local lookup to find the FSN of the target 2. The fileserver does a local lookup to find the FSN of the target
fileset. fileset.
3. Using the FSN, the fileserver finds the NSDB node responsible for 3. Using the FSN, the fileserver finds the NSDB node responsible for
the target FSN. the target FSN.
4. The fileserver contacts that NSDB node and asks for the set of 4. The fileserver contacts that NSDB node and asks for the set of
FSLs that implement the target FSN. The NSDB node responds with FSLs that implement the target FSN. The NSDB node responds with
a (possibly empty) set of FSLs. a (possibly empty) set of FSLs.
5. The fileserver converts one or more of the FSLs to the location
type used by the client (e.g., a Network File System (NFSv4)
fs_location, as described in [RFC3530]).
6. The fileserver redirects (in whatever manner is appropriate for
the client) the client to the location(s).
3.3. Example Use Cases for Fileset Annotations 3.3. Example Use Cases for Fileset Annotations
Fileset annotations MAY be used to convey additional attributes of a Fileset annotations MAY be used to convey additional attributes of a
fileset fileset
For example, fileset annotations can be used to define relationships For example, fileset annotations can be used to define relationships
between filesets that can be used by an auxiliary replication between filesets that can be used by an auxiliary replication
protocol. Consider the scenario where a fileset is created and protocol. Consider the scenario where a fileset is created and
mounted at some point in the namespace. A snapshot of the read-write mounted at some point in the namespace. A snapshot of the read-write
FSL of that fileset is taken periodically at different frequencies FSL of that fileset is taken periodically at different frequencies
skipping to change at page 15, line 44 skipping to change at page 16, line 31
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
4.2.1.2. fedfsNetAddr 4.2.1.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
a UTF-8 string and represent a network location in either IPv4, IPv6, a UTF-8 string and represent a network location in either IPv4, IPv6,
or DNS host name notation. The format is the same as that specified or DNS name notation.
for an fs_location4's server array elements in section 11.9 of
[NFSv4.1]. An IPv4 address MUST be represented using the format defined in
Section 4.2.3.3 of [RPC-NETID]. An IPv6 address MUST be represented
using the format defined in Section 4.2.3.4 of [RPC-NETID]. For both
IPv4 and IPv6 addresses, the trailing ".p1.p2" suffix that represents
the transport port number MAY be omitted.
A DNS name MUST be represented using a fully qualified domain name
followed by an optional ":port" suffix where "port" is the UTF-8
string representing the transport port number's decimal value. A
system (i.e. fileserver or administrative host) SHOULD resolve the
fully qualified domain name to a network address using the system's
standard resolution mechanisms.
If the optional port suffix is omitted, subtypes of this attribute
define a default transport port number.
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.2 NAME 'fedfsNetAddr' /// 1.3.6.1.4.1.31103.1.2 NAME 'fedfsNetAddr'
/// DESC 'The network name of a host or service' /// DESC 'The network name of a host or service'
/// SUP name /// SUP name
/// SINGLE-VALUE /// SINGLE-VALUE
skipping to change at page 16, line 42 skipping to change at page 17, line 42
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
4.2.1.4. fedfsNsdbName 4.2.1.4. fedfsNsdbName
A fedfsNsdbName is the NSDB component of an FSN. A fedfsNsdbName is the NSDB component of an FSN.
The fedfsNsdbName attribute is a subclass of fedfsNetAddr, with the It MUST be a UTF-8 string containing a DNS name. The DNS name MUST
same encoding rules. be represented using a fully qualified domain name followed by an
optional ":port" suffix where "port" is the UTF-8 string representing
the transport port number's decimal value. A system (i.e. fileserver
or administrative host) SHOULD resolve the fully qualified domain
name to a network address using the system's standard resolution
mechanisms.
If a transport port number is omitted, the standard LDAP port number,
389, SHOULD be assumed.
FSNs are immutable and invariant. The attributes of an FSN,
including the fedfsNsdbName, are expected to remain constant.
Therefore, a fedfsNsdbName SHOULD NOT contain a network address, such
as an IPv4 or IPv6 address, as this would indefinitely assign the
network address.
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.4 NAME 'fedfsNsdbName' /// 1.3.6.1.4.1.31103.1.4 NAME 'fedfsNsdbName'
/// DESC 'The NSDB node component of an FSN' /// DESC 'The NSDB node component of an FSN'
/// SUP fedfsNetAddr /// SUP name
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
4.2.1.5. fedfsNsdbContainerEntry 4.2.1.5. fedfsNsdbContainerEntry
A fedfsNsdbContainerEntry stores the DN of the NCE. The DN MUST be A fedfsNsdbContainerEntry stores the DN of the NCE. The DN MUST be
encoded using the <distinguishedName> rule defined in [RFC4514]. A encoded using the <distinguishedName> rule defined in [RFC4514]. A
skipping to change at page 18, line 20 skipping to change at page 19, line 33
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
4.2.1.7. fedfsFslHost 4.2.1.7. fedfsFslHost
A fedfsFslHost is the host component of an FSL. A fedfsFslHost is the host component of an FSL.
The fedfsFslHost attribute is a subclass of fedfsNetAddr, with the The fedfsFslHost attribute is a subclass of fedfsNetAddr, with the
same encoding rules. same encoding rules. If a transport port number is omitted, a
standard port number based on the type of FSL should be assumed. For
an NFS FSL, the standard NFS port number, 2049, SHOULD be assumed.
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.7 NAME 'fedfsFslHost' /// 1.3.6.1.4.1.31103.1.7 NAME 'fedfsFslHost'
/// DESC 'Service location for a fileserver' /// DESC 'Service location for a fileserver'
/// SUP fedfsNetAddr /// SUP fedfsNetAddr
skipping to change at page 41, line 21 skipping to change at page 43, line 21
fedfsNfsFsl" restricts the results to only NFS FSLs. fedfsNfsFsl" restricts the results to only NFS FSLs.
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 can present the search results in a format useful to The fileserver will generate a referral based on the set of FSLs
the type of the client on whose behalf the fileserver is performing returned by these queries using the process described in
the request. For an NFS client, the fileserver can use the search Section 2.4.3.
results to construct an NFSv4 fs_locations list or NFSv4.1
fs_locations_info list.
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 [RFC3530] and NFSv4.1 [NFSv4.1] specifications contain the NFSv4 [RFC3530] and NFSv4.1 [NFSv4.1] specifications contain
skipping to change at page 42, line 14 skipping to change at page 44, line 12
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
protocol described in Section 5.2 SHOULD be secured using the methods protocol described in Section 5.2 SHOULD be secured using the methods
described above to defeat attacks on a fileserver via this channel. described above to defeat attacks on a fileserver via this channel.
If an attacker compromises an NSDB, the attacker will be able to If an attacker compromises an NSDB, the attacker will be able to
forge FSL information and thus poison the fileserver's referral forge FSL information and thus poison the fileserver's referral
information. Therefore an NSDB should be as secure as the information. Therefore an NSDB should be as secure as the
fileservers which query it. The LDAP protocol described in fileservers which query it. The LDAP operations described in
Section 5.1 SHOULD be secured using the methods described above to Section 5 SHOULD be secured using the methods described above to
defeat attacks on an NSDB via this channel. defeat attacks on an NSDB via this channel.
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.
skipping to change at page 46, line 4 skipping to change at page 47, line 45
Object Identifier: 1.3.6.1.4.1.31103.1.1002 Object Identifier: 1.3.6.1.4.1.31103.1.1002
Descriptor (short name): fedfsFsl Descriptor (short name): fedfsFsl
Usage: object class Usage: object class
Object Identifier: 1.3.6.1.4.1.31103.1.1003 Object Identifier: 1.3.6.1.4.1.31103.1.1003
Descriptor (short name): fedfsNfsFsl Descriptor (short name): fedfsNfsFsl
Usage: object class Usage: object class
8. Glossary 8. 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.
Federation: A set of server collections and singleton servers that Federation: A set of server collections and singleton servers that
use a common set of interfaces and protocols in order to provide use a common set of interfaces and protocols in order to provide
to their clients a federated namespace accessible through a to their clients a federated namespace accessible through a
filesystem access protocol. filesystem access protocol.
Fileserver: A server exporting a filesystem via a network filesystem Fileserver: A server exporting a filesystem via a network filesystem
access protocol. access protocol.
Fileset: The abstraction of a set of files and their containing Fileset: The abstraction of a set of files and the directory tree
directory tree. A fileset is the fundamental unit of data that contains them. A fileset is the fundamental unit of data
management in the federation. management in the federation.
Note that all files within a fileset are descendants of one Note that all files within a fileset are descendants of one
directory, and that filesets do not span filesystems. directory, and that filesets do not span filesystems.
Filesystem: A self-contained unit of export for a fileserver, and Filesystem: A self-contained unit of export for a fileserver, and
the mechanism used to implement filesets. The fileset does not the mechanism used to implement filesets. The fileset does not
need to be rooted at the root of the filesystem, nor at the export need to be rooted at the root of the filesystem, nor at the export
point for the filesystem. point for the filesystem.
A single filesystem MAY implement more than one fileset, if the A single filesystem MAY implement more than one fileset, if the
client protocol and the fileserver permit this. client protocol and the fileserver permit this.
Filesystem access protocol: A network filesystem access protocol Filesystem Access Protocol: A network filesystem access protocol
such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [RFC3530], or such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [RFC3530], or CIFS
CIFS. (Common Internet File System) [MS-SMB] [MS-SMB2] [MS-CIFS].
FSL (Fileset location): The location of the implementation of a FSL (Fileset Location): The location of the implementation of a
fileset at a particular moment in time. A FSL MUST be something fileset at a particular moment in time. An FSL MUST be something
that can be translated into a protocol-specific description of a that can be translated into a protocol-specific description of a
resource that a client can access directly, such as a fs_location resource that a client can access directly, such as an fs_location
(for NFSv4), or share name (for CIFS). Note that not all FSLs (for NFSv4), or share name (for CIFS). Note that not all FSLs
need to be explicitly exported as long as they are contained need to be explicitly exported as long as they are contained
within an exported path on the fileserver. within an exported path on the fileserver.
FSN (Fileset name): A platform-independent and globally unique name FSN (Fileset Name): A platform-independent and globally unique name
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.
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 48, line 6 skipping to change at page 50, line 6
The namespace provided by a server collection could be part of the The namespace provided by a server collection could be part of the
federated namespace. federated namespace.
Singleton Server: A server collection containing only one server; a Singleton Server: A server collection containing only one server; a
stand-alone fileserver. stand-alone fileserver.
9. References 9. References
9.1. Normative References 9.1. Normative References
[NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4 [NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "Network File
Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (work System (NFS) Version 4 Minor Version 1 Protocol",
in progress), December 2008. RFC 5661, January 2010.
[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.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
skipping to change at page 49, line 23 skipping to change at page 51, line 23
(LDAP): Schema for User Applications", RFC 4519, (LDAP): Schema for User Applications", RFC 4519,
June 2006. June 2006.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 4520, June 2006. Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
9.2. Informational References [RPC-NETID]
Eisler, M., "IANA Considerations for RPC Net Identifiers
and Universal Address Formats",
draft-ietf-nfsv4-rpc-netid-06 (work in progress),
January 2009.
9.2. Informative References
[AFS] Howard, J., "An Overview of the Andrew File System", [AFS] Howard, J., "An Overview of the Andrew File System",
Proceeding of the USENIX Winter Technical Conference , Proceeding of the USENIX Winter Technical Conference ,
1988. 1988.
[FEDFS-ADMIN] [FEDFS-ADMIN]
Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Naik, "Administration Protocol for Federated Filesystems", Naik, "Administration Protocol for Federated Filesystems",
draft-ietf-nfsv4-federated-fs-admin (Work In Progress), draft-ietf-nfsv4-federated-fs-admin (Work In Progress),
2009. 2009.
[FEDFS-DNS-SRV] [FEDFS-DNS-SRV]
Everhart, C., Adamson, W., and J. Zhang, "Using DNS SRV to Everhart, C., Adamson, W., and J. Zhang, "Using DNS SRV to
Specify a Global File Name Space with NFS version 4", Specify a Global File Name Space with NFS version 4",
draft-ietf-nfsv4-federated-fs-dns-srv-namespace (Work In draft-ietf-nfsv4-federated-fs-dns-srv-namespace (Work In
Progress), 2009. Progress), 2009.
[FEDFS-REQTS] [FEDFS-REQTS]
Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Naik, "Requirements for Federated File Systems", Naik, "Requirements for Federated File Systems", RFC 5716,
draft-ietf-nfsv4-federated-fs-reqts (Work In Progress), January 2010.
2009.
[MS-CIFS] Microsoft Corporation, "Common Internet File System (CIFS)
Protocol Specification", MS-CIFS 2.0, November 2009.
[MS-SMB] Microsoft Corporation, "Server Message Block (SMB)
Protocol Specification", MS-SMB 17.0, November 2009.
[MS-SMB2] Microsoft Corporation, "Server Message Block (SMB) Version
2 Protocol Specification", MS-SMB2 19.0, November 2009.
[NFSv4.1-XDR] [NFSv4.1-XDR]
Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4 Shepler, S., Eisler, M., and D. Noveck, "Network File
Minor Version 1 XDR Description", System (NFS) Version 4 Minor Version 1 External Data
draft-ietf-nfsv4-minorversion1-dot-x-12 (work in Representation Standard (XDR) Description", RFC 5662,
progress), December 2008. January 2010.
[RFC1094] Nowicki, B., "NFS: Network File System Protocol [RFC1094] Nowicki, B., "NFS: Network File System Protocol
specification", RFC 1094, March 1989. specification", RFC 1094, March 1989.
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
Version 3 Protocol Specification", RFC 1813, June 1995. Version 3 Protocol Specification", RFC 1813, June 1995.
[RFC3254] Alvestrand, H., "Definitions for talking about [RFC3254] Alvestrand, H., "Definitions for talking about
directories", RFC 3254, April 2002. directories", RFC 3254, April 2002.
 End of changes. 37 change blocks. 
109 lines changed or deleted 204 lines changed or added

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