draft-ietf-nfsv4-federated-fs-protocol-15.txt   rfc7532.txt 
NFSv4 Working Group J. Lentini Internet Engineering Task Force (IETF) J. Lentini
Internet-Draft NetApp Request for Comments: 7532 NetApp
Intended status: Standards Track D. Ellard Category: Standards Track R. Tewari
Expires: June 15, 2013 Raytheon BBN Technologies ISSN: 2070-1721 IBM Almaden
R. Tewari
IBM Almaden
C. Lever, Ed. C. Lever, Ed.
Oracle Corporation Oracle Corporation
December 12, 2012 March 2015
NSDB Protocol for Federated Filesystems Namespace Database (NSDB) Protocol for Federated File Systems
draft-ietf-nfsv4-federated-fs-protocol-15
Abstract Abstract
This document describes a filesystem federation protocol that enables This document describes a file system federation protocol that
file access and namespace traversal across collections of enables file access and namespace traversal across collections of
independently administered fileservers. The protocol specifies a set independently administered fileservers. The protocol specifies a set
of interfaces by which fileservers 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 file systems physically hosted on and exported by the constituent
fileservers. fileservers.
Requirements Language Status of This Memo
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
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on June 15, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7532.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Copyright (c) 2015 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
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction ....................................................4
2. Overview of Features and Concepts . . . . . . . . . . . . . . 6 1.1. Requirements Language ......................................5
2.1. File-access Protocol . . . . . . . . . . . . . . . . . . . 6 2. Overview of Features and Concepts ...............................5
2.2. File-access Client . . . . . . . . . . . . . . . . . . . . 6 2.1. File-Access Protocol .......................................5
2.3. Fileserver . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. File-Access Client .........................................5
2.4. Referral . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Fileserver .................................................5
2.5. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Referral ...................................................5
2.6. Fileset . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5. Namespace ..................................................6
2.7. Fileset Name (FSN) . . . . . . . . . . . . . . . . . . . . 7 2.6. Fileset ....................................................6
2.8. Fileset Location (FSL) . . . . . . . . . . . . . . . . . . 8 2.7. Fileset Name (FSN) .........................................6
2.8.1. The NFS URI scheme . . . . . . . . . . . . . . . . . . 9 2.8. Fileset Location (FSL) .....................................7
2.8.2. Mutual Consistency across Fileset Locations . . . . . 10 2.8.1. The NFS URI Scheme ..................................8
2.8.3. Caching of Fileset Locations . . . . . . . . . . . . . 11 2.8.2. Mutual Consistency across Fileset Locations ........10
2.8.4. Generating A Referral from Fileset Locations . . . . . 12 2.8.3. Caching of Fileset Locations .......................11
2.9. Namespace Database (NSDB) . . . . . . . . . . . . . . . . 13 2.8.4. Generating a Referral from Fileset Locations .......12
2.9.1. NSDB Client . . . . . . . . . . . . . . . . . . . . . 14 2.9. Namespace Database (NSDB) .................................13
2.10. Junctions and Referrals . . . . . . . . . . . . . . . . . 14 2.9.1. NSDB Client ........................................14
2.11. Unified Namespace and the Root Fileset . . . . . . . . . . 15 2.10. Junctions and Referrals ..................................14
2.12. UUID Considerations . . . . . . . . . . . . . . . . . . . 15 2.11. Unified Namespace and the Root Fileset ...................15
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.12. UUID Considerations ......................................15
3.1. Creating a Fileset and its FSL(s) . . . . . . . . . . . . 16 3. Examples .......................................................16
3.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 17 3.1. Creating a Fileset and Its FSL(s) .........................16
3.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 17 3.1.1. Creating a Fileset and an FSN ......................17
3.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 17 3.1.2. Adding a Replica of a Fileset ......................17
3.3. Example Use Cases for Fileset Annotations . . . . . . . . 18 3.2. Junction Resolution .......................................17
4. NSDB Configuration and Schema . . . . . . . . . . . . . . . . 19 3.3. Example Use Cases for Fileset Annotations .................18
4.1. LDAP Configuration . . . . . . . . . . . . . . . . . . . . 19 4. NSDB Configuration and Schema ..................................19
4.2. LDAP Schema . . . . . . . . . . . . . . . . . . . . . . . 21 4.1. LDAP Configuration ........................................19
4.2.1. LDAP Attributes . . . . . . . . . . . . . . . . . . . 23 4.2. LDAP Schema ...............................................21
4.2.2. LDAP Object Classes . . . . . . . . . . . . . . . . . 37 4.2.1. LDAP Attributes ....................................23
5. NSDB Operations . . . . . . . . . . . . . . . . . . . . . . . 40 4.2.2. LDAP Object Classes ................................38
5.1. NSDB Operations for Administrators . . . . . . . . . . . . 41 5. NSDB Operations ................................................42
5.1.1. Create an FSN . . . . . . . . . . . . . . . . . . . . 41 5.1. NSDB Operations for Administrators ........................43
5.1.2. Delete an FSN . . . . . . . . . . . . . . . . . . . . 42 5.1.1. Create an FSN ......................................43
5.1.3. Create an FSL . . . . . . . . . . . . . . . . . . . . 43 5.1.2. Delete an FSN ......................................44
5.1.4. Delete an FSL . . . . . . . . . . . . . . . . . . . . 46 5.1.3. Create an FSL ......................................44
5.1.5. Update an FSL . . . . . . . . . . . . . . . . . . . . 47 5.1.4. Delete an FSL ......................................47
5.2. NSDB Operations for Fileservers . . . . . . . . . . . . . 48 5.1.5. Update an FSL ......................................48
5.2.1. NSDB Container Entry (NCE) Enumeration . . . . . . . . 48 5.2. NSDB Operations for Fileservers ...........................49
5.2.2. Lookup FSLs for an FSN . . . . . . . . . . . . . . . . 48 5.2.1. NSDB Container Entry (NCE) Enumeration .............49
5.3. NSDB Operations and LDAP Referrals . . . . . . . . . . . . 49 5.2.2. Lookup FSLs for an FSN .............................49
6. Security Considerations . . . . . . . . . . . . . . . . . . . 50 5.3. NSDB Operations and LDAP Referrals ........................50
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 6. Security Considerations ........................................51
7.1. Registry for the fedfsAnnotation Key Namespace . . . . . . 51 7. IANA Considerations ............................................52
7.2. Registry for FedFS Object Identifiers . . . . . . . . . . 51 7.1. Registry for the fedfsAnnotation Key Namespace ............52
7.3. LDAP Descriptor Registration . . . . . . . . . . . . . . . 54 7.2. Registry for FedFS Object Identifiers .....................52
7.3. LDAP Descriptor Registration ..............................55
8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 8. Glossary .......................................................58
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 9. References .....................................................60
9.1. Normative References . . . . . . . . . . . . . . . . . . . 60 9.1. Normative References ......................................60
9.2. Informative References . . . . . . . . . . . . . . . . . . 61 9.2. Informative References ....................................62
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 62 Acknowledgments ...................................................64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63 Authors' Addresses ................................................65
1. Introduction 1. Introduction
A federated filesystem enables file access and namespace traversal in A federated file system enables file access and namespace traversal
a uniform, secure and consistent manner across multiple independent in a uniform, secure, and consistent manner across multiple
fileservers within an enterprise or across multiple enterprises. independent 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 file
filesystems. Each federated filesystem's namespace is composed of systems. Each federated file system's namespace is composed of the
the filesystems physically hosted on and exported by the federation's file systems physically hosted on and exported by the federation's
fileservers. A federation comprises a common namespace across all fileservers. A federation comprises a common namespace across all
its fileservers. A federation can project multiple namespaces and its fileservers. A federation can project multiple namespaces and
enable clients to traverse each one. A federation can contain an enable clients to traverse each one. A federation can contain an
arbitrary number of namespace repositories, each belonging to a arbitrary number of namespace repositories, each belonging to a
different administrative entity, and each rendering a part of the different administrative entity and each rendering a part of the
namespace. A federation might also have an arbitrary number of namespace. A federation might also have an arbitrary number of
administrative entities responsible for administering disjoint administrative entities responsible for administering disjoint
subsets of the fileservers. subsets of the fileservers.
Traditionally, building a namespace that spans multiple fileservers Traditionally, building a namespace that spans multiple fileservers
has been difficult for two reasons. First, the fileservers that has been difficult for two reasons. First, the fileservers that
export pieces of the namespace are often not in the same export pieces of the namespace are often not in the same
administrative domain. Second, there is no standard mechanism for administrative domain. Second, there is no standard mechanism for
the fileservers to cooperatively present the namespace. Fileservers the fileservers to cooperatively present the namespace. Fileservers
may provide proprietary management tools and in some cases an may provide proprietary management tools, and in some cases, an
administrator may be able to use the proprietary tools to build a administrator may be able to use the proprietary tools to build a
shared namespace out of the exported filesystems. However, relying shared namespace out of the exported file systems. However, relying
on vendor-specific proprietary tools does not work in larger on vendor-specific proprietary tools does not work in larger
enterprises or when collaborating across enterprises because the enterprises or when collaborating across enterprises because the
fileservers are likely to be from multiple vendors or use different fileservers are likely to be from multiple vendors or use different
software versions, each with their own namespace protocols, with no software versions, each with their own namespace protocols, with no
common mechanism to manage the namespace or exchange namespace common mechanism to manage the namespace or exchange namespace
information. information.
The federated filesystem protocols in this document define how to The federated file system protocols in this document define how to
construct a namespace accessible by an NFSv4.0 [3530bis], NFSv4.1 construct a namespace accessible by a Network File System (NFS)
[RFC5661] or newer client and have been designed to accommodate other version 4.0 [RFC7530], NFSv4.1 [RFC5661], or newer client and have
file access protocols in the future. been designed to accommodate other file-access protocols in the
future.
The requirements for federated filesystems are described in The requirements for federated file systems 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 [RFC7533]. The mechanism for discovering the root of a
of a federated namespace is described in [RFC6641]. federated namespace is described in [RFC6641].
In the rest of the document, the term fileserver denotes a fileserver In the rest of the document, the term "fileserver" denotes a
that is part of a federation. fileserver that is part of a federation.
1.1. 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].
2. Overview of Features and Concepts 2. Overview of Features and Concepts
2.1. File-access Protocol 2.1. File-Access Protocol
A file-access protocol is a network protocol for accessing data. The A file-access protocol is a network protocol for accessing data. The
NFSv4.0 protocol [3530bis] is an example of a file-access protocol. NFSv4.0 protocol [RFC7530] is an example of a file-access protocol.
2.2. File-access Client 2.2. File-Access Client
File-access clients are standard off-the-shelf network attached File-access clients are standard, off-the-shelf network-attached
storage (NAS) clients that communicate with fileservers using a storage (NAS) clients that communicate with fileservers using a
standard file-access protocol. standard file-access protocol.
2.3. Fileserver 2.3. Fileserver
Fileservers are servers that store physical fileset data, or refer Fileservers are servers that store physical fileset data or refer
file-access clients to other fileservers. A fileserver provides file-access clients to other fileservers. A fileserver provides
access to its shared filesystem data via a file-access protocol. A access to its shared file system data via a file-access protocol. A
fileserver may be implemented in a number of different ways, fileserver may be implemented in a number of different ways,
including a single system, a cluster of systems, or some other including a single system, a cluster of systems, or some other
configuration. configuration.
2.4. Referral 2.4. Referral
A referral is a mechanism by which a fileserver redirects a file- A referral is a mechanism by which a fileserver redirects a file-
access client to a different fileserver or export. The exact access client to a different fileserver or export. The exact
information contained in a referral varies from one file-access information contained in a referral varies from one file-access
protocol to another. The NFSv4.0 protocol, for example, defines the protocol to another. The NFSv4.0 protocol, for example, defines the
fs_locations attribute for returning referral information to NFSv4.0 fs_locations attribute for returning referral information to NFSv4.0
clients. The NFSv4.1 protocol introduces the fs_locations_info clients. The NFSv4.1 protocol introduces the fs_locations_info
attribute that can return richer referral information to its clients. attribute that can return richer referral information to its clients.
NFSv4.1 fileservers may use either attribute during a referral. Both NFSv4.1 fileservers may use either attribute during a referral. Both
attributes are defined in [RFC5661]. attributes are defined in [RFC5661].
2.5. Namespace 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 any file-access client via the same path in a common filesystem to any file-access client via the same path in a common file system
namespace. This should be achieved with minimal or zero namespace. This should be achieved with minimal or zero
configuration on file-access clients. In particular, updates to the configuration on file-access clients. In particular, updates to the
common namespace should not require configuration changes to any common namespace should not require configuration changes to any
file-access client. file-access client.
Filesets, which are the unit of data management, are a set of files Filesets, which are the units of data management, are a set of files
and directories. From the perspective of file-access clients, the and directories. From the perspective of file-access clients, the
common namespace is constructed by mounting filesets that are common namespace is constructed by mounting filesets that are
physically located on different fileservers. The namespace, which is physically located on different fileservers. The namespace, which is
defined in terms of fileset names and locations, is stored in a set defined in terms of fileset names and locations, is stored in a set
of namespace repositories, each managed by an administrative entity. of namespace repositories, each managed by an administrative entity.
The namespace schema defines the model used for populating, The namespace schema defines the model used for populating,
modifying, and querying the namespace repositories. It is not modifying, and querying the namespace repositories. It is not
required by the federation that the namespace be common across all required by the federation that the namespace be common across all
fileservers. It should be possible to have several independently fileservers. It should be possible to have several independently
rooted namespaces. rooted namespaces.
2.6. Fileset 2.6. Fileset
A fileset is loosely defined as a set of files and the directory tree A fileset is loosely defined as a set of files and the directory tree
that contains them. The fileset abstraction is the basic unit of that contains them. The fileset abstraction is the basic unit of
data management. Depending on the configuration, a fileset may be data management. Depending on the configuration, a fileset may be
anything from an individual directory of an exported filesystem to an anything from an individual directory of an exported file system to
entire exported filesystem on a fileserver. an entire exported file system on a fileserver.
2.7. 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 a federation. After an FSN is created, is considered unique across a federation. After an FSN is created,
it is associated with one or more fileset locations (FSLs) on one or it is associated with one or more fileset locations (FSLs) on one or
more fileservers. more fileservers.
An FSN consists of: An FSN consists of:
skipping to change at page 7, line 42 skipping to change at page 7, line 20
FsnUuid: a UUID (universally unique identifier), conforming to FsnUuid: a UUID (universally unique identifier), conforming to
[RFC4122], that is used to uniquely identify an FSN. [RFC4122], that is used to uniquely identify an FSN.
FsnTTL: the time-to-live of the FSN's FSL information, in FsnTTL: the time-to-live of the FSN's FSL information, in
seconds. Fileservers MUST NOT use cached FSL records after the seconds. Fileservers MUST NOT use cached FSL records after the
parent FSN's FsnTTL has expired. An FsnTTL value of zero parent FSN's FsnTTL has expired. An FsnTTL value of zero
indicates that fileservers MUST NOT cache the results of indicates that fileservers MUST NOT cache the results of
resolving this FSN. resolving this FSN.
The NsdbName is not physically stored as an attribute of the record. The NsdbName is not physically stored as an attribute of the record.
The NsdbName is obvious to any client that accesses an NSDB, and is The NsdbName is obvious to any client that accesses an NSDB and is
indeed authenticated in cases where TLS security is in effect. indeed authenticated in cases where Transport Layer Security (TLS) is
in effect.
The FsnUuid and NsdbName values never change during an FSN's The FsnUuid and NsdbName values never change during an FSN's
lifetime. However, an FSN's FSL information can change over time, lifetime. However, an FSN's FSL information can change over time and
and is typically cached on fileservers for performance. More detail is typically cached on fileservers for performance. More detail on
on FSL caching is provided in Section 2.8.3. FSL caching is provided in Section 2.8.3.
An FSN record may also contain: An FSN record may also contain:
Annotations: name/value pairs that can be interpreted by a Annotations: name/value pairs that can be interpreted by a
fileserver. The semantics of this field are not defined by fileserver. The semantics of this field are not defined by
this document. These tuples are intended to be used by higher- this document. These tuples are intended to be used by higher-
level protocols. level protocols.
Descriptions: text descriptions. The semantics of this field are Descriptions: text descriptions. The semantics of this field are
not defined by this document. not defined by this document.
2.8. Fileset Location (FSL) 2.8. Fileset Location (FSL)
An FSL describes one physical location where a complete copy of the An FSL describes one physical location where a complete copy of the
fileset's data resides. An FSL contains generic and type specific fileset's data resides. An FSL contains generic and type-specific
information which together describe how to access the fileset data at information that together describe how to access the fileset data at
this location. An FSL's attributes can be used by a fileserver to this location. An FSL's attributes can be used by a fileserver to
decide which locations it will return to a file-access client. decide which locations it will return to a file-access client.
An FSL consists of: An FSL consists of:
FslUuid: a UUID, conforming to [RFC4122], that is used to FslUuid: a UUID, conforming to [RFC4122], that is used to
uniquely identify an FSL. uniquely identify an FSL.
FsnUuid: the UUID of the FSL's FSN. FsnUuid: the UUID of the FSL's FSN.
skipping to change at page 9, line 5 skipping to change at page 8, line 37
In addition to the attributes defined above, an FSL record contains In addition to the attributes defined above, an FSL record contains
attributes that allow a fileserver to construct referrals. For each attributes that allow a fileserver to construct referrals. For each
file-access protocol, a corresponding FSL record subtype is defined. file-access protocol, a corresponding FSL record subtype is defined.
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 one of the NFSv4 referral attributes information suitable for use in one of the NFSv4 referral attributes
(e.g., fs_locations or fs_locations_info, described in [RFC5661]). (e.g., fs_locations or fs_locations_info, described in [RFC5661]).
Section 4.2.2.4 describes the contents of an NFS FSL record. Section 4.2.2.4 describes the contents of an NFS FSL record.
A fileset also may be accessible by file-access protocols other than A fileset may also be accessible by file-access protocols other than
NFS. The contents and format of such FSL subtypes are not defined in NFS. The contents and format of such FSL subtypes are not defined in
this document. this document.
2.8.1. The NFS URI scheme 2.8.1. The NFS URI Scheme
To capture the location of an NFSv4 fileset, we extend the NFS URL To capture the location of an NFSv4 fileset, we extend the NFS URL
scheme specified in [RFC2224]. This extension follows rules for scheme specified in [RFC2224]. This extension follows rules for
defining Uniform Resource Identifier schemes (see [RFC3986]). In the defining Uniform Resource Identifier schemes (see [RFC3986]). In the
following text, we refer to this extended NFS URL scheme as an NFS following text, we refer to this extended NFS URL scheme as an NFS
URI. URI.
An NFS URI MUST contain both an authority and a path component. It An NFS URI MUST contain both an authority and a path component. It
MUST NOT contain a query component or a fragment component. Use of MUST NOT contain a query component or a fragment component. Use of
the familiar "nfs" scheme name is retained. the familiar "nfs" scheme name is retained.
2.8.1.1. The NFS URI authority component 2.8.1.1. The NFS URI Authority Component
The rules for encoding the authority component of a generic URI are The rules for encoding the authority component of a generic URI are
specified in section 3.2 of [RFC3986]. The authority component of an specified in section 3.2 of [RFC3986]. The authority component of an
NFS URI MUST contain the host subcomponent. For globally-scoped NFS NFS URI MUST contain the host subcomponent. For globally scoped NFS
URIs, a hostname used in such URIs SHOULD be a fully qualified domain URIs, a hostname used in such URIs SHOULD be a fully qualified domain
name. See section 3.2.2 of [RFC3986] for rules on encoding non-ASCII name. See section 3.2.2 of [RFC3986] for rules on encoding non-ASCII
characters in hostnames. characters in hostnames.
An NFS URI MAY contain a port subcomponent as described in section An NFS URI MAY contain a port subcomponent as described in section
3.2.3 of [RFC3986]. If this subcomponent is missing, a port value of 3.2.3 of [RFC3986]. If this subcomponent is missing, a port value of
2049 is assumed, as specified in [3530bis], Section 3.1. 2049 is assumed, as specified in [RFC7530], Section 3.1.
2.8.1.2. The NFS URI path component 2.8.1.2. The NFS URI Path Component
The rules for encoding the path component of a generic URI are The rules for encoding the path component of a generic URI are
specified in section 3.3 of [RFC3986]. specified in Section 3.3 of [RFC3986].
According to sections 5 and 6 of [RFC2224], NFS URLs specify a According to Sections 5 and 6 of [RFC2224], NFS URLs specify a
pathname relative to an NFS fileserver's "public filehandle." pathname relative to an NFS fileserver's public filehandle. However,
However, NFSv4 fileservers do not expose a "public filehandle." NFSv4 fileservers do not expose a public filehandle. Instead, NFSv4
Instead, NFSv4 pathnames contained in an NFS URI are evaluated pathnames contained in an NFS URI are evaluated relative to the
relative to the pseudoroot of the fileserver identified in the URI's pseudoroot of the fileserver identified in the URI's authority
authority component. component.
Each component of an NFSv4 pathname is represented as a component4 Each component of an NFSv4 pathname is represented as a component4
string (see Section 3.2, "Basic Data Types" of [RFC5661]). The string (see Section 3.2, "Basic Data Types", of [RFC5661]). The
component4 elements of an NFSv4 pathname are encoded as path segments component4 elements of an NFSv4 pathname are encoded as path segments
in an NFS URI. NFSv4 pathnames MUST be expressed in an NFS URI as an in an NFS URI. NFSv4 pathnames MUST be expressed in an NFS URI as an
absolute path. An NFS URI path component MUST NOT be empty. The NFS absolute path. An NFS URI path component MUST NOT be empty. The NFS
URI path component starts with a slash ("/") character, followed by URI path component starts with a slash ("/") character, followed by
one or more path segments which each start with a slash ("/") one or more path segments that each start with a slash ("/")
character [RFC3986]. character [RFC3986].
Therefore, a double slash always follows the authority component of Therefore, a double slash always follows the authority component of
an NFS URI. For example, the NFSv4 pathname "/" is represented by an NFS URI. For example, the NFSv4 pathname "/" is represented by
two slash ("/") characters following an NFS URI's authority two slash ("/") characters following an NFS URI's authority
component. component.
The component4 elements of an NFSv4 pathname MUST be prepared using The component names of an NFSv4 pathname MUST be prepared using the
the component4 rules defined in Chapter 12 "Internationalization" of component name rules defined in Section 12 ("Internationalization")
[3530bis] prior to encoding the path component of an NFS URI. As of [RFC7530] prior to encoding the path component of an NFS URI. As
specified in [RFC3986], any non-ASCII characters and any URI-reserved specified in [RFC3986], any non-ASCII characters and any URI-reserved
characters, such as the slash ("/") character, contained in a characters, such as the slash ("/") character, contained in a
component4 element MUST be represented by URI percent encoding. component4 element MUST be represented by URI percent encoding.
2.8.1.3. Encoding an NFS location in an FSL 2.8.1.3. Encoding an NFS Location in an FSL
The path component of an NFS URI encodes the "rootpath" field of the The path component of an NFS URI encodes the rootpath field of the
NFSv4 fs_location4 data type or the "fli_rootpath" of the NFSv4 NFSv4 fs_location4 data type or the "fli_rootpath" of the NFSv4
fs_locations_item4 data type (see [RFC5661]). fs_locations_item4 data type (see [RFC5661]).
In its "server" field, the NFSv4 fs_location4 data type contains a In its server field, the NFSv4 fs_location4 data type contains a list
list of universal addresses and DNS labels. Each may optionally of universal addresses and DNS labels. Each may optionally include a
include a port number. The exact encoding requirements for this port number. The exact encoding requirements for this information is
information is found in Section 12.6 of [3530bis]. The NFSv4 found in Section 12.6 of [RFC7530]. The NFSv4 fs_locations_item4
fs_locations_item4 data type encodes the same data in its data type encodes the same data in its fli_entries field (see
"fli_entries" field (see [RFC5661]). This information is encoded in [RFC5661]). This information is encoded in the authority component
the authority component of an NFS URI. of an NFS URI.
The "server" and "fli_entries" fields can encode multiple server The server and fli_entries fields can encode multiple server
hostnames that share the same pathname. An NFS URI, and hence an FSL hostnames that share the same pathname. An NFS URI, and hence an FSL
record, represents only a single hostname and pathname pair. An NFS record, represents only a single hostname and pathname pair. An NFS
fileserver MUST NOT combine a set of FSL records into a single fileserver MUST NOT combine a set of FSL records into a single
fs_location4 or fs_locations_item4 unless each FSL record in the set fs_location4 or fs_locations_item4 unless each FSL record in the set
contains the same rootpath value and extended filesystem information. contains the same rootpath value and extended file system
information.
2.8.2. Mutual Consistency across Fileset Locations 2.8.2. 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 access by a same fileset) are equivalent from the point of view of access by a
file-access client. Different fileset locations for an FSN represent file-access client. Different fileset locations for an FSN represent
the same data, though potentially at different points in time. the same data, though potentially at different points in time.
Fileset locations are equivalent but not identical. Locations may Fileset locations are equivalent but not identical. Locations may be
either be read-only or read-write. Typically, multiple read-write either read-only or read-write. Typically, multiple read-write
locations are backed by a clustered filesystem while read-only locations are backed by a clustered file system while read-only
locations are replicas created by a federation-initiated or external locations are replicas created by a federation-initiated or external
replication operation. Read-only locations may represent consistent replication operation. Read-only locations may represent consistent
point-in-time copies of a read-write location. The federation point-in-time copies of a read-write location. The federation
protocols, however, cannot prevent subsequent changes to a read-only protocols, however, cannot prevent subsequent changes to a read-only
location nor guarantee point-in-time consistency of a read-only location nor guarantee point-in-time consistency of a read-only
location if the read-write location is changing. location if the read-write location is changing.
Regardless of the type, one file-access client may be referred to a Regardless of the type, one file-access client may be referred to a
location described by one FSL while another client chooses to use a location described by one FSL while another client chooses to use a
location described by another FSL. Since updates to each fileset location described by another FSL. Since updates to each fileset
skipping to change at page 11, line 22 skipping to change at page 11, line 9
equivalence of the data. equivalence of the data.
The federation protocols do not guarantee that different fileset The federation protocols do not guarantee that different fileset
locations are mutually consistent in terms of the currency of their locations are mutually consistent in terms of the currency of their
data. However, they provide a means to publish currency information data. However, they provide a means to publish currency information
so that all fileservers in a federation can convey the same so that all fileservers in a federation can convey the same
information to file-access clients during referrals. Clients use information to file-access clients during referrals. Clients use
this information to ensure they do not revert to an out-of-date this information to ensure they do not revert to an out-of-date
version of a fileset's data when switching between fileset locations. version of a fileset's data when switching between fileset locations.
NFSv4.1 provides guidance on how replication can be handled in such a NFSv4.1 provides guidance on how replication can be handled in such a
manner. In particular see Section 11.7 of [RFC5661]. manner. In particular, see Section 11.7 of [RFC5661].
2.8.3. Caching of Fileset Locations 2.8.3. Caching of Fileset Locations
To resolve an FSN to a set of FSL records, a fileserver queries the To resolve an FSN to a set of FSL records, a fileserver queries the
NSDB node named in the FSN for FSL records associated with this FSN. NSDB node named in the FSN for FSL records associated with this FSN.
The parent FSN's FsnTTL attribute (see Section 2.7) specifies the The parent FSN's FsnTTL attribute (see Section 2.7) specifies the
period of time during which a fileserver may cache these FSL records. period of time during which a fileserver may cache these FSL records.
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. Suppose further that fileserver A contains a junction J to B, and C. Suppose further that fileserver A contains a junction J to
fileset X stored on fileserver B (see Section 2.10 for a description fileset X stored on fileserver B (see Section 2.10 for a description
of junctions). of junctions).
Now suppose that fileset X is migrated from fileserver B to Now suppose that fileset X is migrated from fileserver B to
fileserver C, and the corresponding FSL information for fileset X in fileserver C, and the corresponding FSL information for fileset X in
the authoritative NSDB is updated. the authoritative NSDB is updated.
If fileserver A has cached FSLs for fileset X, a file-access client If fileserver A has cached FSLs for fileset X, a file-access client
traversing junction J on fileserver A will be referred to fileserver traversing junction J on fileserver A will be referred to fileserver
B, even though fileset X has migrated to fileserver C. If fileserver B, even though fileset X has migrated to fileserver C. If fileserver
A had not cached the FSL records, it would have queried the NSDB and A had not cached the FSL records, it would have queried the NSDB and
obtained the correct location of fileset X. obtained the correct location of fileset X.
Typically, the process of fileset migration leaves a redirection on Typically, the process of fileset migration leaves a redirection on
the source fileserver in place of a migrated fileset (without such a the source fileserver in place of a migrated fileset (without such a
redirection, file-access clients would find an empty space where the redirection, file-access clients would find an empty space where the
migrated fileset was, which defeats the purpose of a managed migrated fileset was, which defeats the purpose of a managed
migration). migration).
This redirection might be a new junction that targets the same FSN as This redirection might be a new junction that targets the same FSN as
other junctions referring to the migrated fileset, or it might be other junctions referring to the migrated fileset, or it might be
some other kind of directive, depending on the fileserver some other kind of directive, depending on the fileserver
implementation, that simply refers file-access clients to the new implementation, that simply refers file-access clients to the new
location of the migrated fileset. location of the migrated fileset.
Back to our example. Suppose, as part of the migration process, a Back to our example. Suppose, as part of the migration process, a
junction replaces fileset X on fileserver B. Later, either: junction replaces fileset X on fileserver B. Later, either:
o New file-access clients are referred to fileserver B by stale FSL o New file-access clients are referred to fileserver B by stale FSL
information cached on fileserver A, or information cached on fileserver A, or
o File-access clients continue to access fileserver B because they o File-access clients continue to access fileserver B because they
cache stale location data for fileset X. cache stale location data for fileset X.
In either case, thanks to the redirection, file-access clients are In either case, thanks to the redirection, file-access clients are
informed by fileserver B that fileset X has moved to fileserver C. informed by fileserver B that fileset X has moved to fileserver C.
Such redirecting junctions (here, on fileserver B) would not be Such redirecting junctions (here, on fileserver B) would not be
required to be in place forever. They need to stay in place at least required to be in place forever. They need to stay in place at least
until FSL entries cached on fileservers and locations cached on file- until FSL entries cached on fileservers and locations cached on file-
access clients for the target fileset are invalidated. access clients for the target fileset are invalidated.
The FsnTTL field in the FSL's parent FSN (see Section 2.7) specifies The FsnTTL field in the FSL's parent FSN (see Section 2.7) specifies
an upper bound for the lifetime of cached FSL information, and thus an upper bound for the lifetime of cached FSL information and thus
can act as a lower bound for the lifetime of redirecting junctions. can act as a lower bound for the lifetime of redirecting junctions.
For example, suppose the FsnTTL field contains the value 3600 seconds For example, suppose the FsnTTL field contains the value 3600 seconds
(one hour). In such a case, administrators SHOULD keep the (one hour). In such a case, administrators SHOULD keep the
redirection in place for at least one hour after a fileset migration redirection in place for at least one hour after a fileset migration
has taken place, because a referring fileserver might cache the FSL has taken place because a referring fileserver might cache the FSL
data during that time before refreshing it. data during that time before refreshing it.
To get file-access clients to access the destination fileserver more To get file-access clients to access the destination fileserver more
quickly, administrators SHOULD set the FsnTTL field of the migrated quickly, administrators SHOULD set the FsnTTL field of the migrated
fileset to a low number or zero before migration begins. It can be fileset to a low number or zero before migration begins. It can be
reset to a more reasonable number at a later point. reset to a more reasonable number at a later point.
Note that some file-access protocols do not communicate location Note that some file-access protocols do not communicate location
cache expiry information to file-access clients. In some cases it cache expiry information to file-access clients. In some cases, it
may be difficult to determine an appropriate lifetime for redirecting may be difficult to determine an appropriate lifetime for redirecting
junctions because file-access clients may cache location information junctions because file-access clients may cache location information
indefinitely. indefinitely.
2.8.4. Generating A Referral from Fileset Locations 2.8.4. Generating a Referral from Fileset Locations
After resolving an FSN to a set of FSL records, the fileserver After resolving an FSN to a set of FSL records, the fileserver
generates a referral to redirect a file-access client to one or more generates a referral to redirect a file-access client to one or more
of the FSN's FSLs. The fileserver converts the FSL records to a of the FSN's FSLs. The fileserver converts the FSL records to a
referral format understood by a particular file-access client, such referral format understood by a particular file-access client, such
as an NFSv4 fs_locations or fs_locations_info attribute. as an NFSv4 fs_locations or fs_locations_info attribute.
To give file-access clients as many options as possible, the To give file-access clients 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
records from the referral. For example, the fileserver might omit an records from the referral. For example, the fileserver might omit an
FSL record because of limitations in the file access protocol's FSL record because of limitations in the file-access protocol's
referral format. referral format.
For a given FSL record, the fileserver MAY convert or reduce the FSL For a given FSL record, the fileserver MAY convert or reduce the FSL
record's contents in a manner appropriate to the referral format. record's contents in a manner appropriate to the referral format.
For example, an NFS FSL record contains all the data necessary to For example, an NFS FSL record contains all the data necessary to
construct an fs_locations_info attribute, but an fs_locations_info construct an fs_locations_info attribute, but an fs_locations_info
attribute contains several pieces of information that are not found attribute contains several pieces of information that are not found
in the simpler fs_locations attribute. A fileserver constructs in the simpler fs_locations attribute. A fileserver constructs
entries in an fs_locations attribute using the relevant contents of entries in an fs_locations attribute using the relevant contents of
an NFS FSL record. an NFS FSL record.
skipping to change at page 13, line 39 skipping to change at page 13, line 36
FSLI4BX_WRITEORDER). While this rank and order information is not FSLI4BX_WRITEORDER). While this rank and order information is not
explicitly expressible in an fs_locations attribute, the fileserver explicitly expressible in an fs_locations attribute, the fileserver
can arrange the fs_locations attribute's locations list based on the can arrange the fs_locations attribute's locations list based on the
rank and order values. rank and order values.
Another example: A single NFS FSL record contains the hostname of one Another example: A single NFS FSL record contains the hostname of one
fileserver. A single fs_locations attribute can contain a list of fileserver. A single fs_locations attribute can contain a list of
fileserver names. An NFS fileserver MAY combine two or more FSL fileserver names. An NFS fileserver MAY combine two or more FSL
records into a single entry in an fs_locations or fs_locations_info records into a single entry in an fs_locations or fs_locations_info
array only if each FSL record contains the same pathname and extended array only if each FSL record contains the same pathname and extended
filesystem information. file system information.
Refer to the NFSv4.1 protocol specification [RFC5661], sections 11.9 Refer to Sections 11.9 and 11.10 of the NFSv4.1 protocol
and 11.10, for further details. specification [RFC5661] for further details.
2.9. 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. information, and FSN-to-FSL mapping information.
An individual repository of namespace information is called an NSDB An individual repository of namespace information is called an NSDB
node. The difference between the NSDB service and an NSDB node is node. The difference between the NSDB service and an NSDB node is
analogous to that between the DNS service and a particular DNS analogous to that between the DNS service and a particular DNS
server. server.
Each NSDB node is managed by a single administrative entity. A Each NSDB node is managed by a single administrative entity. A
single administrative entity can manage multiple NSDB nodes. single administrative entity can manage multiple NSDB nodes.
Each NSDB node stores the definition of the FSNs for which it is Each NSDB node stores the definition of the FSNs for which it is
authoritative. It also stores the definitions of the FSLs associated authoritative. It also stores the definitions of the FSLs associated
with those FSNs. An NSDB node is authoritative for the filesets that with those FSNs. An NSDB node is authoritative for the filesets that
it defines. it defines.
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 Lightweight Directory
support replication. These features MAY be used to replicate the Access Protocol (LDAP) implementations support replication. These
NSDB. features MAY be used to replicate the NSDB.
2.9.1. NSDB Client 2.9.1. NSDB Client
Each NSDB node supports an LDAP [RFC4510] interface. An NSDB client Each NSDB node supports an LDAP [RFC4510] interface. An NSDB client
is software that uses the LDAP protocol to access or update namespace is software that uses the LDAP protocol to access or update namespace
information stored on an NSDB node. Details of these transactions information stored on an NSDB node.
are discussed in Section 4.
A domain's administrative entity uses NSDB client software to manage A domain's administrative entity uses NSDB client software to manage
information stored on NSDB nodes. information stored on NSDB nodes. Details of these transactions are
discussed in Section 5.1.
Fileservers act as an NSDB client when contacting a particular NSDB Fileservers act as an NSDB client when contacting a particular NSDB
node to resolve an FSN to a set of FSL records. The resulting node to resolve an FSN to a set of FSL records. The resulting
location information is then transferred to file-access clients via location information is then transferred to file-access clients via
referrals. Therefore file-access clients never have need to access referrals. Therefore, file-access clients never need to access NSDBs
NSDBs directly. directly. These transactions are described in Section 5.2.
2.10. Junctions and Referrals 2.10. Junctions and Referrals
A junction is a point in a particular fileset namespace where a A junction is a point in a particular fileset namespace where a
specific target fileset may be attached. If a file-access client specific target fileset may be attached. If a file-access client
traverses the path leading from the root of a federated namespace to traverses the path leading from the root of a federated namespace to
the junction referring to a target fileset, it should be able to the junction referring to a target fileset, it should be able to
mount and access the data in that target fileset (assuming mount and access the data in that target fileset (assuming
appropriate permissions). In other words, a junction can be viewed appropriate permissions). In other words, a junction can be viewed
as a reference from a directory in one fileset to the root of the as a reference from a directory in one fileset to the root of the
target fileset. target fileset.
A junction can be implemented as a special marker on a directory, or A junction can be implemented as a special marker on a directory or
by some other mechanism in the fileserver's underlying filesystem. by some other mechanism in the fileserver's underlying file system.
What data is used by the fileserver to represent junctions is not What data is used by the fileserver to represent junctions is not
defined by this document. The essential property is that given a defined by this document. The essential property is that given a
junction, a fileserver must be able to find the FSN for the target junction, a fileserver must be able to find the FSN for the target
fileset. fileset.
When a file-access client reaches a junction, the fileserver refers When a file-access client reaches a junction, the fileserver refers
the client to a list of FSLs associated with the FSN targeted by the the client to a list of FSLs associated with the FSN targeted by the
junction. The client can then mount one of the associated FSLs. junction. The client can then mount one of the associated FSLs.
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.11. 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 file-access client mounts federation-wide unified namespace. When a file-access client mounts
the root fileset from any of these designated fileservers it can view the root fileset from any of these designated fileservers, it can
a common federation-wide namespace. view a common federation-wide namespace.
2.12. UUID Considerations 2.12. UUID Considerations
To ensure FSN and FSL records are unique across a domain, FedFS To ensure FSN and FSL records are unique across a domain, Federated
employs UUIDs conforming to [RFC4122] to form the distinguished names File System (FedFS) employs UUIDs conforming to [RFC4122] to form the
of LDAP records containing FedFS data (see Section 4.2.2.2). distinguished names of LDAP records containing FedFS data (see
Section 4.2.2.2).
Because junctions store a tuple containing an FSN UUID and the name Because junctions store a tuple containing an FSN UUID and the name
and port of an NSDB node, an FSN UUID must be unique only on a single and port of an NSDB node, an FSN UUID must be unique only on a single
NSDB node. An FSN UUID collision can be detected immediately when an NSDB node. An FSN UUID collision can be detected immediately when an
administrator attempts to publish an FSN or FSL by storing it under a administrator attempts to publish an FSN or FSL by storing it under a
specific NSDB Container Entry (NCE) on an authoritative NSDB host. specific NSDB Container Entry (NCE) on an authoritative NSDB host.
Note that one NSDB node may store multiple NCEs, each under a Note that one NSDB node may store multiple NCEs, each under a
different namingContext. If an NSDB node must contain more than one different namingContext. If an NSDB node must contain more than one
NCE, the federation's admin entity SHOULD provide a robust method for NCE, the federation's admin entity SHOULD provide a robust method for
preventing FSN UUID collisions between FSNs that reside on the same preventing FSN UUID collisions between FSNs that reside on the same
NSDB node but under different NCEs. NSDB node but under different NCEs.
Because FSLs are children of FSNs, FSL UUIDs must be unique for just Because FSLs are children of FSNs, FSL UUIDs must be unique for just
a single FSN. As with FSNs, as soon as an FSL is published, its a single FSN. As with FSNs, as soon as an FSL is published, its
uniqueness is guaranteed. uniqueness is guaranteed.
A fileserver performs the operations described in Section 5.2 as an A fileserver performs the operations described in Section 5.2 as an
unauthenticated user. Thus distinguished names of FSN and FSL unauthenticated user. Thus, distinguished names of FSN and FSL
records, as well as the FSN and FSL records themselves, are required records, as well as the FSN and FSL records themselves, are required
to be readable by anyone who can bind anonymously to an NSDB node. to be readable by anyone who can bind anonymously to an NSDB node.
Therefore, FSN and FSL UUIDs should be considered public information.
Therefore FSN and FSL UUIDs should be considered public information. Version 1 UUIDs contain a host's Media Access Control (MAC) address
and a timestamp in the clear. This gives provenance to each UUID,
Version 1 UUIDs contain a host's MAC address and a time stamp in the but attackers can use such details to guess information about the
clear. This gives provenance to each UUID, but attackers can use host where the UUID was generated. Security-sensitive installations
such details to guess information about the host where the UUID was should be aware that on externally facing NSDBs, UUIDs can reveal
generated. Security-sensitive installations should be aware that on information about the hosts where they are generated.
externally-facing NSDBs, UUIDs can reveal information about the hosts
where they are generated.
In addition, version 1 UUIDs depend on the notion that a hardware MAC In addition, version 1 UUIDs depend on the notion that a hardware MAC
address is unique across machines. As virtual machines do not depend address is unique across machines. As virtual machines do not depend
on unique physical MAC addresses and in any event an administrator on unique physical MAC addresses and, in any event, an administrator
can modify the physical MAC address, version 1 UUIDs are no longer can modify the physical MAC address, version 1 UUIDs are no longer
considered sufficient. considered sufficient.
To minimize the probability of UUIDs colliding, a consistent To minimize the probability of UUIDs colliding, a consistent
procedure for generating UUIDs should be used throughout a procedure for generating UUIDs should be used throughout a
federation. Within a federation, UUIDs SHOULD be generated using the federation. Within a federation, UUIDs SHOULD be generated using the
procedure described for version 4 of the UUID variant specified in procedure described for version 4 of the UUID variant specified in
[RFC4122]. [RFC4122].
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 file system protocol:
a fileset, adding a replica of a fileset, resolving a junction, and creating a fileset, adding a replica of a fileset, resolving a
creating a junction. junction, and 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
that contains them. The fileset abstraction is the fundamental unit that contains them. The fileset abstraction is the fundamental unit
of data management in the federation. This abstraction is of data management in the federation. This abstraction is
implemented by an actual directory tree whose root location is implemented by an actual directory tree whose root location is
specified by a 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
how the FSN that binds the FSL is created, and whether other replicas how the FSN that binds the FSL is created and whether other replicas
of the fileset exist, are known to the federation, and need to be of the fileset exist, are known to the federation, and need to be
bound to the same FSN. bound to the same FSN.
It is easiest to describe this in terms of how to create the initial It is easiest to describe this in terms of how to create the initial
implementation of the fileset, and then describe how to add replicas. implementation of the fileset and then describe how to add replicas.
3.1.1. Creating a Fileset and an FSN 3.1.1. Creating a Fileset and an FSN
The following administrative steps create an FSN, which is used to
track all replicas of a single physical dataset.
1. Choose the NSDB node that will keep track of the FSL(s) and 1. Choose the NSDB node that will keep track of the FSL(s) and
related information for the fileset. related information for the fileset.
2. Create an FSN in the NSDB node. 2. Create an FSN in the NSDB node.
The FSN UUID is chosen by the administrator or generated The FSN UUID is chosen by the administrator or generated
automatically by administration software. The former case is automatically by administration software. The former case is
used if the fileset is being restored, perhaps as part of used if the fileset is being restored, perhaps as part of
disaster recovery, and the administrator wishes to specify the disaster recovery, and the administrator wishes to specify the
FSN UUID in order to permit existing junctions that reference FSN UUID in order to permit existing junctions that reference
skipping to change at page 19, line 7 skipping to change at page 19, line 11
This follows the traditional Andrew File System (AFS) model of This follows the traditional Andrew File System (AFS) model of
mounting the read-only volume at a path in the namespace different mounting the read-only volume at a path in the namespace different
from that of the read-write volume [AFS]. from that of the read-write volume [AFS].
The federation protocol does not control or manage the relationship The federation protocol does not control or manage the relationship
among filesets. It merely enables annotating the filesets with user- among filesets. It merely enables annotating the filesets with user-
defined relationships. defined relationships.
Another potential use for annotations is recording references to an Another potential use for annotations is recording references to an
FSN. A single annotation containing the number of references could FSN. A single annotation containing the number of references could
be defined; or multiple annotations, one per reference, could be used be defined, or multiple annotations, one per reference, could be used
to store detailed information on the location of each reference. to store detailed information on the location of each reference.
As with the replication annotation described above, the maintenance As with the replication annotation described above, the maintenance
of reference information would not be controlled by the federation of reference information would not be controlled by the federation
protocol. The information would most likely be non-authoritative protocol. The information would most likely be non-authoritative
because the ability to create a junction does not require the because the ability to create a junction does not require the
authority to update the FSN record. In any event, such annotations authority to update the FSN record. In any event, such annotations
could be useful to administrators for determining if an FSN is could be useful to administrators for determining if an FSN is
referenced by a junction. referenced by a junction.
4. NSDB Configuration and Schema 4. NSDB Configuration and Schema
This section describes how an NSDB is constructed using an LDAP This section describes how an NSDB is constructed using an LDAP
Version 3 [RFC4510] Directory. Section 4.1 describes the basic Version 3 [RFC4510] directory. Section 4.1 describes the basic
properties of the LDAP configuration that MUST be used in order to properties of the LDAP configuration that MUST be used in order to
ensure compatibility between different implementations. Section 4.2 ensure compatibility between different implementations. Section 4.2
defines the new LDAP attribute types, the new object types, and defines the new LDAP attribute types and the new object types; it
specifies how the distinguished name (DN) of each object instance also specifies how the distinguished name (DN) of each object
MUST be constructed. instance MUST be constructed.
4.1. LDAP Configuration 4.1. LDAP Configuration
An NSDB is constructed using an LDAP Directory. This LDAP Directory An NSDB is constructed using an LDAP directory. This LDAP directory
MAY have multiple naming contexts. The LDAP Directory's DSA-specific MAY have multiple naming contexts. The LDAP directory's entry
entry (its rootDSE) has a multi-valued namingContext attribute. Each specific to Digital Signature Algorithm (DSA) (its rootDSE) has a
value of the namingContext attribute is the DN of a naming context's multi-valued namingContext attribute. Each value of the
root entry (see [RFC4512]). namingContext attribute is the DN of a naming context's root entry
(see [RFC4512]).
For each naming context that contains federation entries (e.g., FSNs For each naming context that contains federation entries (e.g., FSNs
and FSLs): and FSLs):
1. There MUST be an LDAP entry that is superior to all of the naming 1. There MUST be an LDAP entry that is superior to all of the naming
context's federation entries in the Directory Information Tree context's federation entries in the Directory Information Tree
(DIT). This entry is termed the NSDB Container Entry (NCE). The (DIT). This entry is termed the NSDB Container Entry (NCE). The
NCE's children are FSNs. An FSN's children are FSLs. NCE's children are FSNs. An FSN's children are FSLs.
2. The naming context's root entry MUST include the 2. The naming context's root entry MUST include
fedfsNsdbContainerInfo (defined below) as one of its object "fedfsNsdbContainerInfo" (defined in Section 4.2.2.1) as one of
classes. The fedfsNsdbContainerInfo's fedfsNceDN attribute is its object classes. The fedfsNsdbContainerInfo's fedfsNceDN
used to locate the naming context's NCE. attribute is used to locate the naming context's NCE.
If a naming context does not contain federation entries, it will not If a naming context does not contain federation entries, it will not
contain an NCE and its root entry will not include a contain an NCE, and its root entry will not include a
fedfsNsdbContainerInfo as one of its object classes. "fedfsNsdbContainerInfo" as one of its object classes.
A fedfsNsdbContainerInfo's fedfsNceDN attribute contains the A fedfsNsdbContainerInfo's fedfsNceDN attribute contains the
Distinguished Name (DN) of the NSDB Container Entry residing under distinguished name (DN) of the NSDB Container Entry residing under
this naming context. The fedfsNceDN attribute MUST NOT be empty. this naming context. The fedfsNceDN attribute MUST NOT be empty.
For example, an LDAP directory might have the following entries: For example, an LDAP directory might have the following entries:
-+ [root DSE] -+ [root DSE]
| namingContext: o=fedfs | namingContext: o=fedfs
| namingContext: dc=example,dc=com | namingContext: dc=example,dc=com
| namingContext: ou=system | namingContext: ou=system
| |
| |
+---- [o=fedfs] +---- [o=fedfs]
| fedfsNceDN: o=fedfs | fedfsNceDN: o=fedfs
| |
| |
+---- [dc=example,dc=com] +---- [dc=example,dc=com]
| fedfsNceDN: ou=fedfs,ou=corp-it,dc=example,dc=com | fedfsNceDN: ou=fedfs,ou=corp-it,dc=example,dc=com
| |
| |
+---- [ou=system] +---- [ou=system]
In this case, the o=fedfs namingContext has an NSDB Container Entry In this case, the "o=fedfs" namingContext has an NSDB Container Entry
at o=fedfs, the dc=example,dc=com namingContext has an NSDB Container at "o=fedfs", the "dc=example,dc=com" namingContext has an NSDB
Entry at ou=fedfs,ou=corp-it,dc=example,dc=com, and the ou=system Container Entry at "ou=fedfs,ou=corp-it,dc=example,dc=com", and the
namingContext has no NSDB Container Entry. "ou=system" namingContext has no NSDB Container Entry.
The NSDB SHOULD be configured with one or more privileged LDAP users. The NSDB SHOULD be configured with one or more privileged LDAP users.
These users are able to modify the contents of the LDAP database. An These users are able to modify the contents of the LDAP database. An
administrator that performs the operations described in Section 5.1 administrator that performs the operations described in Section 5.1
SHOULD authenticate using the DN of a privileged LDAP user. SHOULD authenticate using the DN of a privileged LDAP user.
It MUST be possible for an unprivileged (unauthenticated) user to It MUST be possible for an unprivileged (unauthenticated) user to
perform LDAP queries that access the NSDB data. A fileserver perform LDAP queries that access the NSDB data. A fileserver
performs the operations described in Section 5.2 as an unprivileged performs the operations described in Section 5.2 as an unprivileged
user. user.
skipping to change at page 22, line 4 skipping to change at page 22, line 9
<CODE ENDS> <CODE ENDS>
The effect of the script is to remove leading white space from each The effect of the script is to remove leading white space from each
line, plus a sentinel sequence of "///". line, plus a sentinel sequence of "///".
Code components extracted from this document must include the Code components extracted from this document must include the
following license: following license:
<CODE BEGINS> <CODE BEGINS>
/// # /// #
/// # Copyright (c) 2010-2012 IETF Trust and the persons identified /// # Copyright (c) 2015 IETF Trust and the persons identified
/// # as authors of the code. All rights reserved. /// # as authors of the code. All rights reserved.
/// # /// #
/// # The authors of the code are the authors of /// # The authors of the code are:
/// # [draft-ietf-nfsv4-federated-fs-protocol-xx.txt]: J. Lentini, /// # J. Lentini, C. Everhart, D. Ellard, R. Tewari, and M. Naik.
/// # C. Everhart, D. Ellard, R. Tewari, and M. Naik.
/// # /// #
/// # Redistribution and use in source and binary forms, with /// # Redistribution and use in source and binary forms, with
/// # or without modification, are permitted provided that the /// # or without modification, are permitted provided that the
/// # following conditions are met: /// # following conditions are met:
/// # /// #
/// # - Redistributions of source code must retain the above /// # - Redistributions of source code must retain the above
/// # copyright notice, this list of conditions and the /// # copyright notice, this list of conditions and the
/// # following disclaimer. /// # following disclaimer.
/// # /// #
/// # - Redistributions in binary form must reproduce the above /// # - Redistributions in binary form must reproduce the above
skipping to change at page 23, line 7 skipping to change at page 23, line 7
/// # LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, /// # LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
/// # OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING /// # OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
/// # IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF /// # IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
/// # ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. /// # ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
/// # /// #
<CODE ENDS> <CODE ENDS>
4.2.1. LDAP Attributes 4.2.1. LDAP Attributes
The following definitions are used below: The following definitions are used in this document:
o The "name" attribute described in [RFC4519]. o The name attribute described in [RFC4519].
o The Integer syntax (1.3.6.1.4.1.1466.115.121.1.27) described in o The Integer syntax (1.3.6.1.4.1.1466.115.121.1.27) described in
[RFC4517]. [RFC4517].
o The "integerMatch" rule described in [RFC4517]. o The integerMatch rule described in [RFC4517].
o The Octet String syntax (1.3.6.1.4.1.1466.115.121.1.40) described o The Octet String syntax (1.3.6.1.4.1.1466.115.121.1.40) described
in [RFC4517]. in [RFC4517].
o The "octetStringMatch" rule described in [RFC4517]. o The octetStringMatch rule described in [RFC4517].
o The Boolean syntax (1.3.6.1.4.1.1466.115.121.1.7) described in o The Boolean syntax (1.3.6.1.4.1.1466.115.121.1.7) described in
[RFC4517]. [RFC4517].
o The "booleanMatch" rule described in [RFC4517]. o The booleanMatch rule described in [RFC4517].
o The "distinguishedNameMatch" rule described in [RFC4517]. o The distinguishedNameMatch rule described in [RFC4517].
o The DN syntax (1.3.6.1.4.1.1466.115.121.1.12) described in o The DN syntax (1.3.6.1.4.1.1466.115.121.1.12) described in
[RFC4517]. [RFC4517].
o The "labeledURI" attribute described in [RFC2079]. o The labeledURI attribute described in [RFC2079].
o The UUID syntax (1.3.6.1.1.16.1) described in [RFC4530]. o The UUID syntax (1.3.6.1.1.16.1) described in [RFC4530].
o The UuidMatch rule described in [RFC4530]. o The UuidMatch rule described in [RFC4530].
o The UuidOrderingMatch rule described in [RFC4530]. o The UuidOrderingMatch rule described in [RFC4530].
4.2.1.1. fedfsUuid 4.2.1.1. fedfsUuid
A fedfsUuid is the base type for all of the universally unique A fedfsUuid is the base type for all of the universally unique
identifiers (UUIDs) used by the federated filesystem protocols. identifiers (UUIDs) used by the federated file system protocols.
The fedfsUuid type is based on rules and syntax defined in [RFC4530]. The fedfsUuid type is based on rules and syntax defined in [RFC4530].
A fedfsUuid is a single-valued LDAP attribute. A fedfsUuid is a single-valued LDAP attribute.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.1 NAME 'fedfsUuid' /// 1.3.6.1.4.1.31103.1.1 NAME 'fedfsUuid'
/// DESC 'A UUID used by NSDB' /// DESC 'A UUID used by NSDB'
/// EQUALITY uuidMatch /// EQUALITY uuidMatch
/// ORDERING uuidOrderingMatch /// ORDERING uuidOrderingMatch
/// SYNTAX 1.3.6.1.1.16.1 /// SYNTAX 1.3.6.1.1.16.1
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
skipping to change at page 24, line 41 skipping to change at page 25, line 9
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
4.2.1.3. fedfsFsnTTL 4.2.1.3. fedfsFsnTTL
A fedfsFsnTTL is the time-to-live in seconds of a cached FSN and its A fedfsFsnTTL is the time-to-live in seconds of a cached FSN and its
child FSL records. It corresponds to the FsnTTL as defined in child FSL records. It corresponds to the FsnTTL as defined in
Section 2.7. See also Section Section 2.8.3 for information about Section 2.7. See also Section 2.8.3 for information about caching
caching FSLs. A fedfsFsnTTL MUST be encoded as an Integer syntax FSLs. A fedfsFsnTTL MUST be encoded as an Integer syntax value
value [RFC4517] in the range [0, 4294967295]. [RFC4517] in the range [0, 4294967295].
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.11 NAME 'fedfsFsnTTL' /// 1.3.6.1.4.1.31103.1.11 NAME 'fedfsFsnTTL'
/// DESC 'Time to live of an FSN tree' /// DESC 'Time to live of an FSN tree'
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
skipping to change at page 26, line 28 skipping to change at page 26, line 38
value pair. value pair.
This attribute is multi-valued; an object type that permits This attribute is multi-valued; an object type that permits
annotations may have any number of annotations per instance. annotations may have any number of annotations per instance.
A fedfsAnnotation attribute is a human-readable sequence of UTF-8 A fedfsAnnotation attribute is a human-readable sequence of UTF-8
characters with no non-terminal NUL characters. The value MUST be characters with no non-terminal NUL characters. The value MUST be
formatted according to the following ABNF [RFC5234] rules: formatted according to the following ABNF [RFC5234] rules:
ANNOTATION = KEY "=" VALUE ANNOTATION = KEY "=" VALUE
KEY = ITEM KEY = ITEM
VALUE = ITEM VALUE = ITEM
ITEM = *WSP DQUOTE UTF8-octets DQUOTE *WSP ITEM = *WSP DQUOTE UTF8-octets DQUOTE *WSP
DQUOTE and WSP are defined in [RFC5234], and UTF8-octets is defined DQUOTE and WSP are defined in [RFC5234], and UTF8-octets is defined
in [RFC3629]. in [RFC3629].
The following escape sequences are allowed: The following escape sequences are allowed:
+-----------------+-------------+ +-----------------+-------------+
| escape sequence | replacement | | escape sequence | replacement |
+-----------------+-------------+ +-----------------+-------------+
| \\ | \ | | \\ | \ |
skipping to change at page 27, line 16 skipping to change at page 27, line 24
SHOULD be ignored in its entirety. It MUST NOT prevent further SHOULD be ignored in its entirety. It MUST NOT prevent further
processing of its containing entry. processing of its containing entry.
The following are examples of valid fedfsAnnotation attributes: The following are examples of valid fedfsAnnotation attributes:
"key1" = "foo" "key1" = "foo"
"another key" = "x=3" "another key" = "x=3"
"key-2" = "A string with \" and \\ characters." "key-2" = "A string with \" and \\ characters."
"key3"="bar" "key3"="bar"
which correspond to the following key/value pairs: These correspond to the following key/value pairs:
+-------------+-----------------------------------+ +-------------+-----------------------------------+
| key | value | | key | value |
+-------------+-----------------------------------+ +-------------+-----------------------------------+
| key1 | foo | | key1 | foo |
| another key | x=3 | | another key | x=3 |
| key-2 | A string with " and \ characters. | | key-2 | A string with " and \ characters. |
| key3 | bar | | key3 | bar |
+-------------+-----------------------------------+ +-------------+-----------------------------------+
skipping to change at page 27, line 44 skipping to change at page 28, line 10
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
4.2.1.7. fedfsDescr 4.2.1.7. fedfsDescr
A fedfsDescr stores an object description. The description MUST be A fedfsDescr stores an object description. The description MUST be
encoded as a UTF-8 string. encoded as a UTF-8 string.
This attribute is multi-valued which permits any number of This attribute is multi-valued, which permits any number of
descriptions per entry. descriptions per entry.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.13 NAME 'fedfsDescr' /// 1.3.6.1.4.1.31103.1.13 NAME 'fedfsDescr'
/// DESC 'Description of an object' /// DESC 'Description of an object'
/// SUP name /// SUP name
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
skipping to change at page 29, line 29 skipping to change at page 29, line 41
A fedfsNfsGenFlagWritable stores the value of an FSL's NFSv4.1 A fedfsNfsGenFlagWritable stores the value of an FSL's NFSv4.1
FSLI4GF_WRITABLE bit [RFC5661]. A value of "TRUE" indicates the bit FSLI4GF_WRITABLE bit [RFC5661]. A value of "TRUE" indicates the bit
is set. A value of "FALSE" indicates the bit is not set. is set. A value of "FALSE" indicates the bit is not set.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.104 NAME 'fedfsNfsGenFlagWritable' /// 1.3.6.1.4.1.31103.1.104 NAME 'fedfsNfsGenFlagWritable'
/// DESC 'Indicates if the filesystem is writable' /// DESC 'Indicates if the file system is writable'
/// EQUALITY booleanMatch /// EQUALITY booleanMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].
skipping to change at page 30, line 4 skipping to change at page 30, line 12
OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].
4.2.1.11. fedfsNfsGenFlagGoing 4.2.1.11. fedfsNfsGenFlagGoing
A fedfsNfsGenFlagGoing stores the value of an FSL's NFSv4.1 A fedfsNfsGenFlagGoing stores the value of an FSL's NFSv4.1
FSLI4GF_GOING bit [RFC5661]. A value of "TRUE" indicates the bit is FSLI4GF_GOING bit [RFC5661]. A value of "TRUE" indicates the bit is
set. A value of "FALSE" indicates the bit is not set. set. A value of "FALSE" indicates the bit is not set.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.105 NAME 'fedfsNfsGenFlagGoing' /// 1.3.6.1.4.1.31103.1.105 NAME 'fedfsNfsGenFlagGoing'
/// DESC 'Indicates if the filesystem is going' /// DESC 'Indicates if the file system is going'
/// EQUALITY booleanMatch /// EQUALITY booleanMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].
skipping to change at page 30, line 29 skipping to change at page 30, line 38
A fedfsNfsGenFlagSplit stores the value of an FSL's NFSv4.1 A fedfsNfsGenFlagSplit stores the value of an FSL's NFSv4.1
FSLI4GF_SPLIT bit [RFC5661]. A value of "TRUE" indicates the bit is FSLI4GF_SPLIT bit [RFC5661]. A value of "TRUE" indicates the bit is
set. A value of "FALSE" indicates the bit is not set. set. A value of "FALSE" indicates the bit is not set.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.106 NAME 'fedfsNfsGenFlagSplit' /// 1.3.6.1.4.1.31103.1.106 NAME 'fedfsNfsGenFlagSplit'
/// DESC 'Indicates if there are multiple filesystems' /// DESC 'Indicates if there are multiple file systems'
/// EQUALITY booleanMatch /// EQUALITY booleanMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].
skipping to change at page 31, line 29 skipping to change at page 31, line 38
A fedfsNfsClassSimul contains the FSL's NFSv4.1 FSLI4BX_CLSIMUL A fedfsNfsClassSimul contains the FSL's NFSv4.1 FSLI4BX_CLSIMUL
[RFC5661] value. A fedfsNfsClassSimul MUST be encoded as an Integer [RFC5661] value. A fedfsNfsClassSimul MUST be encoded as an Integer
syntax value [RFC4517] in the range [0, 255]. syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.108 NAME 'fedfsNfsClassSimul' /// 1.3.6.1.4.1.31103.1.108 NAME 'fedfsNfsClassSimul'
/// DESC 'The simultaneous-use class of the filesystem' /// DESC 'The simultaneous-use class of the file system'
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
skipping to change at page 32, line 4 skipping to change at page 32, line 12
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.15. fedfsNfsClassHandle 4.2.1.15. fedfsNfsClassHandle
A fedfsNfsClassHandle contains the FSL's NFSv4.1 FSLI4BX_CLHANDLE A fedfsNfsClassHandle contains the FSL's NFSv4.1 FSLI4BX_CLHANDLE
[RFC5661] value. A fedfsNfsClassHandle MUST be encoded as an Integer [RFC5661] value. A fedfsNfsClassHandle MUST be encoded as an Integer
syntax value [RFC4517] in the range [0, 255]. syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.109 NAME 'fedfsNfsClassHandle' /// 1.3.6.1.4.1.31103.1.109 NAME 'fedfsNfsClassHandle'
/// DESC 'The handle class of the filesystem' /// DESC 'The handle class of the file system'
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
skipping to change at page 32, line 29 skipping to change at page 32, line 38
A fedfsNfsClassFileid contains the FSL's NFSv4.1 FSLI4BX_CLFILEID A fedfsNfsClassFileid contains the FSL's NFSv4.1 FSLI4BX_CLFILEID
[RFC5661] value. A fedfsNfsClassFileid MUST be encoded as an Integer [RFC5661] value. A fedfsNfsClassFileid MUST be encoded as an Integer
syntax value [RFC4517] in the range [0, 255]. syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.110 NAME 'fedfsNfsClassFileid' /// 1.3.6.1.4.1.31103.1.110 NAME 'fedfsNfsClassFileid'
/// DESC 'The fileid class of the filesystem' /// DESC 'The fileid class of the file system'
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
skipping to change at page 33, line 4 skipping to change at page 33, line 12
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.17. fedfsNfsClassWritever 4.2.1.17. fedfsNfsClassWritever
A fedfsNfsClassWritever contains the FSL's NFSv4.1 FSLI4BX_CLWRITEVER A fedfsNfsClassWritever contains the FSL's NFSv4.1 FSLI4BX_CLWRITEVER
[RFC5661] value. A fedfsNfsClassWritever MUST be encoded as an [RFC5661] value. A fedfsNfsClassWritever MUST be encoded as an
Integer syntax value [RFC4517] in the range [0, 255]. Integer syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.111 NAME 'fedfsNfsClassWritever' /// 1.3.6.1.4.1.31103.1.111 NAME 'fedfsNfsClassWritever'
/// DESC 'The write-verifier class of the filesystem' /// DESC 'The write-verifier class of the file system'
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
skipping to change at page 33, line 29 skipping to change at page 33, line 38
A fedfsNfsClassChange contains the FSL's NFSv4.1 FSLI4BX_CLCHANGE A fedfsNfsClassChange contains the FSL's NFSv4.1 FSLI4BX_CLCHANGE
[RFC5661] value. A fedfsNfsClassChange MUST be encoded as an Integer [RFC5661] value. A fedfsNfsClassChange MUST be encoded as an Integer
syntax value [RFC4517] in the range [0, 255]. syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.112 NAME 'fedfsNfsClassChange' /// 1.3.6.1.4.1.31103.1.112 NAME 'fedfsNfsClassChange'
/// DESC 'The change class of the filesystem' /// DESC 'The change class of the file system'
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
skipping to change at page 34, line 4 skipping to change at page 34, line 12
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.19. fedfsNfsClassReaddir 4.2.1.19. fedfsNfsClassReaddir
A fedfsNfsClassReaddir contains the FSL's NFSv4.1 FSLI4BX_CLREADDIR A fedfsNfsClassReaddir contains the FSL's NFSv4.1 FSLI4BX_CLREADDIR
[RFC5661] value. A fedfsNfsClassReaddir MUST be encoded as an [RFC5661] value. A fedfsNfsClassReaddir MUST be encoded as an
Integer syntax value [RFC4517] in the range [0, 255]. Integer syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.113 NAME 'fedfsNfsClassReaddir' /// 1.3.6.1.4.1.31103.1.113 NAME 'fedfsNfsClassReaddir'
/// DESC 'The readdir class of the filesystem' /// DESC 'The readdir class of the file system'
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
skipping to change at page 34, line 29 skipping to change at page 34, line 38
A fedfsNfsReadRank contains the FSL's NFSv4.1 FSLI4BX_READRANK A fedfsNfsReadRank contains the FSL's NFSv4.1 FSLI4BX_READRANK
[RFC5661] value. A fedfsNfsReadRank MUST be encoded as an Integer [RFC5661] value. A fedfsNfsReadRank MUST be encoded as an Integer
syntax value [RFC4517] in the range [0, 255]. syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.114 NAME 'fedfsNfsReadRank' /// 1.3.6.1.4.1.31103.1.114 NAME 'fedfsNfsReadRank'
/// DESC 'The read rank of the filesystem' /// DESC 'The read rank of the file system'
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
skipping to change at page 35, line 4 skipping to change at page 35, line 12
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.21. fedfsNfsReadOrder 4.2.1.21. fedfsNfsReadOrder
A fedfsNfsReadOrder contains the FSL's NFSv4.1 FSLI4BX_READORDER A fedfsNfsReadOrder contains the FSL's NFSv4.1 FSLI4BX_READORDER
[RFC5661] value. A fedfsNfsReadOrder MUST be encoded as an Integer [RFC5661] value. A fedfsNfsReadOrder MUST be encoded as an Integer
syntax value [RFC4517] in the range [0, 255]. syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.115 NAME 'fedfsNfsReadOrder' /// 1.3.6.1.4.1.31103.1.115 NAME 'fedfsNfsReadOrder'
/// DESC 'The read order of the filesystem' /// DESC 'The read order of the file system'
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
skipping to change at page 35, line 29 skipping to change at page 35, line 38
A fedfsNfsWriteRank contains the FSL's FSLI4BX_WRITERANK [RFC5661] A fedfsNfsWriteRank contains the FSL's FSLI4BX_WRITERANK [RFC5661]
value. A fedfsNfsWriteRank MUST be encoded as an Integer syntax value. A fedfsNfsWriteRank MUST be encoded as an Integer syntax
value [RFC4517] in the range [0, 255]. value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.116 NAME 'fedfsNfsWriteRank' /// 1.3.6.1.4.1.31103.1.116 NAME 'fedfsNfsWriteRank'
/// DESC 'The write rank of the filesystem' /// DESC 'The write rank of the file system'
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
skipping to change at page 36, line 4 skipping to change at page 36, line 12
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.23. fedfsNfsWriteOrder 4.2.1.23. fedfsNfsWriteOrder
A fedfsNfsWriteOrder contains the FSL's FSLI4BX_WRITEORDER [RFC5661] A fedfsNfsWriteOrder contains the FSL's FSLI4BX_WRITEORDER [RFC5661]
value. A fedfsNfsWriteOrder MUST be encoded as an Integer syntax value. A fedfsNfsWriteOrder MUST be encoded as an Integer syntax
value [RFC4517] in the range [0, 255]. value [RFC4517] in the range [0, 255].
<CODE BEGINS> <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.117 NAME 'fedfsNfsWriteOrder' /// 1.3.6.1.4.1.31103.1.117 NAME 'fedfsNfsWriteOrder'
/// DESC 'The write order of the filesystem' /// DESC 'The write order of the file system'
/// EQUALITY integerMatch /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS> <CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
skipping to change at page 38, line 42 skipping to change at page 40, line 9
/// $ fedfsDescr /// $ fedfsDescr
/// )) /// ))
/// ///
<CODE ENDS> <CODE ENDS>
4.2.2.3. fedfsFsl 4.2.2.3. fedfsFsl
The fedfsFsl object class represents an FSL. The fedfsFsl object class represents an FSL.
The fedfsFsl is an abstract object class. Protocol specific subtypes The fedfsFsl is an abstract object class. Protocol-specific subtypes
of this object class are used to store FSL information. The of this object class are used to store FSL information. The
fedfsNfsFsl object class defined below is used to record an NFS FSL's fedfsNfsFsl object class defined in Section 4.2.2.4 is used to record
location. Other subtypes MAY be defined for other protocols (e.g., an NFS FSL's location. Other subtypes MAY be defined for other
CIFS). protocols (e.g., Common Internet File System (CIFS)).
A fedfsFsl's fedfsFslUuid and fedfsFsnUuid attributes are REQUIRED. A fedfsFsl's fedfsFslUuid and fedfsFsnUuid attributes are REQUIRED.
A fedfsFsl's fedfsAnnotation, and fedfsDescr attributes are OPTIONAL. A fedfsFsl's fedfsAnnotation and fedfsDescr attributes are OPTIONAL.
The DN of an FSL is REQUIRED to take the following form: The DN of an FSL is REQUIRED to take the following form:
"fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE", where $FSLUUID is
"fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE" where $FSLUUID is
the FSL's UUID, $FSNUUID is the FSN's UUID, and $NCE is the DN of the the FSL's UUID, $FSNUUID is the FSN's UUID, and $NCE is the DN of the
NCE. Since LDAP requires a DN to be unique, this ensures that each NCE. Since LDAP requires a DN to be unique, this ensures that each
FSL entry has a unique UUID value within the LDAP directory. FSL entry has a unique UUID value within the LDAP directory.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// objectclass ( /// objectclass (
/// 1.3.6.1.4.1.31103.1.1003 NAME 'fedfsFsl' /// 1.3.6.1.4.1.31103.1.1003 NAME 'fedfsFsl'
/// DESC 'A physical location of a fileset' /// DESC 'A physical location of a fileset'
skipping to change at page 39, line 36 skipping to change at page 41, line 12
<CODE ENDS> <CODE ENDS>
4.2.2.4. fedfsNfsFsl 4.2.2.4. fedfsNfsFsl
A fedfsNfsFsl is used to represent an NFS FSL. The fedfsNfsFsl A fedfsNfsFsl is used to represent an NFS FSL. The fedfsNfsFsl
inherits all of the attributes of the fedfsFsl and extends the inherits all of the attributes of the fedfsFsl and extends the
fedfsFsl with information specific to the NFS protocol. fedfsFsl with information specific to the NFS protocol.
The DN of an NFS FSL is REQUIRED to take the following form: The DN of an NFS FSL is REQUIRED to take the following form:
"fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE" where $FSLUUID is "fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE", where $FSLUUID is
the FSL's UUID, $FSNUUID is the FSN's UUID, and $NCE is the DN of the the FSL's UUID, $FSNUUID is the FSN's UUID, and $NCE is the DN of the
NCE. Since LDAP requires a DN to be unique, this ensures that each NCE. Since LDAP requires a DN to be unique, this ensures that each
NFS FSL entry has a unique UUID value within the LDAP directory. NFS FSL entry has a unique UUID value within the LDAP directory.
<CODE BEGINS> <CODE BEGINS>
/// ///
/// objectclass ( /// objectclass (
/// 1.3.6.1.4.1.31103.1.1004 NAME 'fedfsNfsFsl' /// 1.3.6.1.4.1.31103.1.1004 NAME 'fedfsNfsFsl'
/// DESC 'An NFS location of a fileset' /// DESC 'An NFS location of a fileset'
/// SUP fedfsFsl STRUCTURAL /// SUP fedfsFsl STRUCTURAL
/// MUST ( /// MUST (
/// fedfsNfsURI /// fedfsNfsURI
/// $ fedfsNfsCurrency /// $ fedfsNfsCurrency
/// $ fedfsNfsGenFlagWritable /// $ fedfsNfsGenFlagWritable
/// $ fedfsNfsGenFlagGoing /// $ fedfsNfsGenFlagGoing
skipping to change at page 41, line 8 skipping to change at page 42, line 27
to an NSDB node in order to perform resolution (or to find other to an NSDB node in order to perform resolution (or to find other
information about the data stored within that NSDB node) and the information about the data stored within that NSDB node) and the
responses returned by the NSDB node. The primary use of this sub- responses returned by the NSDB node. The primary use of this sub-
protocol is by a fileserver in order to perform resolution, but it protocol is by a fileserver in order to perform resolution, but it
may also be used by an administrator to query the state of the may also be used by an administrator to query the state of the
system. system.
The first and second sub-protocols are defined as LDAP operations, The first and second sub-protocols are defined as LDAP operations,
using the schema defined in the previous section. If each NSDB node using the schema defined in the previous section. If each NSDB node
is a standard LDAP server, then, in theory, it is unnecessary to is a standard LDAP server, then, in theory, it is unnecessary to
describe the LDAP operations in detail, because the operations are describe the LDAP operations in detail because the operations are
ordinary LDAP operations to query and update records. However, we do ordinary LDAP operations to query and update records. However, we do
not require that an NSDB node implement a complete LDAP service, and not require that an NSDB node implement a complete LDAP service.
therefore we define in these sections the minimum level of LDAP Therefore, we define the minimum level of LDAP functionality required
functionality required to implement an NSDB node. to implement an NSDB node.
The NSDB sub-protocols are defined in Section 5.1 and Section 5.2. The NSDB sub-protocols are defined in Section 5.1 and Section 5.2.
The descriptions of LDAP messages in these sections use the LDAP Data The 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 uppercase 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 This document uses the term "NSDB client" to refer to an LDAP client
that uses either of the NSDB sub-protocols. 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 protocol. The reason The third sub-protocol is defined as an Open Network Computing (ONC)
for using ONC RPC instead of LDAP is that all fileservers support ONC Remote Procedure Call (RPC) protocol. The reason for using ONC RPC
RPC but some do not support an LDAP Directory server. instead of LDAP is that all fileservers support ONC RPC, but some do
not support an LDAP directory server.
The ONC RPC administration protocol is defined in [FEDFS-ADMIN]. The ONC RPC administration protocol is defined in [RFC7533].
5.1. NSDB Operations for Administrators 5.1. NSDB Operations for Administrators
The admin entity initiates and controls the commands to manage The admin entity initiates and controls the commands to manage
fileset and namespace information. The protocol used for fileset and namespace information. The protocol used for
communicating between the admin entity and each NSDB node MUST be the communicating between the admin entity and each NSDB node MUST be the
LDAPv3 [RFC4510] protocol. LDAPv3 [RFC4510] protocol.
The names we assign to these operations are entirely for the purpose The names we assign to these operations are entirely for the purpose
of exposition in this document, and are not part of the LDAP dialogs. of exposition in this document and are not part of the LDAP dialogs.
5.1.1. Create an FSN 5.1.1. Create an FSN
This operation creates a new FSN in the NSDB by adding a new fedfsFsn This operation creates a new FSN in the NSDB by adding a new fedfsFsn
entry in the NSDB's LDAP directory. entry in the NSDB's LDAP directory.
A fedfsFsn entry contains a fedfsFsnUuid. The administrator chooses A fedfsFsn entry contains a fedfsFsnUuid. The administrator chooses
the fedfsFsnUuid by a process described in Section 2.12). A fedfsFsn the fedfsFsnUuid by the process described in Section 2.12. A
entry also contains a fedfsFsnTTL. The fedfsFsnTTL is chosen by the fedfsFsn entry also contains a fedfsFsnTTL. The fedfsFsnTTL is
administrator as described in Section 2.8.3. chosen by the administrator as described in Section 2.8.3.
5.1.1.1. LDAP Request 5.1.1.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. the LDIF below.
dn: fedfsFsnUuid=$FSNUUID,$NCE dn: fedfsFsnUuid=$FSNUUID,$NCE
changeType: add changeType: add
objectClass: fedfsFsn objectClass: fedfsFsn
fedfsFsnUuid: $FSNUUID fedfsFsnUuid: $FSNUUID
fedfsFsnTTL: $TTL fedfsFsnTTL: $TTL
For example, if the $FSNUUID is "e8c4761c-eb3b-4307-86fc- For example, if $FSNUUID is "e8c4761c-eb3b-4307-86fc-f702da197966",
f702da197966", the $TTL is "300" seconds, and the $NCE is "o=fedfs" $TTL is "300" seconds, and $NCE is "o=fedfs", the operation would be:
the operation would be:
dn: fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs dn: fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs
changeType: add changeType: add
objectClass: fedfsFsn objectClass: fedfsFsn
fedfsFsnUuid: e8c4761c-eb3b-4307-86fc-f702da197966 fedfsFsnUuid: e8c4761c-eb3b-4307-86fc-f702da197966
fedfsFsnTTL: 300 fedfsFsnTTL: 300
5.1.2. Delete an FSN 5.1.2. Delete an FSN
This operation deletes an FSN by removing a fedfsFsn entry in the This operation deletes an FSN by removing a fedfsFsn entry in the
skipping to change at page 43, line 8 skipping to change at page 44, line 32
to the deleted FSN. to the deleted FSN.
5.1.2.1. LDAP Request 5.1.2.1. LDAP Request
This operation is implemented using the LDAP DELETE request described This operation is implemented using the LDAP DELETE request described
by the LDIF below. by the LDIF below.
dn: fedfsFsnUuid=$FSNUUID,$NCE dn: fedfsFsnUuid=$FSNUUID,$NCE
changeType: delete changeType: delete
For example, if the $FSNUUID is "e8c4761c-eb3b-4307-86fc- For example, if $FSNUUID is "e8c4761c-eb3b-4307-86fc-f702da197966"
f702da197966" and $NCE is "o=fedfs", the operation would be: and $NCE is "o=fedfs", the operation would be:
dn: fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs dn: fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs
changeType: delete changeType: delete
5.1.3. Create an FSL 5.1.3. Create an FSL
This operation creates a new FSL for the given FSN by adding a new This operation creates a new FSL for the given FSN by adding a new
fedfsFsl entry in the NSDB's LDAP directory. fedfsFsl entry in the NSDB's LDAP directory.
A fedfsFsl entry contains a fedfsFslUuid and fedfsFsnUuid. The A fedfsFsl entry contains a fedfsFslUuid and fedfsFsnUuid. The
administrator chooses the fedfsFslUuid. The process for choosing the administrator chooses the fedfsFslUuid. The process for choosing the
fedfsFslUuid is described in Section 2.12. The fedfsFsnUuid is the fedfsFslUuid is described in Section 2.12. The fedfsFsnUuid is the
UUID of the FSL's FSN. UUID of the FSL's FSN.
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
changeType: add changeType: add
objectClass: fedfsNfsFsl objectClass: fedfsNfsFsl
fedfsFslUuid: $FSLUUID fedfsFslUuid: $FSLUUID
fedfsFsnUuid: $FSNUUID fedfsFsnUuid: $FSNUUID
fedfsNfsURI: nfs://$HOST:$PORT//$PATH fedfsNfsURI: nfs://$HOST:$PORT//$PATH
fedfsNfsCurrency: $CURRENCY fedfsNfsCurrency: $CURRENCY
fedfsNfsGenFlagWritable: $WRITABLE fedfsNfsGenFlagWritable: $WRITABLE
fedfsNfsGenFlagGoing: $GOING fedfsNfsGenFlagGoing: $GOING
fedfsNfsGenFlagSplit: $SPLIT fedfsNfsGenFlagSplit: $SPLIT
skipping to change at page 44, line 30 skipping to change at page 45, line 36
fedfsNfsClassReaddir: $CLASS_READDIR fedfsNfsClassReaddir: $CLASS_READDIR
fedfsNfsReadRank: $READ_RANK fedfsNfsReadRank: $READ_RANK
fedfsNfsReadOrder: $READ_ORDER fedfsNfsReadOrder: $READ_ORDER
fedfsNfsWriteRank: $WRITE_RANK fedfsNfsWriteRank: $WRITE_RANK
fedfsNfsWriteOrder: $WRITE_ORDER fedfsNfsWriteOrder: $WRITE_ORDER
fedfsNfsVarSub: $VAR_SUB fedfsNfsVarSub: $VAR_SUB
fedfsNfsValidFor: $TIME fedfsNfsValidFor: $TIME
fedfsAnnotation: $ANNOTATION fedfsAnnotation: $ANNOTATION
fedfsDescr: $DESCR fedfsDescr: $DESCR
For example, if the $FSNUUID is "e8c4761c-eb3b-4307-86fc- For example, if $FSNUUID is "e8c4761c-eb3b-4307-86fc-f702da197966",
f702da197966", the $FSLUUID is "ba89a802-41a9-44cf-8447- $FSLUUID is "ba89a802-41a9-44cf-8447-dda367590eb3", $HOST is
dda367590eb3", the $HOST is "server.example.com", $PORT is "20049", "server.example.com", $PORT is "20049", $PATH is stored in the file
the $PATH is stored in the file "/tmp/fsl_path", $CURRENCY is "0" (an "/tmp/fsl_path", $CURRENCY is "0" (an up-to-date copy), the FSL is
up-to-date copy), the FSL is writable, but not going, split, or writable, but not going, split, or accessible via Remote Direct
accessible via RDMA, the simultaneous-use class is "1", the handle Memory Access (RDMA), the simultaneous-use class is "1", the handle
class is "0", the fileid class is "1", the write-verifier class is class is "0", the fileid class is "1", the write-verifier class is
"1", the change class is "1", the readdir class is "9", the read rank "1", the change class is "1", the readdir class is "9", the read rank
is "7", the read order is "8", the write rank is "5", the write order is "7", the read order is "8", the write rank is "5", the write order
is "6", variable substitution is false, $TIME is "300" seconds, is "6", variable substitution is false, $TIME is "300" seconds,
$ANNOTATION is ""foo" = "bar"", $DESC is "This is a description.", $ANNOTATION is ""foo" = "bar"", $DESC is "This is a description.",
and the $NCE is "o=fedfs", the operation would be (for readability and $NCE is "o=fedfs", the operation would be (for readability, the
the DN is split into two lines): DN is split into two lines):
dn: fedfsFslUuid=ba89a802-41a9-44cf-8447-dda367590eb3, dn: fedfsFslUuid=ba89a802-41a9-44cf-8447-dda367590eb3,
fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs
changeType: add changeType: add
objectClass: fedfsNfsFsl objectClass: fedfsNfsFsl
fedfsFslUuid: ba89a802-41a9-44cf-8447-dda367590eb3 fedfsFslUuid: ba89a802-41a9-44cf-8447-dda367590eb3
fedfsFsnUuid: e8c4761c-eb3b-4307-86fc-f702da197966 fedfsFsnUuid: e8c4761c-eb3b-4307-86fc-f702da197966
fedfsNfsURI: nfs://server.example.com:20049//tmp/fsl_path fedfsNfsURI: nfs://server.example.com:20049//tmp/fsl_path
fedfsNfsCurrency: 0 fedfsNfsCurrency: 0
fedfsNfsGenFlagWritable: TRUE fedfsNfsGenFlagWritable: TRUE
skipping to change at page 45, line 34 skipping to change at page 46, line 34
fedfsNfsReadOrder: 8 fedfsNfsReadOrder: 8
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 accessible The fedfsNfsFSl object class is used to describe NFSv4-accessible
filesets. For the reasons described in Section 2.8.4, administrators filesets. For the reasons described in Section 2.8.4, administrators
SHOULD choose reasonable values for all LDAP attributes of an NFSv4 SHOULD choose reasonable values for all LDAP attributes of an
accessible fedfsNfsFsl even though some of these LDAP attributes are NFSv4-accessible fedfsNfsFsl even though some of these LDAP
not explicitly contained in an NFSv4 fs_locations attribute. attributes are not explicitly contained in an NFSv4 fs_locations
attribute.
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 an NFSv4 fs_locations LDAP attributes not explicitly contained in an NFSv4 fs_locations
attribute, the values in the following table are RECOMMENDED. attribute, the values in the following table are RECOMMENDED.
+-------------------------+----------+------------------------------+ +-------------------------+----------+------------------------------+
| LDAP attribute | LDAP | Notes | | LDAP attribute | LDAP | Notes |
| | value | | | | value | |
+-------------------------+----------+------------------------------+ +-------------------------+----------+------------------------------+
| fedfsNfsCurrency | negative | Indicates that the server | | fedfsNfsCurrency | negative | Indicates that the server |
| | value | does not know the currency | | | value | does not know the currency |
| | | (see 11.10.1 of [RFC5661]). | | | | (see Section 11.10.1 of |
| | | [RFC5661]). |
| fedfsNfsGenFlagWritable | FALSE | Leaving unset is not harmful | | fedfsNfsGenFlagWritable | FALSE | Leaving unset is not harmful |
| | | (see 11.10.1 of [RFC5661]). | | | | (see Section 11.10.1 of |
| | | [RFC5661]). |
| fedfsNfsGenFlagGoing | FALSE | NFS client will detect a | | fedfsNfsGenFlagGoing | FALSE | NFS client will detect a |
| | | migration event if the FSL | | | | migration event if the FSL |
| | | becomes unavailable. | | | | becomes unavailable. |
| fedfsNfsGenFlagSplit | TRUE | Safe to assume that the FSL | | fedfsNfsGenFlagSplit | TRUE | Safe to assume that the FSL |
| | | is split. | | | | is split. |
| fedfsNfsTransFlagRdma | TRUE | NFS client will detect if | | fedfsNfsTransFlagRdma | TRUE | NFS client will detect if |
| | | RDMA access is available. | | | | RDMA access is available. |
| fedfsNfsClassSimul | 0 | 0 is treated as non-matching | | fedfsNfsClassSimul | 0 | 0 is treated as non-matching |
| | | (see 11.10.1 of [RFC5661]). | | | | (see Section 11.10.1 of |
| | | [RFC5661]). |
| fedfsNfsClassHandle | 0 | See fedfsNfsClassSimul note. | | fedfsNfsClassHandle | 0 | See fedfsNfsClassSimul note. |
| fedfsNfsClassFileid | 0 | See fedfsNfsClassSimul note. | | fedfsNfsClassFileid | 0 | See fedfsNfsClassSimul note. |
| fedfsNfsClassWritever | 0 | See fedfsNfsClassSimul note. | | fedfsNfsClassWritever | 0 | See fedfsNfsClassSimul note. |
| fedfsNfsClassChange | 0 | See fedfsNfsClassSimul note. | | fedfsNfsClassChange | 0 | See fedfsNfsClassSimul note. |
| fedfsNfsClassReaddir | 0 | See fedfsNfsClassSimul note. | | fedfsNfsClassReaddir | 0 | See fedfsNfsClassSimul note. |
| fedfsNfsReadRank | 0 | Highest value ensures FSL | | fedfsNfsReadRank | 0 | Highest value ensures FSL |
| | | will be tried. | | | | will be tried. |
| fedfsNfsReadOrder | 0 | See fedfsNfsReadRank note. | | fedfsNfsReadOrder | 0 | See fedfsNfsReadRank note. |
| fedfsNfsWriteRank | 0 | See fedfsNfsReadRank note. | | fedfsNfsWriteRank | 0 | See fedfsNfsReadRank note. |
| fedfsNfsWriteOrder | 0 | See fedfsNfsReadRank note. | | fedfsNfsWriteOrder | 0 | See fedfsNfsReadRank note. |
| fedfsNfsVarSub | FALSE | NFSv4 does not define | | fedfsNfsVarSub | FALSE | NFSv4 does not define |
| | | variable substitution in | | | | variable substitution in |
| | | paths. | | | | paths. |
| fedfsNfsValidFor | 0 | Indicates no appropriate | | fedfsNfsValidFor | 0 | Indicates no appropriate |
| | | refetch interval (see | | | | refetch interval (see |
| | | 11.10.2 of [RFC5661]). | | | | Section 11.10.2 of |
| | | [RFC5661]). |
+-------------------------+----------+------------------------------+ +-------------------------+----------+------------------------------+
5.1.4. Delete an FSL 5.1.4. Delete an FSL
This operation deletes an FSL record. The admin requests the NSDB This operation deletes an FSL record. The admin requests the NSDB
node storing the fedfsFsl to delete it from its database. This node storing the fedfsFsl to delete it from its database. This
operation does not result in fileset data being deleted on any operation does not result in fileset data being deleted on any
fileserver. fileserver.
5.1.4.1. LDAP Request 5.1.4.1. LDAP Request
The admin sends an LDAP DELETE request to the NSDB node to remove the The admin sends an LDAP DELETE request to the NSDB node to remove the
FSL. FSL.
dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE
changeType: delete changeType: delete
For example, if the $FSNUUID is "e8c4761c-eb3b-4307-86fc- For example, if $FSNUUID is "e8c4761c-eb3b-4307-86fc-f702da197966",
f702da197966", the $FSLUUID is "ba89a802-41a9-44cf-8447- $FSLUUID is "ba89a802-41a9-44cf-8447-dda367590eb3", and $NCE is
dda367590eb3", and the $NCE is "o=fedfs", the operation would be (for "o=fedfs", the operation would be (for readability, the DN is split
readability the DN is split into two lines): into two lines):
dn: fedfsFslUuid=ba89a802-41a9-44cf-8447-dda367590eb3, dn: fedfsFslUuid=ba89a802-41a9-44cf-8447-dda367590eb3,
fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs
changeType: delete changeType: delete
5.1.5. Update an FSL 5.1.5. Update an FSL
This operation updates the attributes of a given FSL. This command This operation updates the attributes of a given FSL. This command
results in a change in the attributes of the fedfsFsl at the NSDB results in a change in the attributes of the fedfsFsl at the NSDB
node maintaining this FSL. The values of the fedfsFslUuid and node maintaining this FSL. The values of the fedfsFslUuid and
skipping to change at page 47, line 33 skipping to change at page 48, line 38
5.1.5.1. LDAP Request 5.1.5.1. LDAP Request
The admin sends an LDAP MODIFY request to the NSDB node to update the The admin sends an LDAP MODIFY request to the NSDB node to update the
FSL. FSL.
dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE
changeType: modify changeType: modify
replace: $ATTRIBUTE-TYPE replace: $ATTRIBUTE-TYPE
For example, if the $FSNUUID is "e8c4761c-eb3b-4307-86fc- For example, if $FSNUUID is "e8c4761c-eb3b-4307-86fc-f702da197966",
f702da197966", the $FSLUUID is "ba89a802-41a9-44cf-8447- $FSLUUID is "ba89a802-41a9-44cf-8447-dda367590eb3", $NCE is
dda367590eb3", the $NCE is "o=fedfs", and the administrator wished to "o=fedfs", and the administrator wished to change the NFS read rank
change the NFS read rank to 10, the operation would be (for to 10, the operation would be (for readability, the DN is split into
readability the DN is split into two lines): two lines):
dn: fedfsFslUuid=ba89a802-41a9-44cf-8447-dda367590eb3, dn: fedfsFslUuid=ba89a802-41a9-44cf-8447-dda367590eb3,
fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs
changeType: modify changeType: modify
replace: fedfsNfsReadClass replace: fedfsNfsReadClass
fedfsNfsReadRank: 10 fedfsNfsReadRank: 10
5.2. NSDB Operations for Fileservers 5.2. NSDB Operations for Fileservers
5.2.1. NSDB Container Entry (NCE) Enumeration 5.2.1. NSDB Container Entry (NCE) Enumeration
skipping to change at page 48, line 31 skipping to change at page 49, line 31
* (objectClass=fedfsNsdbContainerInfo) * (objectClass=fedfsNsdbContainerInfo)
* *
*/ */
if a fedfsNceDN value is found if a fedfsNceDN value is found
add the value to the nce_list add the value 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 Universal Resource Identifier (URI) following examples use the LDAP Uniform Resource Identifier (URI)
format defined in [RFC4516]. 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/fedfsFsnUuid=$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
"fedfsFsnUuid=$FSNUUID,$NCE" with a filter for "fedfsFsnUuid=$FSNUUID,$NCE" with a filter for
"objectClass=fedfsFsl". The scope value of "one" restricts the "objectClass=fedfsFsl". The scope value of "one" restricts the
search to the entry's children (rather than the entire subtree below search to the entry's children (rather than the entire subtree below
the entry) and the filter ensures that only FSL entries are returned. the entry), and the filter ensures that only FSL entries are
returned.
For example if $NSDBNAME is "nsdb.example.com", $FSNUUID is For example, if $NSDBNAME is "nsdb.example.com", $FSNUUID is
"e8c4761c-eb3b-4307-86fc-f702da197966", and $NCE is "o=fedfs", the "e8c4761c-eb3b-4307-86fc-f702da197966", and $NCE is "o=fedfs", the
search would be (for readability the URI is split into three lines): search would be (for readability, the URI is split into three lines):
ldap://nsdb.example.com/ ldap://nsdb.example.com/
fsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs
??one?(objectClass=fedfsFsl) ??one?(objectClass=fedfsFsl)
The following search can be used to obtain only the NFS FSLs for The following search can be used to obtain only the NFS FSLs for
$FSNUUID on the NSDB named $NSDBNAME (for readability the URI is $FSNUUID on the NSDB named $NSDBNAME (for readability, the URI is
split into two lines): split into two lines):
for each $NCE in nce_list for each $NCE in nce_list
ldap://$NSDBNAME/fsnUuid=$FSNUUID,$NCE??one? ldap://$NSDBNAME/fedfsFsnUuid=$FSNUUID,$NCE??one?
(objectClass=fedfsNfsFsl) (objectClass=fedfsNfsFsl)
This also searches for the children of the object with DN This also searches for the children of the object with DN
"fedfsFsnUuid=$FSNUUID,$NCE", but the filter for "objectClass = "fedfsFsnUuid=$FSNUUID,$NCE", but the filter for "objectClass =
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 "e8c4761c- For example, if $NSDBNAME is nsdb.example.com, $FSNUUID is "e8c4761c-
eb3b-4307-86fc-f702da197966", and $NCE is "o=fedfs",the search would eb3b-4307-86fc-f702da197966", 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=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,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.8.4. Section 2.8.4.
5.3. NSDB Operations and LDAP Referrals 5.3. NSDB Operations and LDAP Referrals
The LDAPv3 protocol defines an LDAP referral mechanism that allows an The LDAPv3 protocol defines an LDAP referral mechanism that allows an
LDAP server to redirect an LDAP client. LDAPv3 defines two types of LDAP server to redirect an LDAP client. LDAPv3 defines two types of
LDAP referrals: the Referral type defined in Section 4.1.10 of LDAP referrals: the Referral type defined in Section 4.1.10 of
[RFC4511] and the SearchResultReference type defined in Section 4.5.3 [RFC4511] and the SearchResultReference type defined in Section 4.5.3
of [RFC4511]. In both cases, the LDAP referral lists one or more 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 URIs for services that can be used to complete the operation. In the
remainder of this document, the term LDAP referral is used to remainder of this document, the term "LDAP referral" is used to
indicate either of these types. indicate either of these types.
If an NSDB operation results in an LDAP referral, the NSDB client MAY 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 follow the LDAP referral. An NSDB client's decision to follow an
LDAP referral is implementation and configuration dependent. For LDAP referral is implementation and configuration dependent. For
example, an NSDB client might be configured to follow only those LDAP example, an NSDB client might be configured to follow only those LDAP
referrals that were received over a secure channel, or only those referrals that were received over a secure channel or only those that
that target an NSDB that supports encrypted communication. If an target an NSDB that supports encrypted communication. If an NSDB
NSDB client chooses to follow an LDAP referral, the NSDB client MUST client chooses to follow an LDAP referral, the NSDB client MUST
process the LDAP referral and prevent looping as described in Section process the LDAP referral and prevent looping as described in
4.1.10 of [RFC4511]. Section 4.1.10 of [RFC4511].
6. Security Considerations 6. Security Considerations
Both the NFSv4 and LDAPv3 protocols provide security mechanisms. Both the NFSv4 and LDAPv3 protocols provide security mechanisms.
When used in conjunction with the federated filesystem protocols When used in conjunction with the federated file system protocols
described in this document, the use of these mechanisms is described in this document, the use of these mechanisms is
RECOMMENDED. Specifically, the use of RPCSEC_GSS [RFC2203], which is RECOMMENDED. Specifically, the use of RPCSEC_GSS [RFC2203], which is
built on the GSS-API [RFC2743], is RECOMMENDED on all NFS connections built on the Generic Security Service Application Program Interface
between a file-access client and fileserver. The "Security (GSS-API) [RFC2743], is RECOMMENDED on all NFS connections between a
Considerations" sections of the NFSv4.0 [3530bis] and NFSv4.1 file-access client and fileserver. The security considerations
[RFC5661] specifications contain special considerations for the sections of the NFSv4.0 [RFC7530] and NFSv4.1 [RFC5661]
handling of GETATTR operations for the fs_locations and specifications contain special considerations for the handling of
fs_locations_info attributes. GETATTR operations for the fs_locations and fs_locations_info
attributes.
NSDB nodes and NSDB clients MUST implement support for TLS [RFC5246], NSDB nodes and NSDB clients MUST implement support for TLS [RFC5246],
as described in [RFC4513]. For all LDAP connections established by as described in [RFC4513]. For all LDAP connections established by
the federated filesystem protocols, the use of TLS is RECOMMENDED. the federated file system protocols, the use of TLS is RECOMMENDED.
If an NSDB client chooses to follow an LDAP referral, the NSDB client If an NSDB client chooses to follow an LDAP referral, the NSDB client
SHOULD authenticate the LDAP referral's target NSDB using the target SHOULD authenticate the LDAP referral's target NSDB using the target
NSDB's credentials (not the credentials of the NSDB that generated NSDB's credentials (not the credentials of the NSDB that generated
the LDAP referral). The NSDB client SHOULD NOT follow an LDAP 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 referral that targets an NSDB for which it does not know the NSDB's
credentials. 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 a file-access client's filesystem I/O operations (e.g., by with a file-access client's file system input/output (I/O) operations
returning fictitious data in the response to a read request) or (e.g., by returning fictitious data in the response to a read
fabricating a referral. The attacker's abilities are the same request) or can fabricate a referral. The attacker's abilities are
regardless of whether or not the federation protocols are in use. the same regardless of whether or not the federation protocols are in
While the federation protocols do not give the attacker additional use. While the federation protocols do not give the attacker
capabilities, they are additional targets for attack. The LDAP additional capabilities, they are additional targets for attack. The
protocol described in Section 5.2 SHOULD be secured using the methods LDAP protocol described in Section 5.2 SHOULD be secured using the
described above to defeat attacks on a fileserver via this channel. methods 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 operations described in fileservers that query it. The LDAP operations described in
Section 5 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.
A fileserver binds anonymously when performing NSDB operations. Thus A fileserver binds anonymously when performing NSDB operations.
the contents and distinguished names of FSN and FSL records are Thus, the contents and distinguished names of FSN and FSL records are
required to be readable by anyone who can bind anonymously to an NSDB required to be readable by anyone who can bind anonymously to an NSDB
service. Section 2.12 presents the security considerations in the service. Section 2.12 presents the security considerations in the
choice of the type of UUID used in these records. choice of the type of UUID used in these records.
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 file system 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 file-access client and fileserver just as they would occur between a file-access client and fileserver just as they would
if the federation protocols were not in use. As a result, the if the federation protocols were not in use. As a result, the
federation protocols do not require new user authentication and federation protocols do not require new user authentication and
authorization mechanisms or require a fileserver to act as a proxy authorization mechanisms or require a fileserver to act as a proxy
for a client. for a client.
7. IANA Considerations 7. IANA Considerations
7.1. Registry for the fedfsAnnotation Key Namespace 7.1. Registry for the fedfsAnnotation Key Namespace
This document defines the fedfsAnnotation key in Section 4.2.1.6. This document defines the fedfsAnnotation key in Section 4.2.1.6.
The fedfsAnnotation key namespace is to be managed by IANA. IANA is The fedfsAnnotation key namespace is managed by IANA. IANA has
to create and maintain a new registry entitled "FedFS Annotation created and now maintains a new registry entitled "FedFS Annotation
Keys". The location of this registry should be under a new heading Keys". The location of this registry is under a new heading called
called "Federated File System (FedFS) Parameters". The URL address "Federated File System (FedFS) Parameters". The URL address is
can be based off of the new heading name, for example: <http://www.iana.org/assignments/fedfs-parameters>.
http://www.iana.org/assignments/fedfs-parameters/ ...
Future registrations are to be administered by IANA using the "First Future registrations are to be administered by IANA using the "First
Come First Served" policy defined in [RFC5226]. Registration Come First Served" policy defined in [RFC5226]. Registration
requests MUST include the key (a valid UTF-8 string of any length), a requests MUST include the key (a valid UTF-8 string of any length), a
brief description of the key's purpose, and an email contact for the brief description of the key's purpose, and an email contact for the
registration. For viewing, the registry should be sorted registration. For viewing, the registry should be sorted
lexicographically by key. There are no initial assignments for this lexicographically by key. There are no initial assignments for this
registry. registry.
7.2. Registry for FedFS Object Identifiers 7.2. Registry for FedFS Object Identifiers
Using the process described in [RFC2578], one of the authors was Using the process described in [RFC2578], one of the authors was
assigned the Internet Private Enterprise Numbers range assigned the Internet Private Enterprise Numbers range
1.3.6.1.4.1.31103.x. Within this range, the subrange 1.3.6.1.4.1.31103.x. Within this range, the subrange
1.3.6.1.4.1.31103.1.x is permanently dedicated for use by the 1.3.6.1.4.1.31103.1.x is permanently dedicated for use by the
federated file system protocols. Unassigned OIDs in this range MAY federated file system protocols. Unassigned OIDs in this range MAY
be used for Private Use or Experimental Use as defined in [RFC5226]. be used for Private Use or Experimental Use as defined in [RFC5226].
New permanent FedFS OID assignments MUST NOT be made using OIDs in New permanent FedFS OID assignments MUST NOT be made using OIDs in
this range. this range.
IANA is to create and maintain a new registry entitled "FedFS Object IANA has created and now maintains a new registry entitled "FedFS
Identifiers" for the purpose of recording the allocations of FedFS Object Identifiers" for the purpose of recording the allocations of
Object Identifiers (OIDs) specified by this document. No future FedFS Object Identifiers (OIDs) specified by this document. No
allocations in this registry are allowed. future allocations in this registry are allowed.
The location of this registry should be under the heading "Federated The location of this registry is under the heading "Federated File
File System (FedFS) Parameters", created in Section 7.1. The URL System (FedFS) Parameters", created in Section 7.1. The URL address
address can be based off of the new heading name, for example: is <http://www.iana.org/assignments/fedfs-parameters>.
http://www.iana.org/assignments/fedfs-parameters/ ...
For viewing, the registry should be sorted numerically by OID value. For viewing, the registry has been sorted numerically by OID value.
The contents of the FedFS Object Identifiers registry are given in The contents of the "FedFS Object Identifiers" registry are given in
Table 1. Table 1.
Note: A descriptor designated below as "historic" reserves an OID Note: A descriptor designated below as "historic" reserves an OID
used in a past version of the NSDB protocol. Registering such OIDs used in a past version of the NSDB protocol. Registering such OIDs
retains compatibility among existing implementations of the NSDB retains compatibility among existing implementations of the NSDB
protocol. This document does not otherwise refer to historic OIDs. protocol. This document does not otherwise refer to historic OIDs.
+--------------------------+-------------------------+-----------+ +---------------------------+--------------------------+-----------+
| OID | Description | Reference | | OID | Description | Reference |
+--------------------------+-------------------------+-----------+ +---------------------------+--------------------------+-----------+
| 1.3.6.1.4.1.31103.1.1 | fedfsUuid | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.1 | fedfsUuid | RFC 7532 |
| 1.3.6.1.4.1.31103.1.2 | fedfsNetAddr | historic | | 1.3.6.1.4.1.31103.1.2 | fedfsNetAddr | historic |
| 1.3.6.1.4.1.31103.1.3 | fedfsNetPort | historic | | 1.3.6.1.4.1.31103.1.3 | fedfsNetPort | historic |
| 1.3.6.1.4.1.31103.1.4 | fedfsFsnUuid | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.4 | fedfsFsnUuid | RFC 7532 |
| 1.3.6.1.4.1.31103.1.5 | fedfsNsdbName | historic | | 1.3.6.1.4.1.31103.1.5 | fedfsNsdbName | historic |
| 1.3.6.1.4.1.31103.1.6 | fedfsNsdbPort | historic | | 1.3.6.1.4.1.31103.1.6 | fedfsNsdbPort | historic |
| 1.3.6.1.4.1.31103.1.7 | fedfsNcePrefix | historic | | 1.3.6.1.4.1.31103.1.7 | fedfsNcePrefix | historic |
| 1.3.6.1.4.1.31103.1.8 | fedfsFslUuid | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.8 | fedfsFslUuid | RFC 7532 |
| 1.3.6.1.4.1.31103.1.9 | fedfsFslHost | historic | | 1.3.6.1.4.1.31103.1.9 | fedfsFslHost | historic |
| 1.3.6.1.4.1.31103.1.10 | fedfsFslPort | historic | | 1.3.6.1.4.1.31103.1.10 | fedfsFslPort | historic |
| 1.3.6.1.4.1.31103.1.11 | fedfsFslTTL | historic | | 1.3.6.1.4.1.31103.1.11 | fedfsFslTTL | historic |
| 1.3.6.1.4.1.31103.1.12 | fedfsAnnotation | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.12 | fedfsAnnotation | RFC 7532 |
| 1.3.6.1.4.1.31103.1.13 | fedfsDescr | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.13 | fedfsDescr | RFC 7532 |
| 1.3.6.1.4.1.31103.1.14 | fedfsNceDN | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.14 | fedfsNceDN | RFC 7532 |
| 1.3.6.1.4.1.31103.1.15 | fedfsFsnTTL | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.15 | fedfsFsnTTL | RFC 7532 |
| 1.3.6.1.4.1.31103.1.100 | fedfsNfsPath | historic | | 1.3.6.1.4.1.31103.1.100 | fedfsNfsPath | historic |
| 1.3.6.1.4.1.31103.1.101 | fedfsNfsMajorVer | historic | | 1.3.6.1.4.1.31103.1.101 | fedfsNfsMajorVer | historic |
| 1.3.6.1.4.1.31103.1.102 | fedfsNfsMinorVer | historic | | 1.3.6.1.4.1.31103.1.102 | fedfsNfsMinorVer | historic |
| 1.3.6.1.4.1.31103.1.103 | fedfsNfsCurrency | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.103 | fedfsNfsCurrency | RFC 7532 |
| 1.3.6.1.4.1.31103.1.104 | fedfsNfsGenFlagWritable | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.104 | fedfsNfsGenFlagWritable | RFC 7532 |
| 1.3.6.1.4.1.31103.1.105 | fedfsNfsGenFlagGoing | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.105 | fedfsNfsGenFlagGoing | RFC 7532 |
| 1.3.6.1.4.1.31103.1.106 | fedfsNfsGenFlagSplit | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.106 | fedfsNfsGenFlagSplit | RFC 7532 |
| 1.3.6.1.4.1.31103.1.107 | fedfsNfsTransFlagRdma | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.107 | fedfsNfsTransFlagRdma | RFC 7532 |
| 1.3.6.1.4.1.31103.1.108 | fedfsNfsClassSimul | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.108 | fedfsNfsClassSimul | RFC 7532 |
| 1.3.6.1.4.1.31103.1.109 | fedfsNfsClassHandle | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.109 | fedfsNfsClassHandle | RFC 7532 |
| 1.3.6.1.4.1.31103.1.110 | fedfsNfsClassFileid | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.110 | fedfsNfsClassFileid | RFC 7532 |
| 1.3.6.1.4.1.31103.1.111 | fedfsNfsClassWritever | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.111 | fedfsNfsClassWritever | RFC 7532 |
| 1.3.6.1.4.1.31103.1.112 | fedfsNfsClassChange | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.112 | fedfsNfsClassChange | RFC 7532 |
| 1.3.6.1.4.1.31103.1.113 | fedfsNfsClassReaddir | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.113 | fedfsNfsClassReaddir | RFC 7532 |
| 1.3.6.1.4.1.31103.1.114 | fedfsNfsReadRank | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.114 | fedfsNfsReadRank | RFC 7532 |
| 1.3.6.1.4.1.31103.1.115 | fedfsNfsReadOrder | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.115 | fedfsNfsReadOrder | RFC 7532 |
| 1.3.6.1.4.1.31103.1.116 | fedfsNfsWriteRank | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.116 | fedfsNfsWriteRank | RFC 7532 |
| 1.3.6.1.4.1.31103.1.117 | fedfsNfsWriteOrder | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.117 | fedfsNfsWriteOrder | RFC 7532 |
| 1.3.6.1.4.1.31103.1.118 | fedfsNfsVarSub | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.118 | fedfsNfsVarSub | RFC 7532 |
| 1.3.6.1.4.1.31103.1.119 | fedfsNfsValidFor | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.119 | fedfsNfsValidFor | RFC 7532 |
| 1.3.6.1.4.1.31103.1.120 | fedfsNfsURI | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.120 | fedfsNfsURI | RFC 7532 |
| 1.3.6.1.4.1.31103.1.1001 | fedfsNsdbContainerInfo | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.1001 | fedfsNsdbContainerInfo | RFC 7532 |
| 1.3.6.1.4.1.31103.1.1002 | fedfsFsn | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.1002 | fedfsFsn | RFC 7532 |
| 1.3.6.1.4.1.31103.1.1003 | fedfsFsl | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.1003 | fedfsFsl | RFC 7532 |
| 1.3.6.1.4.1.31103.1.1004 | fedfsNfsFsl | RFC-TBD1 | | 1.3.6.1.4.1.31103.1.1004 | fedfsNfsFsl | RFC 7532 |
+--------------------------+-------------------------+-----------+ +---------------------------+--------------------------+-----------+
Table 1 Table 1
7.3. LDAP Descriptor Registration 7.3. LDAP Descriptor Registration
In accordance with Section 3.4 and Section 4 of [RFC4520], the object In accordance with Sections 3.4 and 4 of [RFC4520], the object
identifier descriptors defined in this document (listed below) will identifier descriptors defined in this document (listed below) have
be registered via the Expert Review process. been registered via the Expert Review process.
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: RFC 7532
Author/Change Controller: IESG (iesg@ietf.org) Author/Change Controller: IESG (iesg@ietf.org)
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
Object Identifier: 1.3.6.1.4.1.31103.1.2 Object Identifier: 1.3.6.1.4.1.31103.1.2
Descriptor (short name): fedfsNetAddr Descriptor (short name): fedfsNetAddr
Usage: attribute type (historic) Usage: attribute type (historic)
skipping to change at page 58, line 8 skipping to change at page 58, line 40
Usage: object class Usage: object class
8. Glossary 8. Glossary
Administrator: A user with the necessary authority to initiate Administrator: A 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.
File-access Client: Standard off-the-shelf network attached storage File-Access Client: Standard off-the-shelf, network-attached storage
(NAS) client software that communicates with fileservers using a (NAS) client software that communicates with fileservers using a
standard file-access protocol. standard file-access protocol.
Federation: A set of fileserver collections and singleton Federation: A set of fileserver collections and singleton
fileservers that use a common set of interfaces and protocols in fileservers that use a common set of interfaces and protocols in
order to provide to file-access clients a federated namespace order to provide to file-access clients a federated namespace
accessible through a filesystem access protocol. accessible through a file system access protocol.
Fileserver: A server that stores physical fileset data, or refers Fileserver: A server that stores physical fileset data or refers
file-access clients to other fileservers. A fileserver provides file-access clients to other fileservers. A fileserver provides
access to its shared filesystem data via a file-access protocol. access to its shared file system data via a file-access protocol.
Fileset: The abstraction of a set of files and the directory tree Fileset: The abstraction of a set of files and the directory tree
that contains them. 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 file systems.
Filesystem: A self-contained unit of export for a fileserver, and File System: 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 file system, nor at the
point for the filesystem. export point for the file system.
A single filesystem MAY implement more than one fileset, if the A single file system MAY implement more than one fileset, if the
file-access protocol and the fileserver permit this. file-access protocol and the fileserver permit this.
File-access Protocol: A network filesystem access protocol such as File-Access Protocol: A network file system access protocol such as
NFSv3 [RFC1813], NFSv4 [3530bis], or CIFS (Common Internet File NFSv3 [RFC1813], NFSv4 [RFC7530], or CIFS (Common Internet File
System) [MS-SMB] [MS-SMB2] [MS-CIFS]. 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. An 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 file-access client can access directly, such as an resource that a file-access client can access directly, such as an
fs_locations attribute (for NFSv4), or a share name (for CIFS). fs_locations attribute (for NFSv4) or a share name (for CIFS).
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 file system 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
file-access client can observe. file-access 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 information) that implement a given partition of the
FSNs.
Referral: A server response to a file-access client access that Referral: A server response to a file-access client access that
directs the client to evaluate the current object as a reference directs the client to evaluate the current object as a reference
to an object at a different location (specified by an FSL) in to an object at a different location (specified by an FSL) in
another fileset, and possibly hosted on another fileserver. The another fileset and possibly hosted on another fileserver. The
client re-attempts the access to the object at the new location. client re-attempts the access to the object at the new location.
Replica: A replica is a redundant implementation of a fileset. Each Replica: A redundant implementation of a fileset. Each replica
replica shares the same FSN, but has a different FSL. shares the same FSN but has a different FSL.
Replicas may be used to increase availability or performance. Replicas may be used to increase availability or performance.
Updates to replicas of the same fileset MUST appear to occur in Updates to replicas of the same fileset MUST appear to occur in
the same order, and therefore each replica is self-consistent at the same order; therefore, each replica is self-consistent at any
any moment. moment.
We do not assume that updates to each replica occur We do not assume that updates to each replica occur
simultaneously. If a replica is offline or unreachable, the other simultaneously. If a replica is offline or unreachable, the other
replicas may be updated. replicas may be updated.
Server Collection: A set of fileservers administered as a unit. A Server Collection: A set of fileservers administered as a unit. A
server collection may be administered with vendor-specific server collection may be administered with vendor-specific
software. software.
The namespace provided by a server collection could be part of the The namespace provided by a server collection could be part of the
federated namespace. federated namespace.
Singleton Server: A server collection containing only one server; a Singleton Server: A server collection containing only one server; a
stand-alone fileserver. stand-alone fileserver.
9. References 9. References
9.1. Normative References
[3530bis] Haynes, T. and D. Noveck, "NFS Version 4 Protocol", 9.1. Normative References
draft-ietf-nfsv4-rfc3530bis (Work In Progress), 2010.
[RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an [RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an
Object Class to Hold Uniform Resource Identifiers (URIs)", Object Class to Hold Uniform Resource Identifiers (URIs)",
RFC 2079, January 1997. RFC 2079, January 1997,
<http://www.rfc-editor.org/info/rfc2079>.
[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,
<http://www.rfc-editor.org/info/rfc2119>.
[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,
<http://www.rfc-editor.org/info/rfc2203>.
[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,
<http://www.rfc-editor.org/info/rfc2578>.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000,
<http://www.rfc-editor.org/info/rfc2743>.
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
Technical Specification", RFC 2849, June 2000. Technical Specification", RFC 2849, June 2000,
<http://www.rfc-editor.org/info/rfc2849>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003,
<http://www.rfc-editor.org/info/rfc3629>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66, RFC
RFC 3986, January 2005. 3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122, July
July 2005. 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, (LDAP): Technical Specification Road Map", RFC 4510, June
June 2006. 2006, <http://www.rfc-editor.org/info/rfc4510>.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
(LDAP): The Protocol", RFC 4511, June 2006. Protocol (LDAP): The Protocol", RFC 4511, June 2006,
<http://www.rfc-editor.org/info/rfc4511>.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4512] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, (LDAP): Directory Information Models", RFC 4512, June
June 2006. 2006, <http://www.rfc-editor.org/info/rfc4512>.
[RFC4513] Harrison, R., "Lightweight Directory Access Protocol [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
(LDAP): Authentication Methods and Security Mechanisms", (LDAP): Authentication Methods and Security Mechanisms",
RFC 4513, June 2006. RFC 4513, June 2006,
<http://www.rfc-editor.org/info/rfc4513>.
[RFC4516] Smith, M. and T. Howes, "Lightweight Directory Access [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access
Protocol (LDAP): Uniform Resource Locator", RFC 4516, Protocol (LDAP): Uniform Resource Locator", RFC 4516, June
June 2006. 2006, <http://www.rfc-editor.org/info/rfc4516>.
[RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
Syntaxes and Matching Rules", RFC 4517, June 2006. (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006,
<http://www.rfc-editor.org/info/rfc4517>.
[RFC4519] Sciberras, A., "Lightweight Directory Access Protocol [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519, (LDAP): Schema for User Applications", RFC 4519, June
June 2006. 2006, <http://www.rfc-editor.org/info/rfc4519>.
[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,
<http://www.rfc-editor.org/info/rfc4520>.
[RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP) entryUUID Operational Attribute", RFC 4530, (LDAP) entryUUID Operational Attribute", RFC 4530, June
June 2006. 2006, <http://www.rfc-editor.org/info/rfc4530>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[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,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
System (NFS) Version 4 Minor Version 1 Protocol", "Network File System (NFS) Version 4 Minor Version 1
RFC 5661, January 2010. Protocol", RFC 5661, January 2010,
<http://www.rfc-editor.org/info/rfc5661>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", RFC 7530, March 2015,
<http://www.rfc-editor.org/info/rfc7530>.
9.2. Informative References 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 , Proceedings of the USENIX Winter Technical Conference ,
1988. 1988.
[FEDFS-ADMIN]
Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Naik, "Administration Protocol for Federated Filesystems",
draft-ietf-nfsv4-federated-fs-admin (Work In Progress),
2010.
[MS-CIFS] Microsoft Corporation, "Common Internet File System (CIFS) [MS-CIFS] Microsoft Corporation, "Common Internet File System (CIFS)
Protocol Specification", MS-CIFS 2.0, November 2009. Protocol Specification", MS-CIFS 24.0, May 2014.
[MS-SMB] Microsoft Corporation, "Server Message Block (SMB) [MS-SMB] Microsoft Corporation, "Server Message Block (SMB)
Protocol Specification", MS-SMB 17.0, November 2009. Protocol Specification", MS-SMB 43.0, May 2014.
[MS-SMB2] Microsoft Corporation, "Server Message Block (SMB) Version [MS-SMB2] Microsoft Corporation, "Server Message Block (SMB) Version
2 Protocol Specification", MS-SMB2 19.0, November 2009. 2 Protocol Specification", MS-SMB2 46.0, May 2014.
[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,
<http://www.rfc-editor.org/info/rfc1813>.
[RFC2224] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997. [RFC2224] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997,
<http://www.rfc-editor.org/info/rfc2224>.
[RFC3254] Alvestrand, H., "Definitions for talking about [RFC3254] Alvestrand, H., "Definitions for talking about
directories", RFC 3254, April 2002. directories", RFC 3254, April 2002,
<http://www.rfc-editor.org/info/rfc3254>.
[RFC5662] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
System (NFS) Version 4 Minor Version 1 External Data "Network File System (NFS) Version 4 Minor Version 1
Representation Standard (XDR) Description", RFC 5662, External Data Representation Standard (XDR) Description",
January 2010. RFC 5662, January 2010,
<http://www.rfc-editor.org/info/rfc5662>.
[RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Naik, "Requirements for Federated File Systems", RFC 5716, Naik, "Requirements for Federated File Systems", RFC 5716,
January 2010. January 2010, <http://www.rfc-editor.org/info/rfc5716>.
[RFC6641] Everhart, C., Adamson, W., and J. Zhang, "Using DNS SRV to [RFC6641] Everhart, C., Adamson, W., and J. Zhang, "Using DNS SRV to
Specify a Global File Namespace with NFS Version 4", Specify a Global File Namespace with NFS Version 4", RFC
RFC 6641, June 2012. 6641, June 2012, <http://www.rfc-editor.org/info/rfc6641>.
Appendix A. Acknowledgments [RFC7533] Lentini, J., Tewari, R., and C. Lever, Ed.,
"Administration Protocol for Federated File Systems", RFC
7533, March 2015,
<http://www.rfc-editor.org/info/rfc7533>.
Acknowledgments
Daniel Ellard contributed significant parts of this document.
The authors and editor would like to thank Craig Everhart and Manoj The authors and editor would like to thank Craig Everhart and Manoj
Naik, who were co-authors of an earlier version of this document. In Naik, who were co-authors of an earlier draft version of this
addition, we would like to thank Andy Adamson, Paul Lemahieu, Mario document. In addition, we would like to thank Andy Adamson, Paul
Wurzl, and Robert Thurlow for helping to author this document. Lemahieu, Mario Wurzl, and Robert Thurlow for helping to author this
document.
We would like to thank George Amvrosiadis, Trond Myklebust, Howard We would like to thank George Amvrosiadis, Trond Myklebust, Howard
Chu, and Nicolas Williams for their comments and review. Chu, and Nicolas Williams for their comments and review.
The editor gratefully acknowledges the IESG reviewers, whose The editor gratefully acknowledges the IESG reviewers, whose
constructive comments helped make this a much stronger document. constructive comments helped make this a much stronger document.
Finally, we would like to thank Andy Adamson, Rob Thurlow, and Tom Finally, we would like to thank Andy Adamson, Rob Thurlow, and Tom
Haynes for helping to get this document out the door. Haynes for helping to get this document out the door.
The extract.sh shell script and formatting conventions were first The extract.sh shell script and formatting conventions were first
described by the authors of the NFSv4.1 XDR specification [RFC5662]. described by the authors of the NFSv4.1 XDR specification [RFC5662].
Authors' Addresses Authors' Addresses
James Lentini James Lentini
NetApp NetApp
1601 Trapelo Rd, Suite 16 1601 Trapelo Rd, Suite 16
Waltham, MA 02451 Waltham, MA 02451
US United States
Phone: +1 781-768-5359 Phone: +1 781-768-5359
Email: jlentini@netapp.com EMail: jlentini@netapp.com
Daniel Ellard
Raytheon BBN Technologies
10 Moulton Street
Cambridge, MA 02138
US
Phone: +1 617-873-8004
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 United States
Email: tewarir@us.ibm.com EMail: tewarir@us.ibm.com
Charles Lever (editor) Charles Lever (editor)
Oracle Corporation Oracle Corporation
1015 Granger Avenue 1015 Granger Avenue
Ann Arbor, MI 48104 Ann Arbor, MI 48104
US United States
Phone: +1 248-614-5091 Phone: +1 248-614-5091
Email: chuck.lever@oracle.com EMail: chuck.lever@oracle.com
 End of changes. 235 change blocks. 
514 lines changed or deleted 548 lines changed or added

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