draft-ietf-nfsv4-federated-fs-protocol-03.txt   draft-ietf-nfsv4-federated-fs-protocol-04.txt 
NFSv4 Working Group J. Lentini NFSv4 Working Group J. Lentini
Internet-Draft C. Everhart Internet-Draft C. Everhart
Intended status: Standards Track NetApp Intended status: Standards Track NetApp
Expires: February 21, 2010 D. Ellard Expires: April 29, 2010 D. Ellard
BBN Technologies BBN Technologies
R. Tewari R. Tewari
M. Naik M. Naik
IBM Almaden IBM Almaden
August 20, 2009 October 26, 2009
NSDB Protocol for Federated Filesystems NSDB Protocol for Federated Filesystems
draft-ietf-nfsv4-federated-fs-protocol-03 draft-ietf-nfsv4-federated-fs-protocol-04
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 21, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Features and Concepts . . . . . . . . . . . . . . 4 2. Overview of Features and Concepts . . . . . . . . . . . . . . 5
2.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Fileset and Fileset Name (FSN) . . . . . . . . . . . . . . 5 2.2. Fileset . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Fileset Location (FSL) . . . . . . . . . . . . . . . . . . 6 2.3. Fileset Name (FSN) . . . . . . . . . . . . . . . . . . . . 5
2.3.1. Mutual Consistency across Fileset Locations . . . . . 7 2.4. Fileset Location (FSL) . . . . . . . . . . . . . . . . . . 6
2.3.2. Caching of Fileset Locations . . . . . . . . . . . . . 8 2.4.1. Mutual Consistency across Fileset Locations . . . . . 6
2.4. Namespace Database (NSDB) . . . . . . . . . . . . . . . . 8 2.4.2. Caching of Fileset Locations . . . . . . . . . . . . . 7
2.5. Mount Points, Junctions and Referrals . . . . . . . . . . 9 2.5. Namespace Database (NSDB) . . . . . . . . . . . . . . . . 8
2.6. Unified Namespace and the Root Fileset . . . . . . . . . . 10 2.6. Mount Points, Junctions and Referrals . . . . . . . . . . 9
2.7. Fileservers . . . . . . . . . . . . . . . . . . . . . . . 10 2.7. Unified Namespace and the Root Fileset . . . . . . . . . . 9
2.8. File-access Clients . . . . . . . . . . . . . . . . . . . 10 2.8. Fileservers . . . . . . . . . . . . . . . . . . . . . . . 10
2.9. File-access Clients . . . . . . . . . . . . . . . . . . . 10
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Creating a Fileset and its FSL(s) . . . . . . . . . . . . 11 3.1. Creating a Fileset and its FSL(s) . . . . . . . . . . . . 10
3.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 11 3.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 11
3.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 12 3.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 11
3.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 12 3.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 11
3.3. Example Use Case for Fileset Annotations . . . . . . . . . 12 3.3. Example Use Cases for Fileset Annotations . . . . . . . . 12
4. Mapping the NSDB onto LDAP . . . . . . . . . . . . . . . . . . 13 4. NSDB Configuration and Schema . . . . . . . . . . . . . . . . 13
4.1. Basic LDAP Configuration . . . . . . . . . . . . . . . . . 13 4.1. LDAP Configuration . . . . . . . . . . . . . . . . . . . . 13
4.2. LDAP Schema . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. LDAP Schema . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1. LDAP Attributes . . . . . . . . . . . . . . . . . . . 14 4.2.1. LDAP Attributes . . . . . . . . . . . . . . . . . . . 14
4.2.2. LDAP Objects . . . . . . . . . . . . . . . . . . . . . 22 4.2.2. LDAP Objects . . . . . . . . . . . . . . . . . . . . . 30
5. NSDB Operations . . . . . . . . . . . . . . . . . . . . . . . 24 5. NSDB Operations . . . . . . . . . . . . . . . . . . . . . . . 33
5.1. NSDB Operations for Administrators . . . . . . . . . . . . 25 5.1. NSDB Operations for Administrators . . . . . . . . . . . . 34
5.1.1. Create an FSN . . . . . . . . . . . . . . . . . . . . 25 5.1.1. Create an FSN . . . . . . . . . . . . . . . . . . . . 35
5.1.2. Delete an FSN . . . . . . . . . . . . . . . . . . . . 26 5.1.2. Delete an FSN . . . . . . . . . . . . . . . . . . . . 36
5.1.3. Create an FSL . . . . . . . . . . . . . . . . . . . . 27 5.1.3. Create an FSL . . . . . . . . . . . . . . . . . . . . 36
5.1.4. Delete an FSL . . . . . . . . . . . . . . . . . . . . 27 5.1.4. Delete an FSL . . . . . . . . . . . . . . . . . . . . 39
5.1.5. Update an FSL . . . . . . . . . . . . . . . . . . . . 28 5.1.5. Update an FSL . . . . . . . . . . . . . . . . . . . . 39
5.2. NSDB Operations for Fileservers . . . . . . . . . . . . . 28 5.2. NSDB Operations for Fileservers . . . . . . . . . . . . . 40
5.2.1. Lookup FSLs for an FSN . . . . . . . . . . . . . . . . 28 5.2.1. Lookup FSLs for an FSN . . . . . . . . . . . . . . . . 40
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
7.1. LDAP Descriptor Registration . . . . . . . . . . . . . . . 30 7.1. LDAP Descriptor Registration . . . . . . . . . . . . . . . 42
8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
9.1. Normative References . . . . . . . . . . . . . . . . . . . 34 9.1. Normative References . . . . . . . . . . . . . . . . . . . 48
9.2. Informational References . . . . . . . . . . . . . . . . . 35 9.2. Informational References . . . . . . . . . . . . . . . . . 49
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 36 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
A federated filesystem enables file access and namespace traversal in A federated filesystem enables file access and namespace traversal in
a uniform, secure and consistent manner across multiple independent a uniform, secure and consistent manner across multiple independent
fileservers within an enterprise or across multiple enterprises. fileservers within an enterprise or across multiple enterprises.
This document specifies a set of protocols that allow fileservers, This document specifies a set of protocols that allow fileservers,
possibly from different vendors and with different administrators, to possibly from different vendors and with different administrators, to
cooperatively form a federation containing one or more federated cooperatively form a federation containing one or more federated
skipping to change at page 4, line 33 skipping to change at page 4, line 33
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 filesystems. However, relying
on vendor-proprietary tools does not work in larger enterprises or on vendor-specific proprietary tools does not work in larger
when collaborating across enterprises because the fileservers are enterprises or when collaborating across enterprises because the
likely to be from multiple vendors or use different software fileservers are likely to be from multiple vendors or use different
versions, each with their own namespace protocols, with no common software versions, each with their own namespace protocols, with no
mechanism to manage the namespace or exchange namespace information. common mechanism to manage the namespace or exchange namespace
information.
The federated filesystem protocols in this document define how to The federated filesystem protocols in this document define how to
construct a namespace accessible by an NFSv4 [RFC3530] or NFSv4.1 construct a namespace accessible by an NFSv4 [RFC3530] or NFSv4.1
[NFSv4.1] client and have been designed to accommodate other file [NFSv4.1] client and have been designed to accommodate other file
access protocols in the future. access protocols in the future.
The requirements for federated filesystems are described in The requirements for federated filesystems are described in
[FEDFS-REQTS]. A protocol for administering a fileserver's namespace [FEDFS-REQTS]. A protocol for administering a fileserver's namespace
is described in [FEDFS-ADMIN]. In the rest of the document, the term is described in [FEDFS-ADMIN]. The mechanism for discovering the
fileserver denotes a fileserver that is part of a federation. root of an NFSv4 namespace is described in [FEDFS-DNS-SRV]. In the
rest of the document, the term fileserver denotes a fileserver that
is part of a federation.
2. Overview of Features and Concepts 2. Overview of Features and Concepts
2.1. Namespace 2.1. Namespace
The goal of a unified namespace is to make all managed data available The goal of a unified namespace is to make all managed data available
to all clients via the same path in a common filesystem-like to all clients via the same path in a common filesystem-like
namespace. This should be achieved with minimal or zero client namespace. This should be achieved with minimal or zero client
configuration. In particular, updates to the common namespace should configuration. In particular, updates to the common namespace should
not require configuration changes at the client. Filesets, which are not require configuration changes at the client. Filesets, which are
the unit of data management, are a set of files and directories. the unit of data management, are a set of files and directories.
From the perspective of the clients, the common namespace is From the perspective of the clients, the common namespace is
constructed by mounting filesets that are physically located on constructed by mounting filesets that are physically located on
skipping to change at page 5, line 24 skipping to change at page 5, line 27
different fileservers. The namespace, which is defined in terms of different fileservers. The namespace, which is defined in terms of
fileset definitions, fileset identifiers, the location of each fileset definitions, fileset identifiers, the location of each
fileset in the namespace, and the physical location of the fileset in the namespace, and the physical location of the
implementation(s) of each fileset, is stored in a set of namespace implementation(s) of each fileset, is stored in a set of namespace
repositories, each managed by an administrative entity. The repositories, each managed by an administrative entity. The
namespace schema defines the model used for populating, modifying, namespace schema defines the model used for populating, modifying,
and querying the namespace repositories. It is not required by the and querying the namespace repositories. It is not required by the
federation that the namespace be common across all fileservers. It federation that the namespace be common across all fileservers. It
should be possible to have several independently rooted namespaces. should be possible to have several independently rooted namespaces.
2.2. Fileset and Fileset Name (FSN) 2.2. Fileset
A fileset is defined to be a container of data and is the basic unit A fileset is defined to be a container of data and is the basic unit
of data management. Depending on the implementation, they may be of data management. Depending on the configuration, they may be
anything between an individual directory of an exported filesystem to anything between an individual directory of an exported filesystem to
an entire exported filesystem at a fileserver. A fileset is uniquely an entire exported filesystem at a fileserver.
represented by its fileset name (FSN). An FSN is considered unique
across the federation. An FSN contains information sufficient to
locate the namespace database (NSDB) that holds authoritative
information about it and an identifier, called the FsnUuid, that
identifies it on that NSDB. After an FSN is created, it is
associated with a fileset location (FSL) on a fileserver. A fileset
can be implemented by one or more FSLs. The attributes of an FSN
are:
NsdbName: the fully qualified domain name of an NSDB location 2.3. Fileset Name (FSN)
that contains authoritative information for this FSN.
A fileset is uniquely represented by its fileset name (FSN). An FSN
is considered unique across the federation. After an FSN is created,
it is associated with one or more fileset locations (FSLs) on a
fileserver.
The attributes of an FSN are:
NsdbName: the network location of the NSDB node that contains
authoritative information for this FSN.
NsdbContainerEntry: the location within the NSDB below which
federation objects are stored.
FsnUuid: a 128-bit UUID (universally unique identifier), FsnUuid: a 128-bit UUID (universally unique identifier),
conforming to [RFC4122], that is used to uniquely identify an conforming to [RFC4122], that is used to uniquely identify an
FSN. To minimize the probability of two UUIDs colliding, a FSN.
consistent procedure for generating UUIDs SHOULD be used
throughout the federation. Within the federation, UUIDs SHOULD
be generated using the procedure described for version 1 of the
UUID variant specified in [RFC4122]. An NSDB SHOULD ensure
that no two FSNs it stores have the same FsnUuid.
2.3. Fileset Location (FSL) 2.4. Fileset Location (FSL)
An FSL represents the location where the fileset data resides. Each An FSL describes the location where the fileset data resides. An FSL
FSL contains the host addresses of the fileserver storing the FSL and contains generic and type specific information which together
protocol specific information for accessing the FSL. Each location describe how to access the fileset. An FSL's type indicates which
has an associated type that determines the protocol(s) that may be protocol(s) may be used to access its data. An FSL's attributes can
used to access its data. Type information can be used to decide the be used by a fileserver to decide which locations it will be returned
list of locations that will be returned to the client. to a client.
Each FSL consists of: All FSLs have the following attributes:
FslUuid: a 128-bit UUID, conforming to [RFC4122], that is used to FslUuid: a 128-bit UUID, conforming to [RFC4122], that is used to
uniquely identify an FSL. To minimize the probability of two uniquely identify an FSL.
UUIDs colliding, a consistent procedure for generating UUIDs
SHOULD be used throughout the federation. Within the
federation, UUIDs SHOULD be generated using the procedure
described for version 1 of the UUID variant specified in
[RFC4122]. An NSDB SHOULD ensure that no two FSLs it stores
have the same FslUuid.
FsnUuid: the 128-bit UUID of the FSL's FSN. FsnUuid: the 128-bit UUID of the FSL's FSN.
NsdbName: the fully qualified domain name of an NSDB location NsdbName: the NSDB node that contains authoritative information
that contains authoritative information for this FSL. for this FSL.
FSL Host: the fully qualified domain name of the host fileserver NsdbContainerEntry: the location within the NSDB below which
storing the physical data federation objects are stored.
FSL TTL: the time in seconds during which the FSL may be cached FslHost: the network location of the host fileserver storing the
physical data
FslTTL: the time in seconds during which the FSL may be cached
Annotations: optional name/value pairs that can be interpreted by Annotations: optional name/value pairs that can be interpreted by
a fileserver. The semantics of this field are not defined by a 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: optional text descriptions. The semantics of this Descriptions: optional text descriptions. The semantics of this
field are not defined by this document. field are not defined by this document.
In addition, an NFS FSL contains information suitable for an NFSv4 This document defines an FSL subtype for NFS. An NFS FSL contains
fs_locations [RFC3530] or NFSv4.1 fs_locations_info attribute information suitable for use in an NFSv4 fs_locations [RFC3530] or
[NFSv4.1]: NFSv4.1 fs_locations_info attribute [NFSv4.1].
Pathname: the exported pathname at that host fileserver
Major Version: the NFS protocol major version (e.g. 4 for
NFSv4.1)
Minor Version: the NFS protocol minor version (e.g. 1 for
NFSv4.1)
Currency: the time lag of this FSL represented as the number of
time units it lags the latest version as defined by the NFSv4.1
fs_locations_server's fls_currency field. A currency value of
0 represents the latest version. Currency values are less than
or equal to zero
Info: as defined by the NFSv4.1 fl_locations_server's fls_info
field.
Flags: as defined by the NFSv4.1 fs_locations_info's fli_flags
field.
Valid For: as defined by the NFSv4.1 fs_locations_info's
fli_valid_for field.
A fileset MAY be accessible by protocols other than NFS. For each A fileset MAY be accessible by protocols other than NFS. For each
such protocol, a corresponding FSL subtype SHOULD be defined. The such protocol, a corresponding FSL subtype SHOULD be defined. The
contents and format of such FSL subtypes are not defined in this contents and format of such FSL subtypes are not defined in this
document. document.
2.3.1. Mutual Consistency across Fileset Locations 2.4.1. Mutual Consistency across Fileset Locations
All of the FSLs that have the same FSN (thereby reference the same All of the FSLs that have the same FSN (and thereby reference the
fileset) are equivalent from the point of view of client access; the same fileset) are equivalent from the point of view of client access;
different locations of a fileset represent the same data, though the different locations of a fileset represent the same data, though
potentially at different points in time. Fileset locations are potentially at different points in time. Fileset locations are
equivalent but not identical. Locations may either be read-only or equivalent but not identical. Locations may either be read-only or
read-write. Typically, multiple read-write locations are backed by a read-write. Typically, multiple read-write locations are backed by a
clustered filesystem while read-only locations are replicas created clustered filesystem while read-only locations are replicas created
by a federation-initiated or external replication. Read-only by a federation-initiated or external replication operation. Read-
locations may represent consistent point-in-time copies of a read- only locations may represent consistent point-in-time copies of a
write location. The federation protocols, however, cannot prevent read-write location. The federation protocols, however, cannot
subsequent changes to a read-only location nor guarantee point-in- prevent subsequent changes to a read-only location nor guarantee
time consistency of a read-only location if the read-write location point-in-time consistency of a read-only location if the read-write
is changing. location is changing.
Regardless of the type, all locations exist at the same mount point Regardless of the type, all locations exist at the same mount point
in the namespace and, thus, one client may be referred to one in the namespace and, thus, one client may be referred to one
location while another is directed to a different location. Since location while another is directed to a different location. Since
updates to each fileset location are not controlled by the federation updates to each fileset location are not controlled by the federation
protocol, it is the responsibility of administrators to guarantee the protocol, it is the responsibility of administrators to guarantee the
functional equivalence of the data. functional equivalence of the data.
The federation protocol does not guarantee that the different The federation protocol does not guarantee that the different
locations are mutually consistent in terms of the currency of the locations are mutually consistent in terms of the currency of the
data. It relies on the client file-access protocol (i.e., NFSv4) to data. It relies on the client file-access protocol (e.g., NFSv4) to
contain sufficient information to help the clients determine the contain sufficient information to help the clients determine the
currency of the data at each location in order to ensure that the currency of the data at each location in order to ensure that the
clients do not revert back in time when switching locations. clients do not revert back in time when switching locations.
2.3.2. Caching of Fileset Locations 2.4.2. Caching of Fileset Locations
To resolve an FSN to a set of FSL records, the fileserver queries the To resolve an FSN to a set of FSL records, the fileserver queries the
appropriate NSDB for the FSL records. A fileserver MAY cache these appropriate NSDB for the FSL records. A fileserver MAY cache these
FSL records for a limited period of time. The period of time, if FSL records for a limited period of time. The period of time, if
any, during which FSL records are cached is indicated by the FSL's any, during which FSL records MAY be cached is indicated by the FSL's
TTL field. TTL field.
The combination of FSL caching and FSL migration presents a The combination of FSL caching and FSL migration presents a
challenge. For example, suppose there are three fileservers named A, challenge. For example, suppose there are three fileservers named A,
B, and C and fileserver A contains a junction to fileset X stored on B, and C and fileserver A contains a junction to fileset X stored on
fileserver B. Now suppose that fileset X is migrated from fileserver fileserver B. Now suppose that fileset X is migrated from fileserver
B to fileserver C and the corresponding FSL information for fileset X B to fileserver C and the corresponding FSL information for fileset X
in the appropriate NSDB is updated. If fileserver A has a cached FSL in the appropriate NSDB is updated. If fileserver A has a cached FSL
for fileset X, a user traversing the junction on fileserver A will be for fileset X, a user traversing the junction on fileserver A will be
referred to fileserver B even though fileset X has migrated to referred to fileserver B even though fileset X has migrated to
fileserver C. If fileserver A was not caching FSL records, it would fileserver C. If fileserver A had not cached the FSL record, it would
have obtained the correct location of fileset X from the NSDB. have queried the NSDB and obtained the correct location of fileset X.
Administrators are advised to be aware of FSL caching when performing Administrators are advised to be aware of FSL caching when performing
a migration. When migrating a fileset, administrators SHOULD create a migration. When migrating a fileset, administrators SHOULD create
a junction at the fileset's old location referring back to the NSDB a junction at the fileset's old location referring back to the NSDB
entry for the fileset. This junction will redirect any users who entry for the fileset. This junction will redirect any users who
follow stale FSL information to the correct location. Thus, in the follow stale FSL information to the correct location. Thus, in the
above example, fileserver A would direct clients to fileserver B, but above example, fileserver A would direct clients to fileserver B, but
fileserver B would in turn direct clients to fileserver C. fileserver B would in turn direct clients to fileserver C.
Such supplemental junctions (on fileserver B in the example) would Such supplemental junctions (on fileserver B in the example) would
not be required to be in place forever. They need to stay in place not be required to be in place forever. They need to stay in place
only until cached FSL entries for the target fileset are invalidated. only until cached FSL entries for the target fileset are invalidated.
Each FSL contains a TTL field, a count in seconds of the time Each FSL contains a TTL field, a count in seconds of the time
interval which is an upper bound for the lifetime of the cached interval the FSL MAY be cached. This is an upper bound for the
information and a lower bound for the lifetime of the supplemental lifetime of the cached information and a lower bound for the lifetime
junctions. For example, suppose this field contains the value 3600 of the supplemental junctions. For example, suppose this field
seconds (one hour). In such a case, administrators MUST keep the contains the value 3600 seconds (one hour). In such a case,
supplemental junctions in place for at least one hour after the administrators MUST keep the supplemental junctions in place for at
fileset move has taken place, and FSL data MUST NOT be cached by a least one hour after the fileset move has taken place, and FSL data
referring fileserver for more than one hour without a refresh. MUST NOT be cached by a referring fileserver for more than one hour
without a refresh.
2.4. Namespace Database (NSDB) 2.5. Namespace Database (NSDB)
The NSDB service is a federation-wide service that provides The NSDB service is a federation-wide service that provides
interfaces to define, update, and query FSN information and FSN to interfaces to define, update, and query FSN information, FSL
FSL mapping information. An individual repository of namespace information, and FSN to FSL mapping information. An individual
information is called an NSDB location. Each NSDB location is repository of namespace information is called an NSDB node. Each
managed by a single administrative entity. A single admin entity can NSDB node is managed by a single administrative entity. A single
manage multiple NSDB locations. admin entity can manage multiple NSDB nodes.
The difference between the NSDB service and an NSDB location is The difference between the NSDB service and an NSDB node is analogous
analogous to that between the DNS service and a particular DNS to that between the DNS service and a particular DNS server.
server.
Each NSDB location 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 location is authoritative for the filesets with those FSNs. An NSDB node is authoritative for the filesets that
that it defines. An NSDB location can cache information from a peer it defines. An NSDB node can cache information from a peer NSDB
NSDB location. The fileserver can always contact a local NSDB node. The fileserver can always contact a local NSDB node (if it has
location (if it has been defined) or directly contact any NSDB been defined) or directly contact any NSDB node to resolve a
location to resolve a junction. Each NSDB location supports an LDAP junction. Each NSDB node supports an LDAP [RFC4510] interface and
[RFC4510] interface and can be accessed by an LDAP client. can be accessed by an LDAP client.
An NSDB MAY be replicated throughout the federation. If an NSDB is An NSDB MAY be replicated throughout the federation. If an NSDB is
replicated, the NSDB MUST exhibit loose, converging consistency as replicated, the NSDB MUST exhibit loose, converging consistency as
defined in [RFC3254]. The mechanism by which this is achieved is defined in [RFC3254]. The mechanism by which this is achieved is
outside the scope of this document. Many LDAP implementations outside the scope of this document. Many LDAP implementations
support replication. These features MAY be used to replicate the support replication. These features MAY be used to replicate the
NSDB. NSDB.
2.5. Mount Points, Junctions and Referrals 2.6. Mount Points, Junctions and Referrals
A mount point is a directory in a parent fileset where a target A mount point is a directory in a parent fileset where a target
fileset may be attached. If a client traverses the path leading from fileset may be attached. If a client traverses the path leading from
the root of the namespace to the mount point of a target fileset it the root of the namespace to the mount point of a target fileset it
should be able to access the data in that target fileset (assuming should be able to access the data in that target fileset (assuming
appropriate permissions). appropriate permissions).
The directory where a fileset is mounted is represented by a junction The directory where a fileset is mounted is represented by a junction
in the underlying filesystem. In other words, a junction can be in the underlying filesystem. In other words, a junction can be
viewed as a reference from a directory in one fileset to the root of viewed as a reference from a directory in one fileset to the root of
the target fileset. A junction can be implemented as a special the target fileset. A junction can be implemented as a special
marker on a directory that is interpreted by the fileserver as a marker on a directory that is interpreted by the fileserver as a
mount point, or by some other mechanism in the underlying filesystem. mount point, or by some other mechanism in the underlying filesystem.
What data is used by the underlying filesystem to represent the What data is used by the underlying filesystem to represent the
junction is not defined by this protocol. The essential property is junction is not defined by this protocol. The essential property is
that the server must be able to find, given the junction, the FSN for that the server must be able to find, given the junction, the FSN for
the target fileset. The mechanism by which the server maps a the target fileset. The mechanism by which the server maps a
junction to an FSN is outside the scope of this document. The FSN junction to an FSN is outside the scope of this document. The FSN
(as described earlier) contains both the the authoritative NSDB (as described earlier) contains the authoritative NSDB node, the
location and the FsnUuid (a UUID for the fileset). optional NSDB search base if one is defined, and the FsnUuid (a UUID
for the fileset).
When a client traversal reaches a junction, the client is referred to When a client traversal reaches a junction, the client is referred to
a list of FSLs associated with the FSN that was the target of the a list of FSLs associated with the FSN targeted by the junction. The
junction. The client can then redirect its connection to one of the client can then redirect its connection to one of the FSLs. This act
FSLs. This act is called a referral. For NFSv4 and NFSv4.1 clients, is called a referral. For NFSv4 and NFSv4.1 clients, the FSL
the FSL information is returned in the fs_locations and information is returned in the fs_locations and fs_locations_info
fs_locations_info attributes respectively. attributes respectively.
The federation protocols do not limit where and how many times a The federation protocols do not limit where and how many times a
fileset is mounted in the namespace. Filesets can be nested; a fileset is mounted in the namespace. Filesets can be nested; a
fileset can be mounted under another fileset. fileset can be mounted under another fileset.
2.6. Unified Namespace and the Root Fileset 2.7. Unified Namespace and the Root Fileset
The root fileset, when defined, is the top-level fileset of the The root fileset, when defined, is the top-level fileset of the
federation-wide namespace. The root of the unified namespace is the federation-wide namespace. The root of the unified namespace is the
top level directory of this fileset. A set of designated fileservers top level directory of this fileset. A set of designated fileservers
in the federation can export the root fileset to render the in the federation can export the root fileset to render the
federation-wide unified namespace. When a client mounts the root federation-wide unified namespace. When a client mounts the root
fileset from any of these designated fileservers it can view a common fileset from any of these designated fileservers it can view a common
federation-wide namespace. The properties and schema definition of federation-wide namespace. The properties and schema definition of
the root fileset and the protocol details that describe how to the root fileset and the protocol details that describe how to
configure and replicate the root fileset are not defined in this configure and replicate the root fileset are not defined in this
document. document.
2.7. Fileservers 2.8. Fileservers
Fileservers are servers that store the physical fileset data or refer Fileservers are servers that store the physical fileset data or refer
the client to other fileservers. A fileserver can be implemented in the client to other fileservers. A fileserver can be implemented in
a number of different ways, including a single system, a cluster of a number of different ways, including a single system, a cluster of
systems, or some other configuration. A fileserver access to a systems, or some other configuration. A fileserver provides access
federated filesystem via NFSv4, NFSv4.1, or some other protocol. to a federated filesystem via NFSv4, NFSv4.1, or some other protocol.
2.8. File-access Clients 2.9. File-access Clients
File access clients are standard off-the-shelf NAS clients that File access clients are standard off-the-shelf network attached
access file data using the NFSv4 protocol, the NFSv4.1 protocol, or storage (NAS) clients that access file data using the NFSv4 protocol,
some other protocol. the NFSv4.1 protocol, or some other protocol.
3. Examples 3. Examples
In this section we provide examples and discussion of the basic In this section we provide examples and discussion of the basic
operations facilitated by the federated filesystem protocol: creating operations facilitated by the federated filesystem protocol: creating
a fileset, adding a replica of a fileset, resolving a junction, and a fileset, adding a replica of a fileset, resolving a junction, and
creating a junction. creating a junction.
3.1. Creating a Fileset and its FSL(s) 3.1. Creating a Fileset and its FSL(s)
skipping to change at page 11, line 19 skipping to change at page 10, line 40
data management in the federation. This abstraction is implemented data management in the federation. This abstraction is implemented
by an actual directory tree whose root location is specified by a by an actual directory tree whose root location is specified by a
fileset location (FSL). fileset location (FSL).
In this section, we describe the basic requirements for starting with In this section, we describe the basic requirements for starting with
a directory tree and creating a fileset that can be used in the a directory tree and creating a fileset that can be used in the
federation protocols. Note that we do not assume that the process of federation protocols. Note that we do not assume that the process of
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(s) of the implementation of the fileset as FSL(s). 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
1. Choose the NSDB node that will keep track of the FSL(s) and 1. Choose the NSDB node that will keep track of the FSL(s) and
related information for the fileset. related information for the fileset.
2. Request that the NSDB node register a new FSN for the fileset. 2. 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
that FSN to work again. that FSN to work again.
At this point, the FSN exists, but its fileset locations are At this point, the FSN exists, but its fileset locations are
unspecified. unspecified.
3. Send the FSN, the hostname, the export path, the type, the 3. For the FSN created above, create an FSL with the appropriate
currency, info, and annotations for the fileset to the NSDB node. information in the NSDB node.
The NSDB node records this info and creates the initial FSL for
the fileset.
3.1.2. Adding a Replica of a Fileset 3.1.2. Adding a Replica of a Fileset
Adding a replica is straightforward: the NSDB node and the FSN are Adding a replica is straightforward: the NSDB node and the FSN are
already known. The only remaining step is to add another FSL. already known. The only remaining step is to add another FSL.
Note that the federation protocols do not include methods for Note that the federation protocols only provide the mechanisms to
creating or managing replicas: this is assumed to be a platform- register and unregister replicas of a fileset. Fileserver-to-
dependent operation (at least at this time). The only interface fileserver replication protocols are not defined.
required is the ability to register or remove the registration of
replicas for a fileset.
3.2. Junction Resolution 3.2. Junction Resolution
A fileset may contain references to other filesets. These references A fileset may contain references to other filesets. These references
are represented by junctions. If a client requests access to a are represented by junctions. If a client requests access to a
fileset object that is a junction, the server resolves the junction fileset object that is a junction, the fileserver resolves the
to discover the FSL(s) that implements the referenced fileset. junction to discover one or more FSLs that implement the referenced
fileset.
There are many possible variations to this procedure, depending on There are many possible variations to this procedure, depending on
how the junctions are represented and how the information necessary how the junctions are represented by the fileserver and how the
to perform resolution is represented by the server. fileserver performs junction resolution.
Step 4 is the only step that interacts directly with the federation Step 4 is the only step that interacts directly with the federation
protocols. The rest of the steps may use platform-specific protocols. The rest of the steps may use platform-specific
interfaces. interfaces.
1. The server determines that the object being accessed is a 1. The fileserver determines that the object being accessed is a
junction. junction.
2. The server does a local lookup to find the FSN of the target 2. The fileserver does a local lookup to find the FSN of the target
fileset. fileset.
3. Using the FSN, the server finds the NSDB node responsible for the 3. Using the FSN, the fileserver finds the NSDB node responsible for
target object. the target FSN.
4. The server contacts that NSDB node and asks for the set of FSLs 4. The fileserver contacts that NSDB node and asks for the set of
that implement the target FSN. The NSDB node responds with a set FSLs that implement the target FSN. The NSDB node responds with
of FSLs. a (possibly empty) set of FSLs.
3.3. Example Use Case for Fileset Annotations 3.3. Example Use Cases for Fileset Annotations
The fileset annotations can be used to define relationships between Fileset annotations MAY be used to convey additional attributes of a
filesets that can be used by an auxiliary replication protocol. fileset
Consider the scenario where a fileset is created and mounted at some
point in the namespace. A snapshot of the read-write FSL of that For example, fileset annotations can be used to define relationships
fileset is taken periodically at different frequencies say a daily between filesets that can be used by an auxiliary replication
snapshot or a weekly snapshot. The different snapshots are mounted protocol. Consider the scenario where a fileset is created and
at different locations in the namespace. The daily snapshots are mounted at some point in the namespace. A snapshot of the read-write
considered as a different fileset from the weekly ones but both are FSL of that fileset is taken periodically at different frequencies
related to the source fileset. For this we can define an annotation say a daily snapshot or a weekly snapshot. The different snapshots
labeling the filesets as source and replica. The replication are mounted at different locations in the namespace. The daily
protocol can use this information to copy data from one or more FSLs snapshots are considered as a different fileset from the weekly ones
of the source fileset to all the FSLs of the replica fileset. The but both are related to the source fileset. For this we can define
replica filesets are read-only while the source fileset is read- an annotation labeling the filesets as source and replica. The
write. replication protocol can use this information to copy data from one
or more FSLs of the source fileset to all the FSLs of the replica
fileset. The replica filesets are read-only while the source fileset
is read-write.
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.
4. Mapping the NSDB onto LDAP Another potential use for annotations is recording references to an
FSN. A single annotation containing the number of references could
be defined or multiple annotations, one per reference, could be used
to store detailed information on the location of each reference. As
with the replication annotation described above, the maintenance of
reference information would not be controlled by the federation
protocol. The information would mostly likely be non-authoritative
because the the ability to create a junction does not require the
authority to update the FSN record. In any event, such annotations
could be useful to administrators for determining if an FSN is
referenced by a junction.
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, the new object types, and
specifies how the distinguished name (DN) of each object instance specifies how the distinguished name (DN) of each object instance
MUST be constructed. MUST be constructed.
4.1. Basic LDAP Configuration 4.1. LDAP Configuration
The base name (or suffix) of the NSDB directory information tree An NSDB's LDAP Directory Information Tree (DIT) MUST contain an LDAP
(DIT) is "o=fedfs". entry that is superior to all federation entries (e.g. FSNs and
FSLs). This entry is termed the NSDB Container Entry (NCE).
The DN of the privileged LDAP user is, by convention, The NSDB SHOULD be configured with one or more privileged LDAP users.
"cn=admin,o=fedfs". This user is able to modify the contents of the These users are able to modify the contents of the LDAP database. An
LDAP database. It is permitted to use a different DN (or add administrator that performs the operations described in Section 5.1
additional privileged users) but if a different DN is used then every SHOULD authenticate using the DN of a privileged LDAP user.
admin entity that needs to modify the contents of the database or
view privileged information must be made aware of the new DN.
It MUST be possible for the anonymous (unauthenticated) user to It MUST be possible for an unprivileged (unauthenticated) user to
perform LDAP queries that access the NSDB data. perform LDAP queries that access the NSDB data. A fileserver
performs the operations described in Section 5.2 as an unprivileged
user.
All implementations SHOULD use the same schema, or, at minimum, a All implementations SHOULD use the same schema, or, at minimum, a
schema that includes all of the objects, with each of the attributes, schema that includes all of the objects, with each of the attributes,
named in the following sections. named in the following sections.
Given the above configuration guidelines, an NSDB SHOULD be Given the above configuration guidelines, an NSDB SHOULD be
constructed using a dedicated LDAP directory. Separate LDAP constructed using a dedicated LDAP directory. Separate LDAP
directories may be used for other purposes, such as storing user directories are RECOMMENDED for other purposes, such as storing user
account information. By using an LDAP directory dedicated to storing account information. By using an LDAP directory dedicated to storing
NSDB records, there is no need to disturb the configuration of any NSDB records, there is no need to disturb the configuration of any
other LDAP directories that store information unrelated to an NSDB. other LDAP directories that store information unrelated to an NSDB.
4.2. LDAP Schema 4.2. LDAP Schema
The schema definitions provided in this document use the LDAP schema The schema definitions provided in this document use the LDAP schema
syntax defined in [RFC4512]. The definitions are formatted to allow syntax defined in [RFC4512]. The definitions are formatted to allow
the reader to easily extract them from the document. The reader can the reader to easily extract them from the document. The reader can
use the following shell script to extract the definitions: use the following shell script to extract the definitions:
skipping to change at page 14, line 38 skipping to change at page 14, line 27
sh extract.sh < spec.txt > fedfs.schema sh extract.sh < spec.txt > fedfs.schema
<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 "///".
4.2.1. LDAP Attributes 4.2.1. LDAP Attributes
This section describes the required attributes of the NSDB LDAP This section describes the required attributes of the NSDB LDAP
schema. schema. The following definitions are used below:
o The "name" attribute described in [RFC4519].
o The DN syntax (1.3.6.1.4.1.1466.115.121.1.12) described in
[RFC4517].
o The "distinguishedNameMatch" rule described in [RFC4517].
o The Integer syntax (1.3.6.1.4.1.1466.115.121.1.27) described in
[RFC4517].
o The "integerMatch" rule are described in [RFC4517].
o The Octet String syntax (1.3.6.1.4.1.1466.115.121.1.40) 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
[RFC4517].
o The "booleanMatch" rule described in [RFC4517].
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 filesystem protocols.
This SHOULD be defined in terms of the text representation of the To minimize the probability of two UUIDs colliding, a consistent
standard UUID (as defined in [RFC4122]). procedure for generating UUIDs SHOULD be used throughout a
federation. Within a federation, UUIDs SHOULD be generated using the
procedure described for version 1 of the UUID variant specified in
[RFC4122].
The UUID's text representation (as defined in [RFC4122]) SHOULD be
encoded as a UTF-8 string.
It MAY also be useful, for purposes of debugging or annotation, to It MAY also be useful, for purposes of debugging or annotation, to
permit a fedfsUuid to include members of a more general class of permit a fedfsUuid to include members of a more general class of
strings. strings.
A fedfsUuid is a single-valued LDAP attribute. It is formally A fedfsUuid is a single-valued LDAP attribute.
defined as follows:
<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'
/// SUP name /// SUP name
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS>
4.2.1.2. fedfsNetAddr 4.2.1.2. fedfsNetAddr
A fedfsNetAddr is the locative name of a network service. It MUST be A fedfsNetAddr is the locative name of a network service. It MUST be
a UTF-8 string and represent a network location in either IPv4, IPv6, a UTF-8 string and represent a network location in either IPv4, IPv6,
or DNS host name notation. The format is the same as that specified or DNS host name notation. The format is the same as that specified
for an fs_location4's server array elements in section 11.9 of for an fs_location4's server array elements in section 11.9 of
[NFSv4.1]. [NFSv4.1].
This attribute is single-valued. It is formally defined as follows: This attribute is single-valued.
<CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.2 NAME 'fedfsNetAddr' /// 1.3.6.1.4.1.31103.1.2 NAME 'fedfsNetAddr'
/// DESC 'The network name of a host or service' /// DESC 'The network name of a host or service'
/// SUP name /// SUP name
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS>
4.2.1.3. fedfsFsnUuid 4.2.1.3. fedfsFsnUuid
A fedfsFsnUuid represents the fedfsFsnUuid component of an FSN. A fedfsFsnUuid represents the UUID component of an FSN. An NSDB
SHOULD ensure that no two FSNs it stores have the same fedfsFsnUuid.
The fedfsFsnUuid is a subclass of fedfsUuid. The fedfsFsnUuid is a subclass of fedfsUuid, with the same encoding
rules.
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.3 NAME 'fedfsFsnUuid' /// 1.3.6.1.4.1.31103.1.3 NAME 'fedfsFsnUuid'
/// DESC 'The FSN UUID component of an FSN' /// DESC 'The FSN UUID component of an FSN'
/// SUP fedfsUuid /// SUP fedfsUuid
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS>
4.2.1.4. fedfsNsdbName 4.2.1.4. fedfsNsdbName
An fedfsNsdbName is the NSDB component of an FSN. A fedfsNsdbName is the NSDB component of an FSN.
The fedfsNsdbName attribute is a subclass of fedfsNetAddr. The fedfsNsdbName attribute is a subclass of fedfsNetAddr, with the
same encoding rules.
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.4 NAME 'fedfsNsdbName' /// 1.3.6.1.4.1.31103.1.4 NAME 'fedfsNsdbName'
/// DESC 'The NSDB location component of an FSN' /// DESC 'The NSDB node component of an FSN'
/// SUP fedfsNetAddr /// SUP fedfsNetAddr
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
4.2.1.5. fedfsFslUuid <CODE ENDS>
Each FSL must have a UUID associated with it, which serves as part of 4.2.1.5. fedfsNsdbContainerEntry
its DN.
The fedfsFslUuid attribute is a subclass of fedfsUuid. A fedfsNsdbContainerEntry stores the DN of the NCE. The DN MUST be
encoded using the <distinguishedName> rule defined in [RFC4514]. A
DN of up to 128 octets MUST be supported. A DN greater than 128
octets MAY be supported.
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.5 NAME 'fedfsFslUuid' /// 1.3.6.1.4.1.31103.1.5 NAME 'fedfsNsdbContainerEntry'
/// DESC 'The NSDB search base'
/// EQUALITY distinguishedNameMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
/// SINGLE-VALUE
/// )
///
<CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.12 is the DN syntax [RFC4517].
4.2.1.6. fedfsFslUuid
A fedfsFslUuid represents the UUID of an FSL. An NSDB SHOULD ensure
that no two FSLs it stores have the same fedfsFslUuid.
The fedfsFslUuid attribute is a subclass of fedfsUuid, with the same
encoding rules.
This attribute is single-valued.
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.6 NAME 'fedfsFslUuid'
/// DESC 'UUID of an FSL' /// DESC 'UUID of an FSL'
/// SUP fedfsUuid /// SUP fedfsUuid
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
4.2.1.6. fedfsFslHost <CODE ENDS>
An fedfsFslHost is the hostname/port component of an FSL. 4.2.1.7. fedfsFslHost
The fedfsFslHost attribute is a subclass of fedfsNetAddr. A fedfsFslHost is the host component of an FSL.
The fedfsFslHost attribute is a subclass of fedfsNetAddr, with the
same encoding rules.
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.6 NAME 'fedfsFslHost' /// 1.3.6.1.4.1.31103.1.7 NAME 'fedfsFslHost'
/// DESC 'Service location for a fileserver' /// DESC 'Service location for a fileserver'
/// SUP fedfsNetAddr /// SUP fedfsNetAddr
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
4.2.1.7. fedfsFslTTL <CODE ENDS>
An fedfsFslTTL is the amount of time in seconds an FSL SHOULD be 4.2.1.8. fedfsFslTTL
cached by a fileserver. The numeric fedfsFslTTL value should be
converted to a string and encoded as a UTF-8 string. A fedfsFslTTL is the amount of time in seconds an FSL SHOULD be
cached by a fileserver. A fedfsFslTTL MUST be encoded as an Integer
syntax value [RFC4517].
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.7 NAME 'fedfsFslTTL' /// 1.3.6.1.4.1.31103.1.8 NAME 'fedfsFslTTL'
/// DESC 'Time to live of an FSL' /// DESC 'Time to live of an FSL'
/// SUP name /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
4.2.1.8. fedfsNfsPath <CODE ENDS>
The path component of an FSL encoded as a UTF-8 string. OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.9. fedfsAnnotation
A fedfsAnnotation contains an object annotation.
This attribute is multi-valued; an object type that permits
annotations may have any number of annotations per instance.
A fedfsAnnotation attribute MUST be an UTF-8 string formatted as
follows:
"KEY" = "VAL"
White space, defined as space, form-feed ('\f'), newline ('\n'),
carriage return ('\r'), horizontal tab ('\t'), and vertical tab
('\v') characters, is ignored.
KEY and VAL MAY may contain any UTF-8 characters. The following
escape sequences are allowed:
+-----------------+-------------+
| escape sequence | replacement |
+-----------------+-------------+
| \\ | \ |
| \" | " |
+-----------------+-------------+
A fedfsAnnotation attribute that does not adhere to this format
SHOULD be ignored.
The following are examples of valid fedfsAnnotation attributes:
"key1" = "foo"
"another key" = "x=3"
"key-2" = "A string with \" and \\ characters."
which correspond to the following key/value pairs:
+-------------+-----------------------------------+
| key | value |
+-------------+-----------------------------------+
| key1 | foo |
| another key | x=3 |
| key-2 | A string with " and \ characters. |
+-------------+-----------------------------------+
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.9 NAME 'fedfsAnnotation'
/// DESC 'Annotation of an object'
/// SUP name
/// )
///
<CODE ENDS>
4.2.1.10. fedfsDescr
A fedfsDescr stores an object description. The description MUST be
encoded as a UTF-8 string.
This attribute is multi-valued which permits any number of
descriptions per entry.
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.10 NAME 'fedfsDescr'
/// DESC 'Description of an object'
/// SUP name
/// )
///
<CODE ENDS>
4.2.1.11. fedfsNfsPath
A fedfsNfsPath is the path component of an FSL. The path MUST be the
XDR encoded NFS pathname as defined by the fs_location's rootpath
[RFC3530] and the fs_locations_item's fli_rootpath [NFSv4.1]. A
pathname is an XDR encoded variable length array of variable length
opaque data.
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.8 NAME 'fedfsNfsPath' /// 1.3.6.1.4.1.31103.1.100 NAME 'fedfsNfsPath'
/// DESC 'Server-local path to a fileset' /// DESC 'Server-local path to a fileset'
/// SUP name /// EQUALITY octetStringMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
4.2.1.9. fedfsNfsMajorVer <CODE ENDS>
The NFS major version of the associated NFS FSL. The numeric OID 1.3.6.1.4.1.1466.115.121.1.40 is the Octet String syntax
fedfsNfsMajorVer value should be converted to a string and encoded as [RFC4517].
a UTF-8 string.
4.2.1.12. fedfsNfsMajorVer
A fedfsNfsMajorVer contains the NFS major version of the associated
NFS FSL. A fedfsNfsMajorVer MUST be encoded as an Integer syntax
value [RFC4517].
For example if the FSL was exported via NFS 4.1, the contents of this For example if the FSL was exported via NFS 4.1, the contents of this
attribute would be the value 4. attribute would be the value 4.
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.9 NAME 'fedfsNfsMajorVer' /// 1.3.6.1.4.1.31103.1.101 NAME 'fedfsNfsMajorVer'
/// DESC 'NFS major version' /// DESC 'NFS major version'
/// SUP name /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
4.2.1.10. fedfsNfsMinorVer <CODE ENDS>
The NFS minor version of the associated NFS FSL. The numeric OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
fedfsNfsMinorVer value should be converted to a string and encoded as
a UTF-8 string. 4.2.1.13. fedfsNfsMinorVer
A fedfsNfsMinorVer contain the NFS minor version of the associated
NFS FSL. A fedfsNfsMinorVer MUST be encoded as an Integer syntax
value [RFC4517].
For example if the FSL was exported via NFS 4.1, the contents of this For example if the FSL was exported via NFS 4.1, the contents of this
attribute would be the value 1. attribute would be the value 1.
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.10 NAME 'fedfsNfsMinorVer' /// 1.3.6.1.4.1.31103.1.102 NAME 'fedfsNfsMinorVer'
/// DESC 'NFS minor version' /// DESC 'NFS minor version'
/// SUP name /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
4.2.1.11. fedfsNfsCurrency <CODE ENDS>
The currency of an FSL. The signed 32-bit numeric value should be OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
converted to a string encoded as a UTF-8 string.
This attribute is used to populate the NFSv4.1 fs_locations_server's 4.2.1.14. fedfsNfsCurrency
currency field.
A fedfsNfsCurrency stores the NFSv4.1 fs_locations_server's
fls_currency value [NFSv4.1]. A fedfsNfsCurrency MUST be encoded as
an Integer syntax value [RFC4517] in the range [-2147483648,
2147483647].
This attribute is single-valued. This attribute is single-valued.
<CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.11 NAME 'fedfsNfsCurrency' /// 1.3.6.1.4.1.31103.1.103 NAME 'fedfsNfsCurrency'
/// DESC 'up-to-date measure of the data' /// DESC 'up-to-date measure of the data'
/// SUP name /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
4.2.1.12. fedfsNfsInfo <CODE ENDS>
Information about the FSL. The variable sized array of octets is OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
stored directly in this attribute.
This attribute is used to populate the NFSv4.1 fs_locations_server's 4.2.1.15. fedfsNfsGenFlagWritable
info field.
This attribute is single-valued. A fedfsNfsGenFlagWritable stores the value of an FSL's NFSv4.1
FSLI4GF_WRITABLE bit [NFSv4.1]. A value of "TRUE" indicates the bit
is true. A value of "FALSE" indicates the bit is false.
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.104 NAME 'fedfsNfsGenFlagWritable'
/// DESC 'Indicates if the filesystem is writable'
/// EQUALITY booleanMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
/// SINGLE-VALUE
/// )
///
<CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].
4.2.1.16. fedfsNfsGenFlagGoing
A fedfsNfsGenFlagGoing stores the value of an FSL's NFSv4.1
FSLI4GF_GOING bit [NFSv4.1]. A value of "TRUE" indicates the bit is
true. A value of "FALSE" indicates the bit is false.
<CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.12 NAME 'fedfsNfsInfo' /// 1.3.6.1.4.1.31103.1.105 NAME 'fedfsNfsGenFlagGoing'
/// DESC 'Information about the FSL' /// DESC 'Indicates if the filesystem is going'
/// EQUALITY octetStringMatch /// EQUALITY booleanMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax <CODE ENDS>
[RFC4517].
4.2.1.13. fedfsNfsFlags OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].
An NFS FSL's flags. The unsigned 32-bit numeric value should be 4.2.1.17. fedfsNfsGenFlagSplit
converted to a string encoded as a UTF-8 string.
This attribute is used to populate the NFSv4.1 fs_locations_info's A fedfsNfsGenFlagSplit stores the value of an FSL's NFSv4.1
fli_flags field. FSLI4GF_SPLIT bit [NFSv4.1]. A value of "TRUE" indicates the bit is
true. A value of "FALSE" indicates the bit is false.
This attribute is single-valued. <CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.13 NAME 'fedfsNfsFlags' /// 1.3.6.1.4.1.31103.1.106 NAME 'fedfsNfsGenFlagSplit'
/// DESC 'Flags' /// DESC 'Indicates if there are multiple filesystems'
/// SUP name /// EQUALITY booleanMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
4.2.1.14. fedfsNfsValidFor <CODE ENDS>
An NFS FSL's "valid for" flag. The signed 32-bit numeric value OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].
should be converted to a string encoded as a UTF-8 string.
This attribute is used to populate the NFSv4.1 fs_locations_info's 4.2.1.18. fedfsNfsTransFlagRdma
fli_valid_for field.
This attribute is single-valued. A fedfsNfsTransFlagRdma stores the value of an FSL's NFSv4.1
FSLI4TF_RDMA bit [NFSv4.1]. A value of "TRUE" indicates the bit is
true. A value of "FALSE" indicates the bit is false.
<CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.14 NAME 'fedfsNfsValidFor' /// 1.3.6.1.4.1.31103.1.107 NAME 'fedfsNfsTransFlagRdma'
/// DESC 'Valid for time' /// DESC 'Indicates if the transport supports RDMA'
/// SUP name /// EQUALITY booleanMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
/// SINGLE-VALUE /// SINGLE-VALUE
/// ) /// )
/// ///
4.2.1.15. fedfsAnnotation <CODE ENDS>
An annotation of an object. OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].
This attribute is multi-valued; an object type that permits 4.2.1.19. fedfsNfsClassSimul
annotations may have any number of annotations per instance.
A fedfsNfsClassSimul contains the FSL's NFSv4.1 FSLI4BX_CLSIMUL
[NFSv4.1] value. A fedfsNfsClassSimul MUST be encoded as an Integer
syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.15 NAME 'fedfsAnnotation' /// 1.3.6.1.4.1.31103.1.108 NAME 'fedfsNfsClassSimul'
/// DESC 'Annotation of an object' /// DESC 'The simultaneous-use class of the filesystem'
/// SUP name /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE
/// ) /// )
/// ///
A fedfsAnnotation attribute MUST be an UTF-8 string formatted as <CODE ENDS>
follows:
"KEY" = "VAL" OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
White space, defined as space, form-feed ('\f'), newline ('\n'),
carriage return ('\r'), horizontal tab ('\t'), and vertical tab
('\v') characters, is ignored.
KEY and VAL MAY may contain any UTF-8 characters. The following 4.2.1.20. fedfsNfsClassHandle
escape sequences are allowed:
+-----------------+-------------+ A fedfsNfsClassHandle contains the FSL's NFSv4.1 FSLI4BX_CLHANDLE
| escape sequence | replacement | [NFSv4.1] value. A fedfsNfsClassHandle MUST be encoded as an Integer
+-----------------+-------------+ syntax value [RFC4517] in the range [0, 255].
| \\ | \ |
| \" | " |
+-----------------+-------------+
A fedfsAnnotation attribute that does not adhere to this format <CODE BEGINS>
SHOULD be ignored.
The following are examples of valid fedfsAnnotation attributes: ///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.109 NAME 'fedfsNfsClassHandle'
/// DESC 'The handle class of the filesystem'
/// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE
/// )
///
"key1" = "foo" <CODE ENDS>
"another key" = "x=3"
"key-2" = "A string with \" and \\ characters."
which correspond to the following key/value pairs: OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
+-------------+-----------------------------------+ 4.2.1.21. fedfsNfsClassFileid
| key | value |
+-------------+-----------------------------------+
| key1 | foo |
| another key | x=3 |
| key-2 | A string with " and \ characters. |
+-------------+-----------------------------------+
4.2.1.16. fedfsDescr A fedfsNfsClassFileid contains the FSL's NFSv4.1 FSLI4BX_CLFILEID
[NFSv4.1] value. A fedfsNfsClassFileid MUST be encoded as an Integer
syntax value [RFC4517] in the range [0, 255].
This attribute is used to store an object's description encoded as a <CODE BEGINS>
UTF-8 string. ///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.110 NAME 'fedfsNfsClassFileid'
/// DESC 'The fileid class of the filesystem'
/// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE
/// )
///
This attribute is multi-valued which permits any number of <CODE ENDS>
descriptions per entry.
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.22. fedfsNfsClassWritever
A fedfsNfsClassWritever contains the FSL's NFSv4.1 FSLI4BX_CLWRITEVER
[NFSv4.1] value. A fedfsNfsClassWritever MUST be encoded as an
Integer syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS>
/// ///
/// attributetype ( /// attributetype (
/// 1.3.6.1.4.1.31103.1.16 NAME 'fedfsDescr' /// 1.3.6.1.4.1.31103.1.111 NAME 'fedfsNfsClassWritever'
/// DESC 'Description of an object' /// DESC 'The write-verifier class of the filesystem'
/// SUP name /// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE
/// )
///
<CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.23. fedfsNfsClassChange
A fedfsNfsClassChange contains the FSL's NFSv4.1 FSLI4BX_CLCHANGE
[NFSv4.1] value. A fedfsNfsClassChange MUST be encoded as an Integer
syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.112 NAME 'fedfsNfsClassChange'
/// DESC 'The change class of the filesystem'
/// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE
/// )
///
<CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.24. fedfsNfsClassReaddir
A fedfsNfsClassReaddir contains the FSL's NFSv4.1 FSLI4BX_CLREADDIR
[NFSv4.1] value. A fedfsNfsClassReaddir MUST be encoded as an
Integer syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.113 NAME 'fedfsNfsClassReaddir'
/// DESC 'The readdir class of the filesystem'
/// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE
/// )
///
<CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.25. fedfsNfsReadRank
A fedfsNfsReadRank contains the FSL's NFSv4.1 FSLI4BX_READRANK
[NFSv4.1] value. A fedfsNfsReadRank MUST be encoded as an Integer
syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.114 NAME 'fedfsNfsReadRank'
/// DESC 'The read rank of the filesystem'
/// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE
/// )
///
<CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.26. fedfsNfsReadOrder
A fedfsNfsReadOrder contains the FSL's NFSv4.1 FSLI4BX_READORDER
[NFSv4.1] value. A fedfsNfsReadOrder MUST be encoded as an Integer
syntax value [RFC4517] in the range [0, 255].
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.115 NAME 'fedfsNfsReadOrder'
/// DESC 'The read order of the filesystem'
/// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE
/// )
///
<CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.27. fedfsNfsWriteRank
A fedfsNfsWriteRank contains the FSL's FSLI4BX_WRITERANK [NFSv4.1]
value. A fedfsNfsWriteRank MUST be encoded as an Integer syntax
value [RFC4517] in the range [0, 255].
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.116 NAME 'fedfsNfsWriteRank'
/// DESC 'The write rank of the filesystem'
/// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE
/// )
///
<CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.28. fedfsNfsWriteOrder
A fedfsNfsWriteOrder contains the FSL's FSLI4BX_WRITEORDER [NFSv4.1]
value. A fedfsNfsWriteOrder MUST be encoded as an Integer syntax
value [RFC4517] in the range [0, 255].
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.117 NAME 'fedfsNfsWriteOrder'
/// DESC 'The write order of the filesystem'
/// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE
/// )
///
<CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
4.2.1.29. fedfsNfsVarSub
A fedfsNfsVarSub stores the value of an FSL's NFSv4.1 FSLI4F_VAR_SUB
bit [NFSv4.1]. A value of "TRUE" indicates the bit is true. A value
of "FALSE" indicates the bit is false.
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.118 NAME 'fedfsNfsVarSub'
/// DESC 'Indicates if variable substitution is present'
/// EQUALITY booleanMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
/// SINGLE-VALUE
/// ) /// )
/// ///
<CODE ENDS>
OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517].
4.2.1.30. fedfsNfsValidFor
A fedfsNfsValidFor stores an FSL's NFSv4.1 fs_locations_info
fli_valid_for value [NFSv4.1]. A fedfsNfsValidFor MUST be encoded as
an Integer syntax value [RFC4517] in the range [-2147483648,
2147483647].
An FSL's fedfsFslTTL value and fedfsNfsValidFor value MAY be
different.
This attribute is single-valued.
<CODE BEGINS>
///
/// attributetype (
/// 1.3.6.1.4.1.31103.1.19 NAME 'fedfsNfsValidFor'
/// DESC 'Valid for time'
/// EQUALITY integerMatch
/// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
/// SINGLE-VALUE
/// )
///
OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517].
<CODE ENDS>
4.2.2. LDAP Objects 4.2.2. LDAP Objects
4.2.2.1. fedfsFsn 4.2.2.1. fedfsFsn
A fedfsFsn represents an FSN. A fedfsFsn represents an FSN.
The required attributes of a fedfsFsn are an fedfsNsdbName and A fedfsFsn's fedfsNsdbName, fedfsNsdbContainerEntry, and fedfsFsnUuid
fedfsFsnUuid. attributes are REQUIRED.
A fedfsFsn's fedfsAnnotation and fedfsDescr attributes are OPTIONAL. A fedfsFsn's fedfsAnnotation and fedfsDescr attributes are OPTIONAL.
The DN of an FSN is REQUIRED to take the following form: The DN of an FSN is REQUIRED to take the following form:
"fedfsFsnUuid=FSNUUID,o=fedfs", where FSNUUID is the UUID of the FSN. "fedfsFsnUuid=$FSNUUID,$NCE", where $FSNUUID is the UUID of the FSN
Since LDAP requires a DN to be unique, this ensures that each FSN and $NCE is the DN of the NCE ("o=fedfs" by default). Since LDAP
entry has a unique UUID value within the LDAP directory. requires a DN to be unique, this ensures that each FSN entry has a
unique UUID value within the LDAP directory.
A fedfsFsn MAY also have additional attributes, but these attributes A fedfsFsn MAY also have additional attributes, but these attributes
MUST NOT be referenced by any part of this document. MUST NOT be referenced by any part of this document.
<CODE BEGINS>
/// ///
/// objectclass ( /// objectclass (
/// 1.3.6.1.4.1.31103.1.1001 NAME 'fedfsFsn' /// 1.3.6.1.4.1.31103.1.1001 NAME 'fedfsFsn'
/// DESC 'Represents a fileset' /// DESC 'Represents a fileset'
/// SUP top STRUCTURAL /// SUP top STRUCTURAL
/// MUST ( /// MUST (
/// fedfsFsnUuid /// fedfsFsnUuid
/// $ fedfsNsdbName /// $ fedfsNsdbName
/// $ fedfsNsdbContainerEntry
/// ) /// )
/// MAY ( /// MAY (
/// fedfsAnnotation /// fedfsAnnotation
/// $ fedfsDescr /// $ fedfsDescr
/// )) /// ))
/// ///
<CODE ENDS>
4.2.2.2. fedfsFsl 4.2.2.2. fedfsFsl
The fedfsFsl object class represents an FSL. The fedfsFsl object class represents an FSL.
A fedfsFsl's required attributes are an fedfsFslUuid, fedfsFsnUuid, A fedfsFsl's fedfsFslUuid, fedfsFsnUuid, fedfsNsdbName,
fedfsNsdbName, fedfsFslHost, and fedfsFslTTL. fedfsNsdbContainerEntry, fedfsFslHost, and fedfsFslTTL attributes are
REQUIRED.
A fedfsFsl's fedfsAnnotation and fedfsDescr attributes are OPTIONAL. A fedfsFsl's fedfsAnnotation and fedfsDescr attributes are OPTIONAL.
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 below is used to record an NFS FSL's
location. Other subtypes MAY be defined for other protocols (e.g. location. Other subtypes MAY be defined for other protocols (e.g.
CIFS). CIFS).
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,o=fedfs" where FSLUUID and "fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE" where $FSLUUID is
FSNUUID are the UUIDs of the FSL and its FSN respectively. Since the FSL's UUID, $FSNUUID is the FSN's UUID, and $NCE is the DN of the
LDAP requires a DN to be unique, this ensures that each FSL entry has NCE ("o=fedfs" by default). Since LDAP requires a DN to be unique,
a unique UUID value within the LDAP directory. this ensures that each FSL entry has a unique UUID value within the
LDAP directory.
<CODE BEGINS>
/// ///
/// objectclass ( /// objectclass (
/// 1.3.6.1.4.1.31103.1.1002 NAME 'fedfsFsl' /// 1.3.6.1.4.1.31103.1.1002 NAME 'fedfsFsl'
/// DESC 'A physical location of a fileset' /// DESC 'A physical location of a fileset'
/// SUP top ABSTRACT /// SUP top ABSTRACT
/// MUST ( /// MUST (
/// fedfsFslUuid /// fedfsFslUuid
/// $ fedfsFsnUuid /// $ fedfsFsnUuid
/// $ fedfsNsdbName /// $ fedfsNsdbName
/// $ fedfsNsdbContainerEntry
/// $ fedfsFslHost /// $ fedfsFslHost
/// $ fedfsFslTTL /// $ fedfsFslTTL
/// ) /// )
/// MAY ( /// MAY (
/// fedfsAnnotation /// fedfsAnnotation
/// $ fedfsDescr /// $ fedfsDescr
/// )) /// ))
/// ///
<CODE ENDS>
4.2.2.3. fedfsNfsFsl 4.2.2.3. 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,o=fedfs" where FSLUUID and "fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE" where $FSLUUID is
FSNUUID are the UUIDs of the FSL and its FSN respectively. Since the FSL's UUID, $FSNUUID is the FSN's UUID, and $NCE is the DN of the
LDAP requires a DN to be unique, this ensures that each NFS FSL entry NCE ("o=fedfs" by default). Since LDAP requires a DN to be unique,
has a unique UUID value within the LDAP directory. this ensures that each NFS FSL entry has a unique UUID value within
the LDAP directory.
<CODE BEGINS>
/// ///
/// objectclass ( /// objectclass (
/// 1.3.6.1.4.1.31103.1.1003 NAME 'fedfsNfsFsl' /// 1.3.6.1.4.1.31103.1.1003 NAME 'fedfsNfsFsl'
/// DESC 'A NFS location of a fileset' /// DESC 'An NFS location of a fileset'
/// SUP fedfsFsl STRUCTURAL /// SUP fedfsFsl STRUCTURAL
/// MUST ( /// MUST (
/// fedfsNfsPath /// fedfsNfsPath
/// $ fedfsNfsMajorVer /// $ fedfsNfsMajorVer
/// $ fedfsNfsMinorVer /// $ fedfsNfsMinorVer
/// $ fedfsNfsCurrency /// $ fedfsNfsCurrency
/// $ fedfsNfsInfo /// $ fedfsNfsGenFlagWritable
/// $ fedfsNfsFlags /// $ fedfsNfsGenFlagGoing
/// $ fedfsNfsGenFlagSplit
/// $ fedfsNfsTransFlagRdma
/// $ fedfsNfsClassSimul
/// $ fedfsNfsClassHandle
/// $ fedfsNfsClassFileid
/// $ fedfsNfsClassWritever
/// $ fedfsNfsClassChange
/// $ fedfsNfsClassReaddir
/// $ fedfsNfsReadRank
/// $ fedfsNfsReadOrder
/// $ fedfsNfsWriteRank
/// $ fedfsNfsWriteOrder
/// $ fedfsNfsVarSub
/// $ fedfsNfsValidFor /// $ fedfsNfsValidFor
/// )) /// ))
/// ///
<CODE ENDS>
5. NSDB Operations 5. NSDB Operations
The operations defined by the protocol can be described as several The operations defined by the protocol can be described as several
sub-protocols that are used by entities within the federation to sub-protocols that are used by entities within the federation to
perform different roles. perform different roles.
The first of these sub-protocols defines how the state of an NSDB The first of these sub-protocols defines how the state of an NSDB
location can be initialized and updated. The primary use of this node can be initialized and updated. The primary use of this sub-
sub-protocol is by an administrator to add, edit, or delete filesets, protocol is by an administrator to add, edit, or delete filesets,
their properties, and their fileset locations. their properties, and their fileset locations.
The second of these sub-protocols defines the queries that are sent The second of these sub-protocols defines the queries that are sent
to an NSDB location 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 location) and the information about the data stored within that NSDB node) and the
responses returned by the NSDB location. The primary use of this responses returned by the NSDB node. The primary use of this sub-
sub-protocol is by a fileserver in order to perform resolution, but protocol is by a fileserver in order to perform resolution, but it
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 using the schema defined in the previous section. If each NSDB node
location is a standard LDAP server, then, in theory, it is is a standard LDAP server, then, in theory, it is unnecessary to
unnecessary to describe the LDAP operations in detail, because the describe the LDAP operations in detail, because the operations are
operations are ordinary LDAP operations to query and update records. ordinary LDAP operations to query and update records. However, we do
However, we do not require that an NSDB location implement a complete not require that an NSDB node implement a complete LDAP service, and
LDAP service, and therefore we define in these sections the minimum therefore we define in these sections the minimum level of LDAP
level of LDAP functionality required to implement an NSDB location. functionality required to implement an NSDB node.
The NSDB sub-protocols are defined in the next two sub-sections. The NSDB sub-protocols are defined in the next two sub-sections. The
descriptions of LDAP messages in these sections use the LDAP Data
Interchange Format (LDIF) [RFC2849]. In order to differentiate
constant and variable strings in the LDIF specifications, variables
are prefixed by a $ character and use all upper case characters. For
example, a variable named FOO would be specified as $FOO.
The third sub-protocol defines the queries and other requests that The third sub-protocol defines the queries and other requests that
are sent to a fileserver in order to get information from it or to are sent to a fileserver in order to get information from it or to
modify the state of the fileserver in a manner related to the modify the state of the fileserver in a manner related to the
federation protocols. The primary purpose of this protocol is for an federation protocols. The primary purpose of this protocol is for an
administrator to create or delete a junction or discover related administrator to create or delete a junction or discover related
information about a particular fileserver. information about a particular fileserver.
The third sub-protocol is defined as an ONC RPC protocols. The The third sub-protocol is defined as an ONC RPC protocols. The
reason for using ONC RPC instead of LDAP is that all fileservers reason for using ONC RPC instead of LDAP is that all fileservers
support ONC RPC but some do not support an LDAP Directory server. support ONC RPC but some do not support an LDAP Directory server.
The ONC RPC administration protocol is defined in [FEDFS-ADMIN]. The ONC RPC administration protocol is defined in [FEDFS-ADMIN].
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 admin entity, however, is fileset and namespace information. The admin entity, however, is
stateless. All state is maintained at the NSDB locations or at the stateless. All state is maintained at the NSDB nodes or at the
fileserver. fileserver.
We require that each NSDB location be able to act as an LDAP server We require that each NSDB node be able to act as an LDAP server and
and that the protocol used for communicating between the admin entity that the protocol used for communicating between the admin entity and
and each NSDB location is LDAP. each NSDB node is LDAP.
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.
In the description of the LDAP messages and LDIF, we use the
following notation: constant strings and literal names are specified
in lower or mixed case, while variables or values are specified in
uppercase.
5.1.1. Create an FSN 5.1.1. Create an FSN
The administrator uses this operation to create a new FSN by This operation creates a new FSN in the NSDB by adding a new fedfsFsn
requesting the NSDB to create a new fedfsFsn in its LDAP database entry in the NSDB's LDAP directory.
with an fedfsFsnUuid value of FSNUUID and an NsdbName value of
NSDBNAME.
The NSDB location that receives the request SHOULD check that the A fedfsFsn entry contains a fedfsFsnUuid, fedfsNsdbName, and
NSDBNAME matches its own value and return an error if it does not. fedfsNsdbContainerEntry. The administrator chooses the fedfsFsnUuid
This is to ensure that an FSN is always created by the NSDB location and fedfsNsdbName. The process for choosing the fedfsFsnUuid is
encoded within the FSN as its owner. described in Section 4.2.1.1). The fedfsNsdbName is the name of the
NSDB node that will serve as the source of definitive information
about the FSN for the life of the FSN. The administrator sets the
fedfsNsdbContainerEntry value to the DN of the NSDB's NCE.
The NSDB location that receives the request SHOULD check all of the The NSDB node that receives the request SHOULD check that
fedfsNsdbName value matches its own value and return an error if it
does not. This is to ensure that an FSN is always created by the
NSDB node encoded within the FSN as its owner.
The NSDB node that receives the request SHOULD check all of the
attributes for validity and consistency, but this is not generally attributes for validity and consistency, but this is not generally
possible for LDAP servers because the consistency requirements cannot possible for LDAP servers because the consistency requirements cannot
be expressed in the LDAP schema (although many LDAP servers can be be expressed in the LDAP schema (although many LDAP servers can be
extended, via plug-ins or other mechanisms, to add functionality extended, via plug-ins or other mechanisms, to add functionality
beyond the strict definition of LDAP). beyond the strict definition of LDAP).
5.1.1.1. LDAP Request 5.1.1.1. LDAP Request
The admin chooses the fedfsFsnUuid and NsdbName of the FSN. The This operation is implemented using the LDAP ADD request described by
fedfsFsnUuid is a UUID and should be chosen via a standard process the LDIF below.
for creating a UUID (described in [RFC4122]). The NsdbName is the
name of the NSDB location that will serve as the source of definitive
information about an FSN for the life of that FSN. In the example
below, the admin server chooses a fedfsFsnUuid of FSNUUID and the
NsdbName of NSDBNAME and then sends an LDAP ADD request, described by
the LDIF below, to the NSDB location NSDBNAME. This will create a
new fedfsFsn on that NSDB location with the given attributes in the
LDAP database.
dn: fedfsFsnUuid=FSNUUID,o=fedfs dn: fedfsFsnUuid=$FSNUUID,$NCE
changeType: add changeType: add
objectClass: fedfsFsn objectClass: fedfsFsn
fedfsFsnUuid: FSNUUID fedfsFsnUuid: $FSNUUID
fedfsNsdbName: NSDBNAME fedfsNsdbName: $NSDBNAME
fedfsNsdbContainerEntry: $NCE
For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765-
00a0c91e6bf6", the $NSDBNAME is "nsdb.example.com", and the $NCE is
"o=fedfs" the operation would be:
dn: fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs
changeType: add
objectClass: fedfsFsn
fedfsFsnUuid: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
fedfsNsdbName: nsdb.example.com
fedfsNsdbContainerEntry: o=fedfs
5.1.2. Delete an FSN 5.1.2. Delete an FSN
This operation deletes the given fileset name. If the FSN entry This operation deletes an FSN by removing a fedfsFsn entry in the
being deleted has child FSL entries, this function MUST return an NSDB's LDAP directory.
error. This ensures that the NSDB will not contain any orphaned FSL
entries. A compliant LDAP implementation will meet this requirement If the FSN entry being deleted has child FSL entries, this function
since Section 4.8 of [RFC4511] defines the LDAP delete operation to MUST return an error. This ensures that the NSDB will not contain
only be capable of removing leaf entries. any orphaned FSL entries. A compliant LDAP implementation will meet
this requirement since Section 4.8 of [RFC4511] defines the LDAP
delete operation to only be capable of removing leaf entries.
Note that the FSN delete function only removes the fileset from the Note that the FSN delete function only removes the fileset from the
namespace (by removing the records for that FSN from the NSDB namespace (by removing the records for that FSN from the NSDB node
location that receives this request). The fileset and its data are that receives this request). The fileset and its data are not
not deleted. Any junction that has this FSN as its target may deleted. Any junction that has this FSN as its target may continue
continue to point to this non-existent FSN. A dangling reference may to point to this non-existent FSN. A dangling reference may be
be detected when a client tries to resolve the target of a junction detected when a client tries to resolve the target of a junction that
that refers to the deleted FSN and the NSDB returns an error. refers to the deleted FSN and the NSDB returns an error.
5.1.2.1. LDAP Request 5.1.2.1. LDAP Request
The admin sends an LDAP DELETE request to the NSDB server to remove This operation is implemented using the LDAP DELETE request described
the fedfsFsn from the NSDB server. An example LDIF for the delete by the LDIF below.
request is shown below.
dn: fedfsFsnUuid=FSNUUID,o=fedfs dn: fedfsFsnUuid=$FSNUUID,$NCE
changeType: delete
For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765-
00a0c91e6bf6" and $NCE is "o=fedfs", the operation would be:
dn: fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs
changeType: delete changeType: delete
5.1.3. Create an FSL 5.1.3. Create an FSL
This operations creates a new Fileset location at the given location This operation creates a new FSL for the given FSN by adding a new
denoted by HOST and PATH for the given FSN. Normally an FSL is fedfsFsl entry in the NSDB's LDAP directory.
identified by the HOST:PATH pair. A UUID is an optional way to
identify an FSL if it is recovered to a different HOST:PATH after a
backup/restore.
The FSL create command will result in the admin server sending an A fedfsFsl entry contains a fedfsFslUuid, fedfsFsnUuid,
LDAP ADD request to create a new fedfsFsl at the NSDB maintaining the fedfsNsdbName, fedfsNsdbContainerEntry, fedfsFslHost, and
given FSN. The example LDIF is shown below. The PATH is the fedfsFslTTL. The admininistrator chooses the fedfsFslUuid. The
pathname where the fileset is located on the fileserver HOST. process for choosing the fedfsFslUuid is described in
Section 4.2.1.1. The fedfsFsnUuid is the UUID of the FSL's FSN. The
fedfsNsdbName is the name of the NSDB node that stores definitive
information about the FSL's FSN. The administrator sets the
fedfsNsdbContainerEntry value to the DN of the NSDB's NCE. The
fedfsFslHost value is the network location of the fileserver that
stores the FSL. The fedfsFslTTL is chosen by the administrator as
described in Section 2.4.2.
The administrator will also set additional attributes depending on
the FSL type.
5.1.3.1. LDAP Request 5.1.3.1. LDAP Request
The admin sends an LDAP ADD request to the NSDB server to add the This operation is implemented using the LDAP ADD request described by
FSL. An example LDIF for adding an NFS FSL is shown below. the LDIF below (NOTE: the LDIF shows the creation of an NFS FSL)
dn:fedfsFslUuid=UUID,fedfsFsnUuid=FSNUUID,o=fedfs dn:fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE
changeType: add changeType: add
objectClass: fedfsNfsFsl objectClass: fedfsNfsFsl
fedfsFslUuid: UUID fedfsFslUuid: $FSLUUID
fedfsFsnUuid: FSNUUID fedfsFsnUuid: $FSNUUID
fedfsNsdbName: NSDBNAME fedfsNsdbName: $NSDBNAME
fedfsFslHost: HOST fedfsNsdbContainerEntry: $NCE
fedfsFslTTL: TTL fedfsFslHost: $HOST
fedfsNfsPath: PATH fedfsFslTTL: $TTL
fedfsNfsMajorVer: MAJOR fedfsNfsPath: $PATH
fedfsNfsMinorVer: MINOR fedfsNfsMajorVer: $MAJOR
fedfsNfsCurrency: CURRENCY fedfsNfsMinorVer: $MINOR
fedfsNfsInfo: INFO fedfsNfsCurrency: $CURRENCY
fedfsNfsFlags: FLAGS fedfsNfsGenFlagWritable: $WRITABLE
fedfsNfsValidFor: TIME fedfsNfsGenFlagGoing: $GOING
fedfsAnnotation: ANNOTATION fedfsNfsGenFlagSplit: $SPLIT
fedfsDescr: DESCR fedfsNfsTransFlagRdma: $RDMA
fedfsNfsClassSimul: $CLASS_SIMUL
fedfsNfsClassHandle:$CLASS_HANDLE
fedfsNfsClassFileid:$CLASS_FILEID
fedfsNfsClassWritever:$CLASS_WRITEVER
fedfsNfsClassChange: $CLASS_CHANGE
fedfsNfsClassReaddir: $CLASS_READDIR
fedfsNfsReadRank: $READ_RANK
fedfsNfsReadOrder: $READ_ORDER
fedfsNfsWriteRank: $WRITE_RANK
fedfsNfsWriteOrder: $WRITE_ORDER
fedfsNfsVarSub: $VAR_SUB
fedfsNfsValidFor: $TIME
fedfsAnnotation: $ANNOTATION
fedfsDescr: $DESCR
For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765-
00a0c91e6bf6", the $FSLUUID is "84f775a7-8e31-14ae-b39d-
10eeee060d2c", the $NSDBNAME is "nsdb.example.com", the $HOST is
"server.example.com", the $TTL is "300" seconds, the $PATH is stored
in the file "/tmp/fsl_path", fileset is exported via NFSv4.1 ($MAJOR
is "4" and $MINOR is "1"), $CURRENCY is "0" (an up to date copy), the
FSL is writable, but not going, split, or accessible via RDMA, the
simultaneous-use class is "1", the handle 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 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, $ANNOTATION is ""foo"
= "bar"", $DESC is "This is a description.", and the $NCE is
"o=fedfs", the operation would be (for readability the DN is split
into two lines):
dn:fedfsFslUuid=84f775a7-8e31-14ae-b39d-10eeee060d2c,
fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs
changeType: add
objectClass: fedfsNfsFsl
fedfsFslUuid: 84f775a7-8e31-14ae-b39d-10eeee060d2c
fedfsFsnUuid: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
fedfsNsdbName: nsdb.example.com
fedfsNsdbContainerEntry: o=fedfs
fedfsFslHost: server.example.com
fedfsFslTTL: 300
fedfsNfsPath:< file:///tmp/fsl_path
fedfsNfsMajorVer: 4
fedfsNfsMinorVer: 1
fedfsNfsCurrency: 0
fedfsNfsGenFlagWritable: TRUE
fedfsNfsGenFlagGoing: FALSE
fedfsNfsGenFlagSplit: FALSE
fedfsNfsTransFlagRdma: FALSE
fedfsNfsClassSimul: 1
fedfsNfsClassHandle: 0
fedfsNfsClassFileid: 1
fedfsNfsClassWritever: 1
fedfsNfsClassChange: 1
fedfsNfsClassReaddir: 9
fedfsNfsReadRank: 7
fedfsNfsReadOrder: 8
fedfsNfsWriteRank: 5
fedfsNfsWriteOrder: 6
fedfsNfsVarSub: FALSE
fedfsNfsValidFor: 300
fedfsAnnotation: "foo" = "bar"
fedfsDescr: This is a description.
5.1.4. Delete an FSL 5.1.4. Delete an FSL
This operation deletes the given Fileset location. The admin This operation deletes the given Fileset location. The admin
requests the NSDB location storing the fedfsFsl to delete it from its requests the NSDB node storing the fedfsFsl to delete it from its
database. This operation does not result in the fileset location's database. This operation does not result in the fileset location's
data being deleted at the fileserver. data being deleted at the fileserver.
5.1.4.1. LDAP Request 5.1.4.1. LDAP Request
The admin sends an LDAP DELETE request to the NSDB server to remove The admin sends an LDAP DELETE request to the NSDB node to remove the
the FSL. FSL.
dn: fedfsFslUuid=UUID,fedfsFsnUuid=FSNUUID,o=fedfs dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE
changeType: delete changeType: delete
For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765-
00a0c91e6bf6", the $FSLUUID is "84f775a7-8e31-14ae-b39d-
10eeee060d2c", and the $NCE is "o=fedfs", the operation would be (for
readability the DN is split into two lines):
dn: fedfsFslUuid=84f775a7-8e31-14ae-b39d-10eeee060d2c,
fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs
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
server maintaining this FSL. The attributes that must not change are node maintaining this FSL. The attributes that must not change are
the fedfsFslUuid and the fedfsFsnUuid of the fileset this FSL the fedfsFslUuid and the fedfsFsnUuid of the fileset this FSL
implements. implements.
5.1.5.1. LDAP Request 5.1.5.1. LDAP Request
The admin sends an LDAP MODIFY request to the NSDB server to update The admin sends an LDAP MODIFY request to the NSDB node to update the
the FSL. FSL.
dn: fedfsFslUuid=UUID,fedfsFsnUuid=FSNUUID,o=fedfs dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE
changeType: modify changeType: modify
replace: ATTRIBUTE-TYPE replace: $ATTRIBUTE-TYPE
For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765-
00a0c91e6bf6", the $FSLUUID is "84f775a7-8e31-14ae-b39d-
10eeee060d2c", the $NCE is "o=fedfs", and the administrator wished to
change the TTL to 10 minutes, the operation would be (for readability
the DN is split into two lines):
dn: fedfsFslUuid=84f775a7-8e31-14ae-b39d-10eeee060d2c,
fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs
changeType: modify
replace: fedfsFslTTL
fedfsFslTTL: 600
5.2. NSDB Operations for Fileservers 5.2. NSDB Operations for Fileservers
5.2.1. Lookup FSLs for an FSN 5.2.1. Lookup FSLs for an FSN
Using an LDAP search, the fileserver can obtain all of the FSLs for a Using an LDAP search, the fileserver can obtain all of the FSLs for a
given FSN. The FSN's fedfsFsnUuid is used as the search key. The given FSN. The FSN's fedfsFsnUuid is used as the search key. The
following examples use the LDAP URI format defined in [RFC4516]. following examples use the LDAP URI format defined in [RFC4516].
To obtain a list of all FSLs on the NSDB named "nsdb.example.com", To obtain a list of all FSLs for $FSNUUID on the NSDB named
the following search can be used (for readability the URI is split $NSDBNAME, the following search can be used (for readability the URI
into two lines): is split into two lines):
ldap://nsdb.example.com/fsnUuid=FSNUUID,o=fedfs??one? ldap://$NSDBNAME/fsnUuid=$FSNUUID,$NCE??one?
(objectClass=fedfsFsl) (objectClass=fedfsFsl)
This search is for the children of the object with DN This search is for the children of the object with DN
"fedfsFsnUuid=FSNUUID,o=fedfs" 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.
The following search can be used to obtain only the NFS FSLs on the For example if $NSDBNAME is "nsdb.example.com", $FSNUUID is
NSDB named "nsdb.example.com" (for readability the URI is split into "f81d4fae-7dec-11d0-a765-00a0c91e6bf6", and $NCE is "o=fedfs", the
two lines): search would be (for readability the URI is split into three lines):
ldap://nsdb.example.com/fsnUuid=FSNUUID,o=fedfs??one? ldap://nsdb.example.com/
fsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs
??one?(objectClass=fedfsFsl)
The following search can be used to obtain only the NFS FSLs for
$FSNUUID on the NSDB named $NSDBNAME (for readability the URI is
split into two lines):
ldap://$NSDBNAME/fsnUuid=$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,o=fedfs", 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 f81d4fae-
7dec-11d0-a765-00a0c91e6bf6, and $NCE is "o=fedfs",the search would
be (for readability the URI is split into three lines):
ldap://nsdb.example.com/
fsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs
??one?(objectClass=fedfsNfsFsl)
The fileserver can present the search results in a format useful to The fileserver can present the search results in a format useful to
the type of the client on whose behalf the fileserver is performing the type of the client on whose behalf the fileserver is performing
the request. For an NFS client, the fileserver can use the search the request. For an NFS client, the fileserver can use the search
results to construct an NFSv4 fs_locations list or NFSv4.1 results to construct an NFSv4 fs_locations list or NFSv4.1
fs_locations_info list. fs_locations_info list.
6. Security Considerations 6. Security Considerations
Both NFSv4/NFSv4.1 and LDAP provide security mechanisms. When used Both NFSv4/NFSv4.1 and LDAP provide security mechanisms. When used
in conjunction with the federated filesystem protocols described in in conjunction with the federated filesystem protocols described in
skipping to change at page 30, line 43 skipping to change at page 43, line 4
7.1. LDAP Descriptor Registration 7.1. LDAP Descriptor Registration
Subject: Request for LDAP Descriptor Registration Subject: Request for LDAP Descriptor Registration
Person & email address to contact for further information: See Person & email address to contact for further information: See
"Author/Change Controller" "Author/Change Controller"
Specification: draft-ietf-nfsv4-federated-fs-protocol Specification: draft-ietf-nfsv4-federated-fs-protocol
Author/Change Controller: [document authors] Author/Change Controller: [document authors]
Object Identifier: 1.3.6.1.4.1.31103.1.1 Object Identifier: 1.3.6.1.4.1.31103.1.1
Descriptor (short name): fedfsUuid Descriptor (short name): fedfsUuid
Usage: attribute type
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
Object Identifier: 1.3.6.1.4.1.31103.1.3 Object Identifier: 1.3.6.1.4.1.31103.1.3
Descriptor (short name): fedfsFsnUuid Descriptor (short name): fedfsFsnUuid
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.4 Object Identifier: 1.3.6.1.4.1.31103.1.4
Descriptor (short name): fedfsNsdbName Descriptor (short name): fedfsNsdbName
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.5 Object Identifier: 1.3.6.1.4.1.31103.1.5
Descriptor (short name): fedfsFslUuid Descriptor (short name): fedfsNsdbContainerEntry
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.6 Object Identifier: 1.3.6.1.4.1.31103.1.6
Descriptor (short name): fedfsFslHost Descriptor (short name): fedfsFslUuid
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.7 Object Identifier: 1.3.6.1.4.1.31103.1.7
Descriptor (short name): fedfsFslTTL Descriptor (short name): fedfsFslHost
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.8 Object Identifier: 1.3.6.1.4.1.31103.1.8
Descriptor (short name): fedfsNfsPath Descriptor (short name): fedfsFslTTL
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.9 Object Identifier: 1.3.6.1.4.1.31103.1.9
Descriptor (short name): fedfsNfsMajorVer Descriptor (short name): fedfsAnnotation
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.10 Object Identifier: 1.3.6.1.4.1.31103.1.10
Descriptor (short name): fedfsDescr
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.100
Descriptor (short name): fedfsNfsPath
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.101
Descriptor (short name): fedfsNfsMajorVer
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.102
Descriptor (short name): fedfsNfsMinorVer Descriptor (short name): fedfsNfsMinorVer
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.11 Object Identifier: 1.3.6.1.4.1.31103.1.103
Descriptor (short name): fedfsNfsCurrency Descriptor (short name): fedfsNfsCurrency
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.12 Object Identifier: 1.3.6.1.4.1.31103.1.104
Descriptor (short name): fedfsNfsInfo Descriptor (short name): fedfsNfsGenFlagWritable
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.13 Object Identifier: 1.3.6.1.4.1.31103.1.105
Descriptor (short name): fedfsNfsFlags Descriptor (short name): fedfsNfsGenFlagGoing
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.14 Object Identifier: 1.3.6.1.4.1.31103.1.106
Descriptor (short name): fedfsNfsValidFor Descriptor (short name): fedfsNfsGenFlagSplit
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.15 Object Identifier: 1.3.6.1.4.1.31103.1.107
Descriptor (short name): fedfsAnnotation Descriptor (short name): fedfsNfsTransFlagRdma
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.16 Object Identifier: 1.3.6.1.4.1.31103.1.108
Descriptor (short name): fedfsDescr Descriptor (short name): fedfsNfsClassSimul
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.109
Descriptor (short name): fedfsNfsClassHandle
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.110
Descriptor (short name): fedfsNfsClassFileid
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.111
Descriptor (short name): fedfsNfsClassWritever
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.112
Descriptor (short name): fedfsNfsClassChange
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.113
Descriptor (short name): fedfsNfsClassReaddir
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.114
Descriptor (short name): fedfsNfsReadRank
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.115
Descriptor (short name): fedfsNfsReadOrder
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.116
Descriptor (short name): fedfsNfsWriteRank
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.117
Descriptor (short name): fedfsNfsWriteOrder
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.118
Descriptor (short name): fedfsNfsVarSub
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.119
Descriptor (short name): fedfsNfsValidFor
Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.1001 Object Identifier: 1.3.6.1.4.1.31103.1.1001
Descriptor (short name): fedfsFsn Descriptor (short name): fedfsFsn
Usage: object class
Object Identifier: 1.3.6.1.4.1.31103.1.1002 Object Identifier: 1.3.6.1.4.1.31103.1.1002
Descriptor (short name): fedfsFsl Descriptor (short name): fedfsFsl
Usage: object class
Object Identifier: 1.3.6.1.4.1.31103.1.1003 Object Identifier: 1.3.6.1.4.1.31103.1.1003
Descriptor (short name): fedfsNfsFsl Descriptor (short name): fedfsNfsFsl
Usage: object class
8. Glossary 8. Glossary
Administrator: user with the necessary authority to initiate Administrator: user with the necessary authority to initiate
administrative tasks on one or more servers. administrative tasks on one or more servers.
Admin entity: A server or agent that administers a collection of Admin entity: A server or agent that administers a collection of
fileservers and persistently stores the namespace information. fileservers and persistently stores the namespace information.
Client: Any client that accesses the fileserver data using a Client: Any client that accesses the fileserver data using a
supported filesystem access protocol. supported filesystem access protocol.
Federation: A set of server collections and singleton servers that Federation: A set of server collections and singleton servers that
skipping to change at page 33, line 27 skipping to change at page 47, line 14
same. same.
Junction: A filesystem object used to link a directory name in the Junction: A filesystem object used to link a directory name in the
current fileset with an object within another fileset. The current fileset with an object within another fileset. The
server-side "link" from a leaf node in one fileset to the root of server-side "link" from a leaf node in one fileset to the root of
another fileset. another fileset.
Namespace: A filename/directory tree that a sufficiently-authorized Namespace: A filename/directory tree that a sufficiently-authorized
client can observe. client can observe.
NSDB (Namespace Database Service): A service that maps FSNs to FSLs. NSDB (Namespace Database) Service: A service that maps FSNs to FSLs.
The NSDB may also be used to store other information, such as The NSDB may also be used to store other information, such as
annotations for these mappings and their components. annotations for these mappings and their components.
NSDB Node: The name or location of a server that implements part of NSDB Node: The name or location of a server that implements part of
the NSDB service and is responsible for keeping track of the FSLs the NSDB service and is responsible for keeping track of the FSLs
(and related info) that implement a given partition of the FSNs. (and related info) that implement a given partition of the FSNs.
Referral: A server response to a client access that directs the Referral: A server response to a client access that directs the
client to evaluate the current object as a reference to an object client to evaluate the current object as a reference to an object
at a different location (specified by an FSL) in another fileset, at a different location (specified by an FSL) in another fileset,
skipping to change at page 33, line 49 skipping to change at page 47, line 36
the access to the object at the new location. the access to the object at the new location.
Replica: A replica is a redundant implementation of a fileset. Each Replica: A replica is a redundant implementation of a fileset. Each
replica shares the same FSN, but has a different FSL. replica 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, and therefore each replica is self-consistent at
any moment. any moment.
We do not assume that updates to each replica occur simultaneously We do not assume that updates to each replica occur
If a replica is offline or unreachable, the other replicas may be simultaneously. If a replica is offline or unreachable, the other
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.
skipping to change at page 34, line 16 skipping to change at page 48, line 4
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 9.1. Normative References
[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),
2009.
[FEDFS-REQTS]
Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Naik, "Requirements for Federated File Systems",
draft-ietf-nfsv4-federated-fs-reqts (Work In Progress),
2009.
[NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4 [NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4
Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (work Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (work
in progress), December 2008. in progress), December 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997. Specification", RFC 2203, September 1997.
[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.
[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.
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
Technical Specification", RFC 2849, June 2000.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003. (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, (LDAP): Technical Specification Road Map", RFC 4510,
skipping to change at page 35, line 24 skipping to change at page 48, line 49
(LDAP): The Protocol", RFC 4511, June 2006. (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, (LDAP): Directory Information Models", RFC 4512,
June 2006. June 2006.
[RFC4513] Harrison, R., "Lightweight Directory Access Protocol [RFC4513] Harrison, R., "Lightweight Directory Access Protocol
(LDAP): Authentication Methods and Security Mechanisms", (LDAP): Authentication Methods and Security Mechanisms",
RFC 4513, June 2006. RFC 4513, June 2006.
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names",
RFC 4514, June 2006.
[RFC4516] Smith, M. and T. Howes, "Lightweight Directory Access [RFC4516] Smith, M. and T. Howes, "Lightweight Directory Access
Protocol (LDAP): Uniform Resource Locator", RFC 4516, Protocol (LDAP): Uniform Resource Locator", RFC 4516,
June 2006. June 2006.
[RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP):
Syntaxes and Matching Rules", RFC 4517, June 2006. Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4519] Sciberras, A., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519,
June 2006.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 4520, June 2006. Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
9.2. Informational References 9.2. Informational References
[AFS] Howard, J., "An Overview of the Andrew File System", [AFS] Howard, J., "An Overview of the Andrew File System",
Proceeding of the USENIX Winter Technical Conference , Proceeding of the USENIX Winter Technical Conference ,
1988. 1988.
[FEDFS-ADMIN]
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),
2009.
[FEDFS-DNS-SRV]
Everhart, C., Adamson, W., and J. Zhang, "Using DNS SRV to
Specify a Global File Name Space with NFS version 4",
draft-ietf-nfsv4-federated-fs-dns-srv-namespace (Work In
Progress), 2009.
[FEDFS-REQTS]
Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Naik, "Requirements for Federated File Systems",
draft-ietf-nfsv4-federated-fs-reqts (Work In Progress),
2009.
[NFSv4.1-XDR]
Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4
Minor Version 1 XDR Description",
draft-ietf-nfsv4-minorversion1-dot-x-12 (work in
progress), December 2008.
[RFC1094] Nowicki, B., "NFS: Network File System Protocol [RFC1094] Nowicki, B., "NFS: Network File System Protocol
specification", RFC 1094, March 1989. specification", RFC 1094, March 1989.
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
Version 3 Protocol Specification", RFC 1813, June 1995. Version 3 Protocol Specification", RFC 1813, June 1995.
[RFC3254] Alvestrand, H., "Definitions for talking about [RFC3254] Alvestrand, H., "Definitions for talking about
directories", RFC 3254, April 2002. directories", RFC 3254, April 2002.
Appendix A. Acknowledgments Appendix A. Acknowledgments
We would like to thank Andy Adamson of NetApp, Paul Lemahieu of EMC, We would like to thank Andy Adamson of NetApp, Paul Lemahieu of EMC,
Robert Thurlow of Sun Microsystems, and Mario Wurzl of EMC for Robert Thurlow of Sun Microsystems, and Mario Wurzl of EMC for
helping to author this document. helping to author this document.
We would also like to thank George Amvrosiadis for pointing out that We would also like to thank George Amvrosiadis, Trond Myklebust, and
several LDAP attributes were missing the SINGLE-VALUE keyword in a Nicolas Williams for their comments.
draft version of this document.
The extract.sh shell script and formatting conventions were first
described by the authors of the NFSv4.1 XDR specification
[NFSv4.1-XDR].
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 US
Phone: +1 781-768-5359 Phone: +1 781-768-5359
 End of changes. 234 change blocks. 
503 lines changed or deleted 1176 lines changed or added

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