RFC 7532
Namespace Database (NSDB) Protocol for Federated File Systems
Pages: 65
Proposed Standard
Proposed Standard
Part 3 of 3 – Pages 42 to 65
5. NSDB Operations
The operations defined by the protocol can be described as several sub-protocols that are used by entities within a federation to perform different roles. The first of these sub-protocols defines how the state of an NSDB node can be initialized and updated. The primary use of this sub- protocol is by an administrator to add, edit, or delete filesets, their properties, and their fileset locations. The second of these sub-protocols defines the queries that are sent to an NSDB node in order to perform resolution (or to find other information about the data stored within that NSDB node) and the responses returned by the NSDB node. The primary use of this sub- protocol is by a fileserver in order to perform resolution, but it may also be used by an administrator to query the state of the system. The first and second sub-protocols are defined as LDAP operations, using the schema defined in the previous section. If each NSDB node is a standard LDAP server, then, in theory, it is unnecessary to describe the LDAP operations in detail because the operations are ordinary LDAP operations to query and update records. However, we do not require that an NSDB node implement a complete LDAP service. Therefore, we define the minimum level of LDAP functionality required to implement an NSDB node. The NSDB sub-protocols are defined in Section 5.1 and Section 5.2. The descriptions of LDAP messages in these sections use the LDAP Data 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 uppercase characters. For example, a variable named FOO would be specified as $FOO. This document uses the term "NSDB client" to refer to an LDAP client that uses either of the NSDB sub-protocols. The third sub-protocol defines the queries and other requests that 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 federation protocols. The primary purpose of this protocol is for an administrator to create or delete a junction or discover related information about a particular fileserver. The third sub-protocol is defined as an Open Network Computing (ONC) Remote Procedure Call (RPC) protocol. The reason for using ONC RPC
instead of LDAP is that all fileservers support ONC RPC, but some do not support an LDAP directory server. The ONC RPC administration protocol is defined in [RFC7533].5.1. NSDB Operations for Administrators
The admin entity initiates and controls the commands to manage fileset and namespace information. The protocol used for communicating between the admin entity and each NSDB node MUST be the LDAPv3 [RFC4510] protocol. 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.5.1.1. Create an FSN
This operation creates a new FSN in the NSDB by adding a new fedfsFsn entry in the NSDB's LDAP directory. A fedfsFsn entry contains a fedfsFsnUuid. The administrator chooses the fedfsFsnUuid by the process described in Section 2.12. A fedfsFsn entry also contains a fedfsFsnTTL. The fedfsFsnTTL is chosen by the administrator as described in Section 2.8.3.5.1.1.1. LDAP Request
This operation is implemented using the LDAP ADD request described by the LDIF below. dn: fedfsFsnUuid=$FSNUUID,$NCE changeType: add objectClass: fedfsFsn fedfsFsnUuid: $FSNUUID fedfsFsnTTL: $TTL For example, if $FSNUUID is "e8c4761c-eb3b-4307-86fc-f702da197966", $TTL is "300" seconds, and $NCE is "o=fedfs", the operation would be: dn: fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs changeType: add objectClass: fedfsFsn fedfsFsnUuid: e8c4761c-eb3b-4307-86fc-f702da197966 fedfsFsnTTL: 300
5.1.2. Delete an FSN
This operation deletes an FSN by removing a fedfsFsn entry in the NSDB's LDAP directory. If the FSN entry being deleted has child FSL entries, this function MUST return an error. This ensures that the NSDB will not contain 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 removes the fileset only from a federation namespace (by removing the records for that FSN from the NSDB node that receives this request). The fileset and its data are not deleted. Any junction that has this FSN as its target may continue to point to this non-existent FSN. A dangling reference may be detected when a fileserver tries to resolve a junction that refers to the deleted FSN.5.1.2.1. LDAP Request
This operation is implemented using the LDAP DELETE request described by the LDIF below. dn: fedfsFsnUuid=$FSNUUID,$NCE changeType: delete For example, if $FSNUUID is "e8c4761c-eb3b-4307-86fc-f702da197966" and $NCE is "o=fedfs", the operation would be: dn: fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs changeType: delete5.1.3. Create an FSL
This operation creates a new FSL for the given FSN by adding a new fedfsFsl entry in the NSDB's LDAP directory. A fedfsFsl entry contains a fedfsFslUuid and fedfsFsnUuid. The administrator chooses the fedfsFslUuid. The process for choosing the fedfsFslUuid is described in Section 2.12. The fedfsFsnUuid is the UUID of the FSL's FSN. The administrator will also set additional attributes depending on the FSL type.
5.1.3.1. LDAP Request
This operation is implemented using the LDAP ADD request described by the LDIF below (Note: the LDIF shows the creation of an NFS FSL.) dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE changeType: add objectClass: fedfsNfsFsl fedfsFslUuid: $FSLUUID fedfsFsnUuid: $FSNUUID fedfsNfsURI: nfs://$HOST:$PORT//$PATH fedfsNfsCurrency: $CURRENCY fedfsNfsGenFlagWritable: $WRITABLE fedfsNfsGenFlagGoing: $GOING fedfsNfsGenFlagSplit: $SPLIT 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 $FSNUUID is "e8c4761c-eb3b-4307-86fc-f702da197966", $FSLUUID is "ba89a802-41a9-44cf-8447-dda367590eb3", $HOST is "server.example.com", $PORT is "20049", $PATH is stored in the file "/tmp/fsl_path", $CURRENCY is "0" (an up-to-date copy), the FSL is writable, but not going, split, or accessible via Remote Direct Memory Access (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 $NCE is "o=fedfs", the operation would be (for readability, the DN is split into two lines):
dn: fedfsFslUuid=ba89a802-41a9-44cf-8447-dda367590eb3,
fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs
changeType: add
objectClass: fedfsNfsFsl
fedfsFslUuid: ba89a802-41a9-44cf-8447-dda367590eb3
fedfsFsnUuid: e8c4761c-eb3b-4307-86fc-f702da197966
fedfsNfsURI: nfs://server.example.com:20049//tmp/fsl_path
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.3.2. Selecting fedfsNfsFsl Values
The fedfsNfsFSl object class is used to describe NFSv4-accessible
filesets. For the reasons described in Section 2.8.4, administrators
SHOULD choose reasonable values for all LDAP attributes of an
NFSv4-accessible fedfsNfsFsl even though some of these LDAP
attributes are not explicitly contained in an NFSv4 fs_locations
attribute.
When the administrator is unable to choose reasonable values for the
LDAP attributes not explicitly contained in an NFSv4 fs_locations
attribute, the values in the following table are RECOMMENDED.
+-------------------------+----------+------------------------------+ | LDAP attribute | LDAP | Notes | | | value | | +-------------------------+----------+------------------------------+ | fedfsNfsCurrency | negative | Indicates that the server | | | value | does not know the currency | | | | (see Section 11.10.1 of | | | | [RFC5661]). | | fedfsNfsGenFlagWritable | FALSE | Leaving unset is not harmful | | | | (see Section 11.10.1 of | | | | [RFC5661]). | | fedfsNfsGenFlagGoing | FALSE | NFS client will detect a | | | | migration event if the FSL | | | | becomes unavailable. | | fedfsNfsGenFlagSplit | TRUE | Safe to assume that the FSL | | | | is split. | | fedfsNfsTransFlagRdma | TRUE | NFS client will detect if | | | | RDMA access is available. | | fedfsNfsClassSimul | 0 | 0 is treated as non-matching | | | | (see Section 11.10.1 of | | | | [RFC5661]). | | fedfsNfsClassHandle | 0 | See fedfsNfsClassSimul note. | | fedfsNfsClassFileid | 0 | See fedfsNfsClassSimul note. | | fedfsNfsClassWritever | 0 | See fedfsNfsClassSimul note. | | fedfsNfsClassChange | 0 | See fedfsNfsClassSimul note. | | fedfsNfsClassReaddir | 0 | See fedfsNfsClassSimul note. | | fedfsNfsReadRank | 0 | Highest value ensures FSL | | | | will be tried. | | fedfsNfsReadOrder | 0 | See fedfsNfsReadRank note. | | fedfsNfsWriteRank | 0 | See fedfsNfsReadRank note. | | fedfsNfsWriteOrder | 0 | See fedfsNfsReadRank note. | | fedfsNfsVarSub | FALSE | NFSv4 does not define | | | | variable substitution in | | | | paths. | | fedfsNfsValidFor | 0 | Indicates no appropriate | | | | refetch interval (see | | | | Section 11.10.2 of | | | | [RFC5661]). | +-------------------------+----------+------------------------------+5.1.4. Delete an FSL
This operation deletes an FSL record. The admin requests the NSDB node storing the fedfsFsl to delete it from its database. This operation does not result in fileset data being deleted on any fileserver.
5.1.4.1. LDAP Request
The admin sends an LDAP DELETE request to the NSDB node to remove the FSL. dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE changeType: delete For example, if $FSNUUID is "e8c4761c-eb3b-4307-86fc-f702da197966", $FSLUUID is "ba89a802-41a9-44cf-8447-dda367590eb3", and $NCE is "o=fedfs", the operation would be (for readability, the DN is split into two lines): dn: fedfsFslUuid=ba89a802-41a9-44cf-8447-dda367590eb3, fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs changeType: delete5.1.5. Update an FSL
This operation updates the attributes of a given FSL. This command results in a change in the attributes of the fedfsFsl at the NSDB node maintaining this FSL. The values of the fedfsFslUuid and fedfsFsnUuid attributes MUST NOT change during an FSL update.5.1.5.1. LDAP Request
The admin sends an LDAP MODIFY request to the NSDB node to update the FSL. dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE changeType: modify replace: $ATTRIBUTE-TYPE For example, if $FSNUUID is "e8c4761c-eb3b-4307-86fc-f702da197966", $FSLUUID is "ba89a802-41a9-44cf-8447-dda367590eb3", $NCE is "o=fedfs", and the administrator wished to change the NFS read rank to 10, the operation would be (for readability, the DN is split into two lines): dn: fedfsFslUuid=ba89a802-41a9-44cf-8447-dda367590eb3, fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs changeType: modify replace: fedfsNfsReadClass fedfsNfsReadRank: 10
5.2. NSDB Operations for Fileservers
5.2.1. NSDB Container Entry (NCE) Enumeration
To find the NCEs for the NSDB nsdb.example.com, a fileserver would do the following: nce_list = empty connect to the LDAP directory at nsdb.example.com for each namingContext value $BAR in the root DSE /* $BAR is a DN */ query for a fedfsNceDN value at $BAR /* * The RFC 4516 LDAP URL for this search would be * * ldap://nsdb.example.com:389/$BAR?fedfsNceDN?? * (objectClass=fedfsNsdbContainerInfo) * */ if a fedfsNceDN value is found add the value to the nce_list5.2.2. Lookup FSLs for an FSN
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 following examples use the LDAP Uniform Resource Identifier (URI) format defined in [RFC4516]. To obtain a list of all FSLs for $FSNUUID on the NSDB named $NSDBNAME, the following search can be used (for readability, the URI is split into two lines): for each $NCE in nce_list ldap://$NSDBNAME/fedfsFsnUuid=$FSNUUID,$NCE??one? (objectClass=fedfsFsl) This search is for the children of the object with DN "fedfsFsnUuid=$FSNUUID,$NCE" with a filter for "objectClass=fedfsFsl". The scope value of "one" restricts the search to the entry's children (rather than the entire subtree below the entry), and the filter ensures that only FSL entries are returned. For example, if $NSDBNAME is "nsdb.example.com", $FSNUUID is "e8c4761c-eb3b-4307-86fc-f702da197966", and $NCE is "o=fedfs", the search would be (for readability, the URI is split into three lines):
ldap://nsdb.example.com/
fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,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):
for each $NCE in nce_list
ldap://$NSDBNAME/fedfsFsnUuid=$FSNUUID,$NCE??one?
(objectClass=fedfsNfsFsl)
This also searches for the children of the object with DN
"fedfsFsnUuid=$FSNUUID,$NCE", but the filter for "objectClass =
fedfsNfsFsl" restricts the results to only NFS FSLs.
For example, if $NSDBNAME is nsdb.example.com, $FSNUUID is "e8c4761c-
eb3b-4307-86fc-f702da197966", and $NCE is "o=fedfs", the search would
be (for readability, the URI is split into three lines):
ldap://nsdb.example.com/
fedfsFsnUuid=e8c4761c-eb3b-4307-86fc-f702da197966,o=fedfs
??one?(objectClass=fedfsNfsFsl)
The fileserver will generate a referral based on the set of FSLs
returned by these queries using the process described in
Section 2.8.4.
5.3. NSDB Operations and LDAP Referrals
The LDAPv3 protocol defines an LDAP referral mechanism that allows an
LDAP server to redirect an LDAP client. LDAPv3 defines two types of
LDAP referrals: the Referral type defined in Section 4.1.10 of
[RFC4511] and the SearchResultReference type defined in Section 4.5.3
of [RFC4511]. In both cases, the LDAP referral lists one or more
URIs for services that can be used to complete the operation. In the
remainder of this document, the term "LDAP referral" is used to
indicate either of these types.
If an NSDB operation results in an LDAP referral, the NSDB client MAY
follow the LDAP referral. An NSDB client's decision to follow an
LDAP referral is implementation and configuration dependent. For
example, an NSDB client might be configured to follow only those LDAP
referrals that were received over a secure channel or only those that
target an NSDB that supports encrypted communication. If an NSDB
client chooses to follow an LDAP referral, the NSDB client MUST
process the LDAP referral and prevent looping as described in
Section 4.1.10 of [RFC4511].
6. Security Considerations
Both the NFSv4 and LDAPv3 protocols provide security mechanisms. When used in conjunction with the federated file system protocols described in this document, the use of these mechanisms is RECOMMENDED. Specifically, the use of RPCSEC_GSS [RFC2203], which is built on the Generic Security Service Application Program Interface (GSS-API) [RFC2743], is RECOMMENDED on all NFS connections between a file-access client and fileserver. The security considerations sections of the NFSv4.0 [RFC7530] and NFSv4.1 [RFC5661] specifications contain special considerations for the handling of GETATTR operations for the fs_locations and fs_locations_info attributes. NSDB nodes and NSDB clients MUST implement support for TLS [RFC5246], as described in [RFC4513]. For all LDAP connections established by the federated file system protocols, the use of TLS is RECOMMENDED. If an NSDB client chooses to follow an LDAP referral, the NSDB client SHOULD authenticate the LDAP referral's target NSDB using the target NSDB's credentials (not the credentials of the NSDB that generated the LDAP referral). The NSDB client SHOULD NOT follow an LDAP referral that targets an NSDB for which it does not know the NSDB's credentials. Within a federation, there are two types of components an attacker may compromise: a fileserver and an NSDB. If an attacker compromises a fileserver, the attacker can interfere with a file-access client's file system input/output (I/O) operations (e.g., by returning fictitious data in the response to a read request) or can fabricate a referral. The attacker's abilities are the same regardless of whether or not the federation protocols are in use. While the federation protocols do not give the attacker additional capabilities, they are additional targets for attack. The LDAP protocol described in Section 5.2 SHOULD be secured using the methods described above to defeat attacks on a fileserver via this channel. If an attacker compromises an NSDB, the attacker will be able to forge FSL information and thus poison the fileserver's referral information. Therefore, an NSDB should be as secure as the fileservers that query it. The LDAP operations described in Section 5 SHOULD be secured using the methods described above to defeat attacks on an NSDB via this channel.
A fileserver binds anonymously when performing NSDB operations. Thus, the contents and distinguished names of FSN and FSL records are required to be readable by anyone who can bind anonymously to an NSDB service. Section 2.12 presents the security considerations in the choice of the type of UUID used in these records. It should be noted that the federation protocols do not directly provide access to file system data. The federation protocols only provide a mechanism for building a namespace. All data transfers occur between a file-access client and fileserver just as they would if the federation protocols were not in use. As a result, the federation protocols do not require new user authentication and authorization mechanisms or require a fileserver to act as a proxy for a client.7. IANA Considerations
7.1. Registry for the fedfsAnnotation Key Namespace
This document defines the fedfsAnnotation key in Section 4.2.1.6. The fedfsAnnotation key namespace is managed by IANA. IANA has created and now maintains a new registry entitled "FedFS Annotation Keys". The location of this registry is under a new heading called "Federated File System (FedFS) Parameters". The URL address is <http://www.iana.org/assignments/fedfs-parameters>. Future registrations are to be administered by IANA using the "First Come First Served" policy defined in [RFC5226]. Registration requests MUST include the key (a valid UTF-8 string of any length), a brief description of the key's purpose, and an email contact for the registration. For viewing, the registry should be sorted lexicographically by key. There are no initial assignments for this registry.7.2. Registry for FedFS Object Identifiers
Using the process described in [RFC2578], one of the authors was assigned the Internet Private Enterprise Numbers range 1.3.6.1.4.1.31103.x. Within this range, the subrange 1.3.6.1.4.1.31103.1.x is permanently dedicated for use by the federated file system protocols. Unassigned OIDs in this range MAY be used for Private Use or Experimental Use as defined in [RFC5226]. New permanent FedFS OID assignments MUST NOT be made using OIDs in this range.
IANA has created and now maintains a new registry entitled "FedFS Object Identifiers" for the purpose of recording the allocations of FedFS Object Identifiers (OIDs) specified by this document. No future allocations in this registry are allowed. The location of this registry is under the heading "Federated File System (FedFS) Parameters", created in Section 7.1. The URL address is <http://www.iana.org/assignments/fedfs-parameters>. For viewing, the registry has been sorted numerically by OID value. The contents of the "FedFS Object Identifiers" registry are given in Table 1. Note: A descriptor designated below as "historic" reserves an OID used in a past version of the NSDB protocol. Registering such OIDs retains compatibility among existing implementations of the NSDB protocol. This document does not otherwise refer to historic OIDs.
+---------------------------+--------------------------+-----------+ | OID | Description | Reference | +---------------------------+--------------------------+-----------+ | 1.3.6.1.4.1.31103.1.1 | fedfsUuid | RFC 7532 | | 1.3.6.1.4.1.31103.1.2 | fedfsNetAddr | historic | | 1.3.6.1.4.1.31103.1.3 | fedfsNetPort | historic | | 1.3.6.1.4.1.31103.1.4 | fedfsFsnUuid | RFC 7532 | | 1.3.6.1.4.1.31103.1.5 | fedfsNsdbName | historic | | 1.3.6.1.4.1.31103.1.6 | fedfsNsdbPort | historic | | 1.3.6.1.4.1.31103.1.7 | fedfsNcePrefix | historic | | 1.3.6.1.4.1.31103.1.8 | fedfsFslUuid | RFC 7532 | | 1.3.6.1.4.1.31103.1.9 | fedfsFslHost | historic | | 1.3.6.1.4.1.31103.1.10 | fedfsFslPort | historic | | 1.3.6.1.4.1.31103.1.11 | fedfsFslTTL | historic | | 1.3.6.1.4.1.31103.1.12 | fedfsAnnotation | RFC 7532 | | 1.3.6.1.4.1.31103.1.13 | fedfsDescr | RFC 7532 | | 1.3.6.1.4.1.31103.1.14 | fedfsNceDN | RFC 7532 | | 1.3.6.1.4.1.31103.1.15 | fedfsFsnTTL | RFC 7532 | | 1.3.6.1.4.1.31103.1.100 | fedfsNfsPath | historic | | 1.3.6.1.4.1.31103.1.101 | fedfsNfsMajorVer | historic | | 1.3.6.1.4.1.31103.1.102 | fedfsNfsMinorVer | historic | | 1.3.6.1.4.1.31103.1.103 | fedfsNfsCurrency | RFC 7532 | | 1.3.6.1.4.1.31103.1.104 | fedfsNfsGenFlagWritable | RFC 7532 | | 1.3.6.1.4.1.31103.1.105 | fedfsNfsGenFlagGoing | RFC 7532 | | 1.3.6.1.4.1.31103.1.106 | fedfsNfsGenFlagSplit | RFC 7532 | | 1.3.6.1.4.1.31103.1.107 | fedfsNfsTransFlagRdma | RFC 7532 | | 1.3.6.1.4.1.31103.1.108 | fedfsNfsClassSimul | RFC 7532 | | 1.3.6.1.4.1.31103.1.109 | fedfsNfsClassHandle | RFC 7532 | | 1.3.6.1.4.1.31103.1.110 | fedfsNfsClassFileid | RFC 7532 | | 1.3.6.1.4.1.31103.1.111 | fedfsNfsClassWritever | RFC 7532 | | 1.3.6.1.4.1.31103.1.112 | fedfsNfsClassChange | RFC 7532 | | 1.3.6.1.4.1.31103.1.113 | fedfsNfsClassReaddir | RFC 7532 | | 1.3.6.1.4.1.31103.1.114 | fedfsNfsReadRank | RFC 7532 | | 1.3.6.1.4.1.31103.1.115 | fedfsNfsReadOrder | RFC 7532 | | 1.3.6.1.4.1.31103.1.116 | fedfsNfsWriteRank | RFC 7532 | | 1.3.6.1.4.1.31103.1.117 | fedfsNfsWriteOrder | RFC 7532 | | 1.3.6.1.4.1.31103.1.118 | fedfsNfsVarSub | RFC 7532 | | 1.3.6.1.4.1.31103.1.119 | fedfsNfsValidFor | RFC 7532 | | 1.3.6.1.4.1.31103.1.120 | fedfsNfsURI | RFC 7532 | | 1.3.6.1.4.1.31103.1.1001 | fedfsNsdbContainerInfo | RFC 7532 | | 1.3.6.1.4.1.31103.1.1002 | fedfsFsn | RFC 7532 | | 1.3.6.1.4.1.31103.1.1003 | fedfsFsl | RFC 7532 | | 1.3.6.1.4.1.31103.1.1004 | fedfsNfsFsl | RFC 7532 | +---------------------------+--------------------------+-----------+ Table 1
7.3. LDAP Descriptor Registration
In accordance with Sections 3.4 and 4 of [RFC4520], the object identifier descriptors defined in this document (listed below) have been registered via the Expert Review process. Subject: Request for LDAP Descriptor Registration Person & email address to contact for further information: See "Author/Change Controller" Specification: RFC 7532 Author/Change Controller: IESG (iesg@ietf.org) Object Identifier: 1.3.6.1.4.1.31103.1.1 Descriptor (short name): fedfsUuid Usage: attribute type Object Identifier: 1.3.6.1.4.1.31103.1.2 Descriptor (short name): fedfsNetAddr Usage: attribute type (historic) Object Identifier: 1.3.6.1.4.1.31103.1.3 Descriptor (short name): fedfsNetPort Usage: attribute type (historic) Object Identifier: 1.3.6.1.4.1.31103.1.4 Descriptor (short name): fedfsFsnUuid Usage: attribute type Object Identifier: 1.3.6.1.4.1.31103.1.5 Descriptor (short name): fedfsNsdbName Usage: attribute type (historic) Object Identifier: 1.3.6.1.4.1.31103.1.6 Descriptor (short name): fedfsNsdbPort Usage: attribute type (historic) Object Identifier: 1.3.6.1.4.1.31103.1.7 Descriptor (short name): fedfsNcePrefix Usage: attribute type (historic) Object Identifier: 1.3.6.1.4.1.31103.1.8 Descriptor (short name): fedfsFslUuid Usage: attribute type Object Identifier: 1.3.6.1.4.1.31103.1.9 Descriptor (short name): fedfsFslHost Usage: attribute type (historic)
Object Identifier: 1.3.6.1.4.1.31103.1.10 Descriptor (short name): fedfsFslPort Usage: attribute type (historic) Object Identifier: 1.3.6.1.4.1.31103.1.11 Descriptor (short name): fedfsFslTTL Usage: attribute type (historic) Object Identifier: 1.3.6.1.4.1.31103.1.12 Descriptor (short name): fedfsAnnotation Usage: attribute type Object Identifier: 1.3.6.1.4.1.31103.1.13 Descriptor (short name): fedfsDescr Usage: attribute type Object Identifier: 1.3.6.1.4.1.31103.1.14 Descriptor (short name): fedfsNceDN Usage: attribute type Object Identifier: 1.3.6.1.4.1.31103.1.15 Descriptor (short name): fedfsFsnTTL Usage: attribute type Object Identifier: 1.3.6.1.4.1.31103.1.100 Descriptor (short name): fedfsNfsPath Usage: attribute type (historic) Object Identifier: 1.3.6.1.4.1.31103.1.101 Descriptor (short name): fedfsNfsMajorVer Usage: attribute type (historic) Object Identifier: 1.3.6.1.4.1.31103.1.102 Descriptor (short name): fedfsNfsMinorVer Usage: attribute type (historic) Object Identifier: 1.3.6.1.4.1.31103.1.103 Descriptor (short name): fedfsNfsCurrency Usage: attribute type Object Identifier: 1.3.6.1.4.1.31103.1.104 Descriptor (short name): fedfsNfsGenFlagWritable Usage: attribute type Object Identifier: 1.3.6.1.4.1.31103.1.105 Descriptor (short name): fedfsNfsGenFlagGoing Usage: attribute type
Object Identifier: 1.3.6.1.4.1.31103.1.106 Descriptor (short name): fedfsNfsGenFlagSplit Usage: attribute type Object Identifier: 1.3.6.1.4.1.31103.1.107 Descriptor (short name): fedfsNfsTransFlagRdma Usage: attribute type Object Identifier: 1.3.6.1.4.1.31103.1.108 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.120 Descriptor (short name): fedfsNfsURI Usage: attribute type Object Identifier: 1.3.6.1.4.1.31103.1.1001 Descriptor (short name): fedfsNsdbContainerInfo Usage: object class Object Identifier: 1.3.6.1.4.1.31103.1.1002 Descriptor (short name): fedfsFsn Usage: object class Object Identifier: 1.3.6.1.4.1.31103.1.1003 Descriptor (short name): fedfsFsl Usage: object class Object Identifier: 1.3.6.1.4.1.31103.1.1004 Descriptor (short name): fedfsNfsFsl Usage: object class8. Glossary
Administrator: A user with the necessary authority to initiate administrative tasks on one or more servers. Admin Entity: A server or agent that administers a collection of fileservers and persistently stores the namespace information. File-Access Client: Standard off-the-shelf, network-attached storage (NAS) client software that communicates with fileservers using a standard file-access protocol. Federation: A set of fileserver collections and singleton fileservers that use a common set of interfaces and protocols in order to provide to file-access clients a federated namespace accessible through a file system access protocol. Fileserver: A server that stores physical fileset data or refers file-access clients to other fileservers. A fileserver provides access to its shared file system data via a file-access protocol.
Fileset: The abstraction of a set of files and the directory tree
that contains them. A fileset is the fundamental unit of data
management in the federation.
Note that all files within a fileset are descendants of one
directory and that filesets do not span file systems.
File System: A self-contained unit of export for a fileserver and
the mechanism used to implement filesets. The fileset does not
need to be rooted at the root of the file system, nor at the
export point for the file system.
A single file system MAY implement more than one fileset, if the
file-access protocol and the fileserver permit this.
File-Access Protocol: A network file system access protocol such as
NFSv3 [RFC1813], NFSv4 [RFC7530], or CIFS (Common Internet File
System) [MS-SMB] [MS-SMB2] [MS-CIFS].
FSL (Fileset Location): The location of the implementation of a
fileset at a particular moment in time. An FSL MUST be something
that can be translated into a protocol-specific description of a
resource that a file-access client can access directly, such as an
fs_locations attribute (for NFSv4) or a share name (for CIFS).
FSN (Fileset Name): A platform-independent and globally unique name
for a fileset. Two FSLs that implement replicas of the same
fileset MUST have the same FSN, and if a fileset is migrated from
one location to another, the FSN of that fileset MUST remain the
same.
Junction: A file system object used to link a directory name in the
current fileset with an object within another fileset. The
server-side "link" from a leaf node in one fileset to the root of
another fileset.
Namespace: A filename/directory tree that a sufficiently authorized
file-access client can observe.
NSDB (Namespace Database) Service: A service that maps FSNs to FSLs.
The NSDB may also be used to store other information, such as
annotations for these mappings and their components.
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
(and related information) that implement a given partition of the
FSNs.
Referral: A server response to a file-access client access that
directs the client to evaluate the current object as a reference
to an object at a different location (specified by an FSL) in
another fileset and possibly hosted on another fileserver. The
client re-attempts the access to the object at the new location.
Replica: A redundant implementation of a fileset. Each replica
shares the same FSN but has a different FSL.
Replicas may be used to increase availability or performance.
Updates to replicas of the same fileset MUST appear to occur in
the same order; therefore, each replica is self-consistent at any
moment.
We do not assume that updates to each replica occur
simultaneously. If a replica is offline or unreachable, the other
replicas may be updated.
Server Collection: A set of fileservers administered as a unit. A
server collection may be administered with vendor-specific
software.
The namespace provided by a server collection could be part of the
federated namespace.
Singleton Server: A server collection containing only one server; a
stand-alone fileserver.
9. References
9.1. Normative References
[RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an
Object Class to Hold Uniform Resource Identifiers (URIs)",
RFC 2079, January 1997,
<http://www.rfc-editor.org/info/rfc2079>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997,
<http://www.rfc-editor.org/info/rfc2203>.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999, <http://www.rfc-editor.org/info/rfc2578>. [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000, <http://www.rfc-editor.org/info/rfc2743>. [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000, <http://www.rfc-editor.org/info/rfc2849>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>. [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006, <http://www.rfc-editor.org/info/rfc4510>. [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006, <http://www.rfc-editor.org/info/rfc4511>. [RFC4512] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006, <http://www.rfc-editor.org/info/rfc4512>. [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006, <http://www.rfc-editor.org/info/rfc4513>. [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006, <http://www.rfc-editor.org/info/rfc4516>.
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006, <http://www.rfc-editor.org/info/rfc4517>. [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006, <http://www.rfc-editor.org/info/rfc4519>. [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006, <http://www.rfc-editor.org/info/rfc4520>. [RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute", RFC 4530, June 2006, <http://www.rfc-editor.org/info/rfc4530>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>. [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010, <http://www.rfc-editor.org/info/rfc5661>. [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, March 2015, <http://www.rfc-editor.org/info/rfc7530>.9.2. Informative References
[AFS] Howard, J., "An Overview of the Andrew File System", Proceedings of the USENIX Winter Technical Conference , 1988. [MS-CIFS] Microsoft Corporation, "Common Internet File System (CIFS) Protocol Specification", MS-CIFS 24.0, May 2014.
[MS-SMB] Microsoft Corporation, "Server Message Block (SMB) Protocol Specification", MS-SMB 43.0, May 2014. [MS-SMB2] Microsoft Corporation, "Server Message Block (SMB) Version 2 Protocol Specification", MS-SMB2 46.0, May 2014. [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995, <http://www.rfc-editor.org/info/rfc1813>. [RFC2224] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997, <http://www.rfc-editor.org/info/rfc2224>. [RFC3254] Alvestrand, H., "Definitions for talking about directories", RFC 3254, April 2002, <http://www.rfc-editor.org/info/rfc3254>. [RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description", RFC 5662, January 2010, <http://www.rfc-editor.org/info/rfc5662>. [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. Naik, "Requirements for Federated File Systems", RFC 5716, January 2010, <http://www.rfc-editor.org/info/rfc5716>. [RFC6641] Everhart, C., Adamson, W., and J. Zhang, "Using DNS SRV to Specify a Global File Namespace with NFS Version 4", RFC 6641, June 2012, <http://www.rfc-editor.org/info/rfc6641>. [RFC7533] Lentini, J., Tewari, R., and C. Lever, Ed., "Administration Protocol for Federated File Systems", RFC 7533, March 2015, <http://www.rfc-editor.org/info/rfc7533>.
Acknowledgments
Daniel Ellard contributed significant parts of this document. The authors and editor would like to thank Craig Everhart and Manoj Naik, who were co-authors of an earlier draft version of this document. In addition, we would like to thank Andy Adamson, Paul Lemahieu, Mario Wurzl, and Robert Thurlow for helping to author this document. We would like to thank George Amvrosiadis, Trond Myklebust, Howard Chu, and Nicolas Williams for their comments and review. The editor gratefully acknowledges the IESG reviewers, whose constructive comments helped make this a much stronger document. Finally, we would like to thank Andy Adamson, Rob Thurlow, and Tom Haynes for helping to get this document out the door. The extract.sh shell script and formatting conventions were first described by the authors of the NFSv4.1 XDR specification [RFC5662].
Authors' Addresses
James Lentini NetApp 1601 Trapelo Rd, Suite 16 Waltham, MA 02451 United States Phone: +1 781-768-5359 EMail: jlentini@netapp.com Renu Tewari IBM Almaden 650 Harry Rd San Jose, CA 95120 United States EMail: tewarir@us.ibm.com Charles Lever (editor) Oracle Corporation 1015 Granger Avenue Ann Arbor, MI 48104 United States Phone: +1 248-614-5091 EMail: chuck.lever@oracle.com