idnits 2.17.1 draft-ietf-nfsv4-federated-fs-protocol-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 24, 2012) is 4354 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 1547 -- Looks like a reference, but probably isn't: '255' on line 1547 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 Working Group J. Lentini 3 Internet-Draft C. Everhart 4 Intended status: Standards Track NetApp 5 Expires: November 25, 2012 D. Ellard 6 Raytheon BBN Technologies 7 R. Tewari 8 M. Naik 9 IBM Almaden 10 May 24, 2012 12 NSDB Protocol for Federated Filesystems 13 draft-ietf-nfsv4-federated-fs-protocol-12 15 Abstract 17 This document describes a filesystem federation protocol that enables 18 file access and namespace traversal across collections of 19 independently administered fileservers. The protocol specifies a set 20 of interfaces by which fileservers with different administrators can 21 form a fileserver federation that provides a namespace composed of 22 the filesystems physically hosted on and exported by the constituent 23 fileservers. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 25, 2012. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 2. Overview of Features and Concepts . . . . . . . . . . . . . . 6 78 2.1. File-access Protocol . . . . . . . . . . . . . . . . . . . 6 79 2.2. File-access Client . . . . . . . . . . . . . . . . . . . . 6 80 2.3. Fileserver . . . . . . . . . . . . . . . . . . . . . . . . 6 81 2.4. Referral . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 2.5. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 6 83 2.6. Fileset . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 2.7. Fileset Name (FSN) . . . . . . . . . . . . . . . . . . . . 7 85 2.8. Fileset Location (FSL) . . . . . . . . . . . . . . . . . . 7 86 2.8.1. Mutual Consistency across Fileset Locations . . . . . 8 87 2.8.2. Caching of Fileset Locations . . . . . . . . . . . . . 9 88 2.8.3. Generating A Referral from Fileset Locations . . . . . 9 89 2.9. Namespace Database (NSDB) . . . . . . . . . . . . . . . . 10 90 2.10. Mount Points, Junctions and Referrals . . . . . . . . . . 11 91 2.11. Unified Namespace and the Root Fileset . . . . . . . . . . 12 92 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 3.1. Creating a Fileset and its FSL(s) . . . . . . . . . . . . 12 94 3.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 13 95 3.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 13 96 3.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 13 97 3.3. Example Use Cases for Fileset Annotations . . . . . . . . 14 98 4. NSDB Configuration and Schema . . . . . . . . . . . . . . . . 15 99 4.1. LDAP Configuration . . . . . . . . . . . . . . . . . . . . 15 100 4.2. LDAP Schema . . . . . . . . . . . . . . . . . . . . . . . 16 101 4.2.1. LDAP Attributes . . . . . . . . . . . . . . . . . . . 19 102 4.2.2. LDAP Objects . . . . . . . . . . . . . . . . . . . . . 37 103 5. NSDB Operations . . . . . . . . . . . . . . . . . . . . . . . 40 104 5.1. NSDB Operations for Administrators . . . . . . . . . . . . 41 105 5.1.1. Create an FSN . . . . . . . . . . . . . . . . . . . . 42 106 5.1.2. Delete an FSN . . . . . . . . . . . . . . . . . . . . 43 107 5.1.3. Create an FSL . . . . . . . . . . . . . . . . . . . . 43 108 5.1.4. Delete an FSL . . . . . . . . . . . . . . . . . . . . 47 109 5.1.5. Update an FSL . . . . . . . . . . . . . . . . . . . . 47 110 5.2. NSDB Operations for Fileservers . . . . . . . . . . . . . 48 111 5.2.1. NSDB Container Entry (NCE) Enumeration . . . . . . . . 48 112 5.2.2. Lookup FSLs for an FSN . . . . . . . . . . . . . . . . 48 113 5.3. NSDB Operations and LDAP Referrals . . . . . . . . . . . . 50 114 6. Security Considerations . . . . . . . . . . . . . . . . . . . 50 115 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 116 7.1. Registry for the fedfsAnnotation Key Namespace . . . . . . 51 117 7.2. Registry for FedFS Object Identifiers . . . . . . . . . . 51 118 7.3. LDAP Descriptor Registration . . . . . . . . . . . . . . . 54 119 8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 120 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 121 9.1. Normative References . . . . . . . . . . . . . . . . . . . 59 122 9.2. Informative References . . . . . . . . . . . . . . . . . . 61 123 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 62 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 126 1. Introduction 128 A federated filesystem enables file access and namespace traversal in 129 a uniform, secure and consistent manner across multiple independent 130 fileservers within an enterprise or across multiple enterprises. 132 This document specifies a set of protocols that allow fileservers, 133 possibly from different vendors and with different administrators, to 134 cooperatively form a federation containing one or more federated 135 filesystems. Each federated filesystem's namespace is composed of 136 the filesystems physically hosted on and exported by the federation's 137 fileservers. A federation MAY contain a common namespace across all 138 its fileservers. A federation MAY project multiple namespaces and 139 enable clients to traverse each one. A federation MAY contain an 140 arbitrary number of namespace repositories, each belonging to a 141 different administrative entity, and each rendering a part of the 142 namespace. A federation MAY also have an arbitrary number of 143 administrative entities responsible for administering disjoint 144 subsets of the fileservers. 146 Traditionally, building a namespace that spans multiple fileservers 147 has been difficult for two reasons. First, the fileservers that 148 export pieces of the namespace are often not in the same 149 administrative domain. Second, there is no standard mechanism for 150 the fileservers to cooperatively present the namespace. Fileservers 151 may provide proprietary management tools and in some cases an 152 administrator may be able to use the proprietary tools to build a 153 shared namespace out of the exported filesystems. However, relying 154 on vendor-specific proprietary tools does not work in larger 155 enterprises or when collaborating across enterprises because the 156 fileservers are likely to be from multiple vendors or use different 157 software versions, each with their own namespace protocols, with no 158 common mechanism to manage the namespace or exchange namespace 159 information. 161 The federated filesystem protocols in this document define how to 162 construct a namespace accessible by an NFSv4 [3530bis] or NFSv4.1 163 [RFC5661] client and have been designed to accommodate other file 164 access protocols in the future. 166 The requirements for federated filesystems are described in 167 [RFC5716]. A protocol for administering a fileserver's namespace is 168 described in [FEDFS-ADMIN]. The mechanism for discovering the root 169 of an NFSv4 namespace is described in [FEDFS-DNS-SRV]. 171 In the rest of the document, the term fileserver denotes a fileserver 172 that is part of a federation. 174 2. Overview of Features and Concepts 176 2.1. File-access Protocol 178 A file-access protocol is a network protocol for accessing data. The 179 NFSv4 protocol and the NFSv4.1 protocol are both examples of a file- 180 access protocol. 182 2.2. File-access Client 184 File-access clients are standard off-the-shelf network attached 185 storage (NAS) clients that communicate with fileservers using the 186 NFSv4 protocol, the NFSv4.1 protocol, or some other file-access 187 protocol. 189 2.3. Fileserver 191 Fileservers are servers that store the physical fileset data or refer 192 the client to other fileservers. A fileserver can be implemented in 193 a number of different ways, including a single system, a cluster of 194 systems, or some other configuration. A fileserver provides access 195 to a federated filesystem via NFSv4, NFSv4.1, or some other file- 196 access protocol. 198 2.4. Referral 200 A referral is a mechanism by which a fileserver redirects a file- 201 access protocol client to a different fileserver. The exact 202 information contained in a referral varies from one file-access 203 protocol to another. The NFSv4 protocol defines the fs_locations 204 attribute for referral information. The NFSv4.1 protocol defines the 205 fs_locations_info attribute for referral information. 207 2.5. Namespace 209 The goal of a unified namespace is to make all managed data available 210 to all clients via the same path in a common filesystem-like 211 namespace. This should be achieved with minimal or zero client 212 configuration. In particular, updates to the common namespace should 213 not require configuration changes at the client. Filesets, which are 214 the unit of data management, are a set of files and directories. 215 From the perspective of the clients, the common namespace is 216 constructed by mounting filesets that are physically located on 217 different fileservers. The namespace, which is defined in terms of 218 fileset definitions, fileset identifiers, the location of each 219 fileset in the namespace, and the physical location of the 220 implementation(s) of each fileset, is stored in a set of namespace 221 repositories, each managed by an administrative entity. The 222 namespace schema defines the model used for populating, modifying, 223 and querying the namespace repositories. It is not required by the 224 federation that the namespace be common across all fileservers. It 225 should be possible to have several independently rooted namespaces. 227 2.6. Fileset 229 A fileset is defined to be a container of data and is the basic unit 230 of data management. Depending on the configuration, they may be 231 anything between an individual directory of an exported filesystem to 232 an entire exported filesystem at a fileserver. 234 2.7. Fileset Name (FSN) 236 A fileset is uniquely represented by its fileset name (FSN). An FSN 237 is considered unique across the federation. After an FSN is created, 238 it is associated with one or more fileset locations (FSLs) on a 239 fileserver. 241 The attributes of an FSN are: 243 NsdbName: the network location of the NSDB node that contains 244 authoritative information for this FSN. 246 FsnUuid: a 128-bit UUID (universally unique identifier), 247 conforming to [RFC4122], that is used to uniquely identify an 248 FSN. 250 2.8. Fileset Location (FSL) 252 An FSL describes the location where the fileset data resides. An FSL 253 contains generic and type specific information which together 254 describe how to access the fileset. An FSL's type indicates which 255 protocol(s) may be used to access its data. An FSL's attributes can 256 be used by a fileserver to decide which locations it will return to a 257 client. 259 All FSLs have the following attributes: 261 FslUuid: a 128-bit UUID, conforming to [RFC4122], that is used to 262 uniquely identify an FSL. 264 FsnUuid: the 128-bit UUID of the FSL's FSN. 266 NsdbName: the network location of the NSDB node that contains 267 authoritative information for this FSL. 269 FslHost: the network location of the host fileserver storing the 270 physical data 272 FslTTL: the time in seconds during which the FSL may be cached 274 Annotations: optional name/value pairs that can be interpreted by 275 a fileserver. The semantics of this field are not defined by 276 this document. These tuples are intended to be used by higher- 277 level protocols. 279 Descriptions: optional text descriptions. The semantics of this 280 field are not defined by this document. 282 This document defines an FSL subtype for NFS. An NFS FSL contains 283 information suitable for use in an NFSv4 fs_locations [3530bis] or 284 NFSv4.1 fs_locations_info attribute [RFC5661]. 286 A fileset MAY be accessible by protocols other than NFS. For each 287 such protocol, a corresponding FSL subtype SHOULD be defined. The 288 contents and format of such FSL subtypes are not defined in this 289 document. 291 2.8.1. Mutual Consistency across Fileset Locations 293 All of the FSLs that have the same FSN (and thereby reference the 294 same fileset) are equivalent from the point of view of client access; 295 the different locations of a fileset represent the same data, though 296 potentially at different points in time. Fileset locations are 297 equivalent but not identical. Locations may either be read-only or 298 read-write. Typically, multiple read-write locations are backed by a 299 clustered filesystem while read-only locations are replicas created 300 by a federation-initiated or external replication operation. Read- 301 only locations may represent consistent point-in-time copies of a 302 read-write location. The federation protocols, however, cannot 303 prevent subsequent changes to a read-only location nor guarantee 304 point-in-time consistency of a read-only location if the read-write 305 location is changing. 307 Regardless of the type, all locations exist at the same mount point 308 in the namespace and, thus, one client may be referred to one 309 location while another is directed to a different location. Since 310 updates to each fileset location are not controlled by the federation 311 protocol, it is the responsibility of administrators to guarantee the 312 functional equivalence of the data. 314 The federation protocol does not guarantee that the different 315 locations are mutually consistent in terms of the currency of the 316 data. It relies on the client file-access protocol (e.g., NFSv4) to 317 contain sufficient information to help the clients determine the 318 currency of the data at each location in order to ensure that the 319 clients do not revert back in time when switching locations. 321 2.8.2. Caching of Fileset Locations 323 To resolve an FSN to a set of FSL records, the fileserver queries the 324 appropriate NSDB for the FSL records. A fileserver MAY cache these 325 FSL records for a limited period of time. The period of time, if 326 any, during which FSL records MAY be cached is indicated by the FSL's 327 TTL field. 329 The combination of FSL caching and FSL migration presents a 330 challenge. For example, suppose there are three fileservers named A, 331 B, and C and fileserver A contains a junction to fileset X stored on 332 fileserver B. Now suppose that fileset X is migrated from fileserver 333 B to fileserver C and the corresponding FSL information for fileset X 334 in the appropriate NSDB is updated. If fileserver A has a cached FSL 335 for fileset X, a user traversing the junction on fileserver A will be 336 referred to fileserver B even though fileset X has migrated to 337 fileserver C. If fileserver A had not cached the FSL record, it would 338 have queried the NSDB and obtained the correct location of fileset X. 340 Administrators are advised to be aware of FSL caching when performing 341 a migration. When migrating a fileset, administrators SHOULD create 342 a junction at the fileset's old location referring back to the NSDB 343 entry for the fileset. This junction will redirect any users who 344 follow stale FSL information to the correct location. Thus, in the 345 above example, fileserver A would direct clients to fileserver B, but 346 fileserver B would in turn direct clients to fileserver C. 348 Such supplemental junctions (on fileserver B in the example) would 349 not be required to be in place forever. They need to stay in place 350 only until cached FSL entries for the target fileset are invalidated. 351 Each FSL contains a TTL field, a count in seconds of the time 352 interval the FSL MAY be cached. This is an upper bound for the 353 lifetime of the cached information and a lower bound for the lifetime 354 of the supplemental junctions. For example, suppose this field 355 contains the value 3600 seconds (one hour). In such a case, 356 administrators MUST keep the supplemental junctions in place for at 357 least one hour after the fileset move has taken place, and FSL data 358 MUST NOT be cached by a referring fileserver for more than one hour 359 without a refresh. 361 2.8.3. Generating A Referral from Fileset Locations 363 After resolving an FSN to a set of FSL records, the fileserver can 364 generate a referral to redirect the client to one or more of the 365 FSLs. The fileserver will convert the FSL records to a referral 366 format understood by the client, such as an NFSv4 fs_locations 367 attribute or NFSv4.1 fs_locations_info attribute. 369 In order to give the client as many options as possible, the 370 fileserver SHOULD include the maximum possible number of FSL records 371 in a referral. However, the fileserver MAY omit some of the FSL 372 records from the referral. For example, the fileserver might omit an 373 FSL record with a different file access protocol from the one in use 374 between the fileserver and client, or the fileserver might omit an 375 FSL record because of limitations in the file access protocol's 376 referral format, or the fileserver might omit an FSL record based on 377 some other criteria. 379 For a given FSL record, the fileserver MAY convert or reduce the FSL 380 record's contents in a manner appropriate to the referral format. 381 For example, an NFS FSL record contains all the data necessary to 382 construct an NFSv4.1 fs_locations_info attribute, but an NFSv4.1 383 fs_locations_info attribute contains several pieces of information 384 that are not found in an NFSv4 fs_locations attribute. A fileserver 385 will construct entries in an NFSv4 fs_locations attribute using the 386 relevant contents of an NFS FSL record. Whenever the fileserver 387 converts or reduces FSL data, the fileserver SHOULD attempt to 388 maintain the original meaning where possible. For example, an NFS 389 FSL record contains the rank and order information that is included 390 in an NFSv4.1 fs_locations_info attribute (see NFSv4.1's 391 FSLI4BX_READRANK, FSLI4BX_READORDER, FSLI4BX_WRITERANK, and 392 FSLI4BX_WRITEORDER). While this rank and order information is not 393 explicitly expressible in an NFSv4 fs_locations attribute, the 394 fileserver can arrange the NFSv4 fs_locations attribute's locations 395 list base on the rank and order values. 397 2.9. Namespace Database (NSDB) 399 The NSDB service is a federation-wide service that provides 400 interfaces to define, update, and query FSN information, FSL 401 information, and FSN to FSL mapping information. An individual 402 repository of namespace information is called an NSDB node. Each 403 NSDB node is managed by a single administrative entity. A single 404 admin entity can manage multiple NSDB nodes. 406 The difference between the NSDB service and an NSDB node is analogous 407 to that between the DNS service and a particular DNS server. 409 Each NSDB node stores the definition of the FSNs for which it is 410 authoritative. It also stores the definitions of the FSLs associated 411 with those FSNs. An NSDB node is authoritative for the filesets that 412 it defines. An NSDB node can cache information from a peer NSDB 413 node. The fileserver can always contact a local NSDB node (if it has 414 been defined) or directly contact any NSDB node to resolve a 415 junction. Each NSDB node supports an LDAP [RFC4510] interface and 416 can be accessed by an LDAP client. 418 An NSDB MAY be replicated throughout the federation. If an NSDB is 419 replicated, the NSDB MUST exhibit loose, converging consistency as 420 defined in [RFC3254]. The mechanism by which this is achieved is 421 outside the scope of this document. Many LDAP implementations 422 support replication. These features MAY be used to replicate the 423 NSDB. 425 2.10. Mount Points, Junctions and Referrals 427 A mount point is a directory in a parent fileset where a target 428 fileset may be attached. If a client traverses the path leading from 429 the root of the namespace to the mount point of a target fileset it 430 should be able to access the data in that target fileset (assuming 431 appropriate permissions). 433 The directory where a fileset is mounted is represented by a junction 434 in the underlying filesystem. In other words, a junction can be 435 viewed as a reference from a directory in one fileset to the root of 436 the target fileset. A junction can be implemented as a special 437 marker on a directory that is interpreted by the fileserver as a 438 mount point, or by some other mechanism in the underlying filesystem. 440 What data is used by the underlying filesystem to represent the 441 junction is not defined by this protocol. The essential property is 442 that the server must be able to find, given the junction, the FSN for 443 the target fileset. The mechanism by which the server maps a 444 junction to an FSN is outside the scope of this document. The FSN 445 (as described earlier) contains the authoritative NSDB node, the 446 optional NSDB search base if one is defined, and the FsnUuid (a UUID 447 for the fileset). 449 When a client traversal reaches a junction, the client is referred to 450 a list of FSLs associated with the FSN targeted by the junction. The 451 client can then redirect its connection to one of the FSLs. This act 452 is called a referral. For NFSv4 and NFSv4.1 clients, the FSL 453 information is returned in the fs_locations and fs_locations_info 454 attributes respectively. 456 The federation protocols do not limit where and how many times a 457 fileset is mounted in the namespace. Filesets can be nested; a 458 fileset can be mounted under another fileset. 460 2.11. Unified Namespace and the Root Fileset 462 The root fileset, when defined, is the top-level fileset of the 463 federation-wide namespace. The root of the unified namespace is the 464 top level directory of this fileset. A set of designated fileservers 465 in the federation can export the root fileset to render the 466 federation-wide unified namespace. When a client mounts the root 467 fileset from any of these designated fileservers it can view a common 468 federation-wide namespace. The root fileset could be implemented 469 either as an exported NFS file system or as data in the NSDB itself. 470 The properties and schema definition of an NSDB-based root fileset 471 and the protocol details that describe how to configure and replicate 472 the root fileset are not defined in this document. 474 3. Examples 476 In this section we provide examples and discussion of the basic 477 operations facilitated by the federated filesystem protocol: creating 478 a fileset, adding a replica of a fileset, resolving a junction, and 479 creating a junction. 481 3.1. Creating a Fileset and its FSL(s) 483 A fileset is the abstraction of a set of files and the directory tree 484 that contains them. The fileset abstraction is the fundamental unit 485 of data management in the federation. This abstraction is 486 implemented by an actual directory tree whose root location is 487 specified by a fileset location (FSL). 489 In this section, we describe the basic requirements for starting with 490 a directory tree and creating a fileset that can be used in the 491 federation protocols. Note that we do not assume that the process of 492 creating a fileset requires any transformation of the files or the 493 directory hierarchy. The only thing that is required by this process 494 is assigning the fileset a fileset name (FSN) and expressing the 495 location of the implementation of the fileset as an FSL. 497 There are many possible variations to this procedure, depending on 498 how the FSN that binds the FSL is created, and whether other replicas 499 of the fileset exist, are known to the federation, and need to be 500 bound to the same FSN. 502 It is easiest to describe this in terms of how to create the initial 503 implementation of the fileset, and then describe how to add replicas. 505 3.1.1. Creating a Fileset and an FSN 507 1. Choose the NSDB node that will keep track of the FSL(s) and 508 related information for the fileset. 510 2. Create an FSN in the NSDB node. 512 The FSN UUID is chosen by the administrator or generated 513 automatically by administration software. The former case is 514 used if the fileset is being restored, perhaps as part of 515 disaster recovery, and the administrator wishes to specify the 516 FSN UUID in order to permit existing junctions that reference 517 that FSN to work again. 519 At this point, the FSN exists, but its fileset locations are 520 unspecified. 522 3. For the FSN created above, create an FSL with the appropriate 523 information in the NSDB node. 525 3.1.2. Adding a Replica of a Fileset 527 Adding a replica is straightforward: the NSDB node and the FSN are 528 already known. The only remaining step is to add another FSL. 530 Note that the federation protocols only provide the mechanisms to 531 register and unregister replicas of a fileset. Fileserver-to- 532 fileserver replication protocols are not defined. 534 3.2. Junction Resolution 536 A fileset may contain references to other filesets. These references 537 are represented by junctions. If a client requests access to a 538 fileset object that is a junction, the fileserver resolves the 539 junction to discover one or more FSLs that implement the referenced 540 fileset. 542 There are many possible variations to this procedure, depending on 543 how the junctions are represented by the fileserver and how the 544 fileserver performs junction resolution. 546 Step 4 is the only step that interacts directly with the federation 547 protocols. The rest of the steps may use platform-specific 548 interfaces. 550 1. The fileserver determines that the object being accessed is a 551 junction. 553 2. The fileserver does a local lookup to find the FSN of the target 554 fileset. 556 3. Using the FSN, the fileserver finds the NSDB node responsible for 557 the target FSN. 559 4. The fileserver contacts that NSDB node and asks for the set of 560 FSLs that implement the target FSN. The NSDB node responds with 561 a (possibly empty) set of FSLs. 563 5. The fileserver converts one or more of the FSLs to the location 564 type used by the client (e.g., a Network File System (NFSv4) 565 fs_location, as described in [3530bis]). 567 6. The fileserver redirects (in whatever manner is appropriate for 568 the client) the client to the location(s). 570 3.3. Example Use Cases for Fileset Annotations 572 Fileset annotations MAY be used to convey additional attributes of a 573 fileset 575 For example, fileset annotations can be used to define relationships 576 between filesets that can be used by an auxiliary replication 577 protocol. Consider the scenario where a fileset is created and 578 mounted at some point in the namespace. A snapshot of the read-write 579 FSL of that fileset is taken periodically at different frequencies 580 say a daily snapshot or a weekly snapshot. The different snapshots 581 are mounted at different locations in the namespace. The daily 582 snapshots are considered as a different fileset from the weekly ones 583 but both are related to the source fileset. For this we can define 584 an annotation labeling the filesets as source and replica. The 585 replication protocol can use this information to copy data from one 586 or more FSLs of the source fileset to all the FSLs of the replica 587 fileset. The replica filesets are read-only while the source fileset 588 is read-write. 590 This follows the traditional Andrew File System (AFS) model of 591 mounting the read-only volume at a path in the namespace different 592 from that of the read-write volume [AFS]. 594 The federation protocol does not control or manage the relationship 595 among filesets. It merely enables annotating the filesets with user- 596 defined relationships. 598 Another potential use for annotations is recording references to an 599 FSN. A single annotation containing the number of references could 600 be defined or multiple annotations, one per reference, could be used 601 to store detailed information on the location of each reference. As 602 with the replication annotation described above, the maintenance of 603 reference information would not be controlled by the federation 604 protocol. The information would mostly likely be non-authoritative 605 because the the ability to create a junction does not require the 606 authority to update the FSN record. In any event, such annotations 607 could be useful to administrators for determining if an FSN is 608 referenced by a junction. 610 4. NSDB Configuration and Schema 612 This section describes how an NSDB is constructed using an LDAP 613 Version 3 [RFC4510] Directory. Section 4.1 describes the basic 614 properties of the LDAP configuration that MUST be used in order to 615 ensure compatibility between different implementations. Section 4.2 616 defines the new LDAP attribute types, the new object types, and 617 specifies how the distinguished name (DN) of each object instance 618 MUST be constructed. 620 4.1. LDAP Configuration 622 An NSDB is constructed using an LDAP Directory. This LDAP Directory 623 MAY have multiple naming contexts. For each naming context, the LDAP 624 Directory's root DSE will have a namingContext attribute. Each 625 namingContext attribute contains the DN of the naming context's root 626 entry. For each naming context that contains federation entries 627 (e.g. FSNs and FSLs): 629 1. There MUST be an LDAP entry that is superior to all of the naming 630 context's federation entries in the Directory Information Tree 631 (DIT) This entry is termed the NSDB Container Entry (NCE). The 632 NCE's children are FSNs. An FSNs children are FSLs. 634 2. The naming context's root entry MUST include the 635 fedfsNsdbContainerInfo (defined below) as one of its object 636 classes. The fedfsNsdbContainerInfo's fedfsNcePrefix attribute 637 is used to locate the naming context's NCE. 639 If a naming context does not contain federation entries, it will not 640 contain an NCE and its root entry will not include a 641 fedfsNsdbContainerInfo as one of its object classes. 643 A fedfsNsdbContainerInfo's fedfsNcePrefix attribute contains a 644 string. Prepending this string to the namingContext value produces 645 the Distinguished Name (DN) of the NSDB Container Entry. An empty 646 fedfsNcePrefix string value indicates that the NSDB Container Entry 647 is the namingContext's root entry. 649 For example, an LDAP directory might have the following entries: 651 -+ [root DSE] 652 | namingContext: o=fedfs 653 | namingContext: dc=example,dc=com 654 | namingContext: ou=system 655 | 656 | 657 +---- [o=fedfs] 658 | fedfsNcePrefix: 659 | 660 | 661 +---- [dc=example,dc=com] 662 | fedfsNcePrefix: ou=fedfs,ou=corp-it 663 | 664 | 665 +---- [ou=system] 667 In this case, the o=fedfs namingContext has an NSBD Container Entry 668 at o=fedfs, the dc=example,dc=com namingContext has an NSDB Container 669 Entry at ou=fedfs,ou=corp-it,dc=example,dc=com, and the ou=system 670 namingContext has no NSDB Container Entry. 672 The NSDB SHOULD be configured with one or more privileged LDAP users. 673 These users are able to modify the contents of the LDAP database. An 674 administrator that performs the operations described in Section 5.1 675 SHOULD authenticate using the DN of a privileged LDAP user. 677 It MUST be possible for an unprivileged (unauthenticated) user to 678 perform LDAP queries that access the NSDB data. A fileserver 679 performs the operations described in Section 5.2 as an unprivileged 680 user. 682 All implementations SHOULD use the same schema, or, at minimum, a 683 schema that includes all of the objects, with each of the attributes, 684 named in the following sections. 686 Given the above configuration guidelines, an NSDB SHOULD be 687 constructed using a dedicated LDAP directory. Separate LDAP 688 directories are RECOMMENDED for other purposes, such as storing user 689 account information. By using an LDAP directory dedicated to storing 690 NSDB records, there is no need to disturb the configuration of any 691 other LDAP directories that store information unrelated to an NSDB. 693 4.2. LDAP Schema 695 The schema definitions provided in this document use the LDAP schema 696 syntax defined in [RFC4512]. The definitions are formatted to allow 697 the reader to easily extract them from the document. The reader can 698 use the following shell script to extract the definitions: 700 702 #!/bin/sh 703 grep '^ *///' | sed 's?^ */// ??' | sed 's?^ *///$??' 705 707 If the above script is stored in a file called "extract.sh", and this 708 document is in a file called "spec.txt", then the reader can do: 710 712 sh extract.sh < spec.txt > fedfs.schema 714 716 The effect of the script is to remove leading white space from each 717 line, plus a sentinel sequence of "///". 719 As stated above, code components extracted from this document must 720 include the following license: 722 723 /// # 724 /// # Copyright (c) 2010 IETF Trust and the persons identified 725 /// # as authors of the code. All rights reserved. 726 /// # 727 /// # The authors of the code are the authors of 728 /// # [draft-ietf-nfsv4-federated-fs-protocol-xx.txt]: J. Lentini, 729 /// # C. Everhart, D. Ellard, R. Tewari, and M. Naik. 730 /// # 731 /// # Redistribution and use in source and binary forms, with 732 /// # or without modification, are permitted provided that the 733 /// # following conditions are met: 734 /// # 735 /// # - Redistributions of source code must retain the above 736 /// # copyright notice, this list of conditions and the 737 /// # following disclaimer. 738 /// # 739 /// # - Redistributions in binary form must reproduce the above 740 /// # copyright notice, this list of conditions and the 741 /// # following disclaimer in the documentation and/or other 742 /// # materials provided with the distribution. 743 /// # 744 /// # - Neither the name of Internet Society, IETF or IETF 745 /// # Trust, nor the names of specific contributors, may be 746 /// # used to endorse or promote products derived from this 747 /// # software without specific prior written permission. 748 /// # 749 /// # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 750 /// # AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED 751 /// # WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 752 /// # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 753 /// # FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO 754 /// # EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE 755 /// # LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 756 /// # EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 757 /// # NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 758 /// # SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 759 /// # INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 760 /// # LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 761 /// # OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING 762 /// # IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF 763 /// # ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 764 /// # 766 768 4.2.1. LDAP Attributes 770 This section describes the required attributes of the NSDB LDAP 771 schema. The following definitions are used below: 773 o The "name" attribute described in [RFC4519]. 775 o The Integer syntax (1.3.6.1.4.1.1466.115.121.1.27) described in 776 [RFC4517]. 778 o The "integerMatch" rule described in [RFC4517]. 780 o The Octet String syntax (1.3.6.1.4.1.1466.115.121.1.40) described 781 in [RFC4517]. 783 o The "octetStringMatch" rule described in [RFC4517]. 785 o The Boolean syntax (1.3.6.1.4.1.1466.115.121.1.7) described in 786 [RFC4517]. 788 o The "booleanMatch" rule described in [RFC4517]. 790 o The "distinguishedNameMatch" rule described in [RFC4517]. 792 o The DN syntax (1.3.6.1.4.1.1466.115.121.1.12) described in 793 [RFC4517]. 795 4.2.1.1. fedfsUuid 797 A fedfsUuid is the base type for all of the universally unique 798 identifiers (UUIDs) used by the federated filesystem protocols. 800 To minimize the probability of two UUIDs colliding, a consistent 801 procedure for generating UUIDs SHOULD be used throughout a 802 federation. Within a federation, UUIDs SHOULD be generated using the 803 procedure described for version 1 of the UUID variant specified in 804 [RFC4122]. This is the time-based UUID variant provided by many UUID 805 programming libraries (e.g., the OSF DCE uuid_generate_time(1) API). 807 The UUID's text representation (as defined in [RFC4122]) SHOULD be 808 encoded as a UTF-8 string. 810 A fedfsUuid is a single-valued LDAP attribute. 812 813 /// 814 /// attributetype ( 815 /// 1.3.6.1.4.1.31103.1.1 NAME 'fedfsUuid' 816 /// DESC 'A UUID used by NSDB' 817 /// SUP name 818 /// SINGLE-VALUE 819 /// ) 820 /// 822 824 4.2.1.2. fedfsNetAddr 826 A fedfsNetAddr is the locative name of a network service in either 827 IPv4, IPv6, or DNS name notation. It MUST be a UTF-8 string and 828 SHOULD be prepared using the server4 rules defined in Chapter 12 829 "Internationalization" of [3530bis]. 831 An IPv4 address MUST be represented using the standard dotted decimal 832 format defined by the IPv4address rule in Section 3.2.2 of RFC 3986 833 [RFC3986]. An IPv6 address MUST be represented using the format 834 defined in Section 2.2 of RFC 4291 [RFC4291]. 836 A DNS name MUST be represented using a fully qualified domain name. 837 A system (i.e. fileserver or administrative host) SHOULD resolve the 838 fully qualified domain name to a network address using the system's 839 standard resolution mechanisms. 841 This attribute is single-valued. 843 845 /// 846 /// attributetype ( 847 /// 1.3.6.1.4.1.31103.1.2 NAME 'fedfsNetAddr' 848 /// DESC 'The network name of a host or service' 849 /// SUP name 850 /// SINGLE-VALUE 851 /// ) 852 /// 854 856 4.2.1.3. fedfsNetPort 858 A fedfsNetPort is the decimal representation of a transport service's 859 port number. A fedfsNetPort MUST be encoded as an Integer syntax 860 value [RFC4517]. 862 This attribute is single-valued. 864 866 /// 867 /// attributetype ( 868 /// 1.3.6.1.4.1.31103.1.3 NAME 'fedfsNetPort' 869 /// DESC 'A transport port number of a service' 870 /// EQUALITY integerMatch 871 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 872 /// SINGLE-VALUE 873 /// ) 874 /// 876 878 4.2.1.4. fedfsFsnUuid 880 A fedfsFsnUuid represents the UUID component of an FSN. An NSDB 881 SHOULD ensure that no two FSNs it stores have the same fedfsFsnUuid. 883 The fedfsFsnUuid is a subclass of fedfsUuid, with the same encoding 884 rules. 886 This attribute is single-valued. 888 890 /// 891 /// attributetype ( 892 /// 1.3.6.1.4.1.31103.1.4 NAME 'fedfsFsnUuid' 893 /// DESC 'The FSN UUID component of an FSN' 894 /// SUP fedfsUuid 895 /// SINGLE-VALUE 896 /// ) 897 /// 899 901 4.2.1.5. fedfsNsdbName 903 A fedfsNsdbName is the NSDB component of an FSN. 905 It MUST be a UTF-8 string containing a DNS name. The DNS name MUST 906 be represented using a fully qualified domain name. A system (i.e. 907 fileserver or administrative host) SHOULD resolve the fully qualified 908 domain name to a network address using the system's standard 909 resolution mechanisms. 911 FSNs are immutable and invariant. The attributes of an FSN, 912 including the fedfsNsdbName, are expected to remain constant. 913 Therefore, a fedfsNsdbName SHOULD NOT contain a network address, such 914 as an IPv4 or IPv6 address, as this would indefinitely assign the 915 network address. 917 This attribute is single-valued. 919 921 /// 922 /// attributetype ( 923 /// 1.3.6.1.4.1.31103.1.5 NAME 'fedfsNsdbName' 924 /// DESC 'The NSDB node component of an FSN' 925 /// SUP name 926 /// SINGLE-VALUE 927 /// ) 928 /// 930 932 4.2.1.6. fedfsNsdbPort 934 A fedfsNsdbPort is the decimal representation of an NSDB's port 935 number. The fedfsNsdbPort attribute is a subclass of fedfsNetPort, 936 with the same encoding rules. 938 This attribute is single-valued. 940 942 /// 943 /// attributetype ( 944 /// 1.3.6.1.4.1.31103.1.6 NAME 'fedfsNsdbPort' 945 /// DESC 'The transport port number of an NSDB' 946 /// SUP fedfsNetPort 947 /// SINGLE-VALUE 948 /// ) 949 /// 951 953 4.2.1.7. fedfsNcePrefix 955 A fedfsNcePrefix stores a distinguished name (DN) prefix. 957 This attribute is single-valued. 959 961 /// 962 /// attributetype ( 963 /// 1.3.6.1.4.1.31103.1.7 NAME 'fedfsNcePrefix' 964 /// DESC 'NCE prefix' 965 /// EQUALITY distinguishedNameMatch 966 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 967 /// SINGLE-VALUE 968 /// ) 969 /// 971 973 OID 1.3.6.1.4.1.1466.115.121.1.12 is the DN syntax [RFC4517]. 975 4.2.1.8. fedfsFslUuid 977 A fedfsFslUuid represents the UUID of an FSL. An NSDB SHOULD ensure 978 that no two FSLs it stores have the same fedfsFslUuid. 980 The fedfsFslUuid attribute is a subclass of fedfsUuid, with the same 981 encoding rules. 983 This attribute is single-valued. 985 987 /// 988 /// attributetype ( 989 /// 1.3.6.1.4.1.31103.1.8 NAME 'fedfsFslUuid' 990 /// DESC 'UUID of an FSL' 991 /// SUP fedfsUuid 992 /// SINGLE-VALUE 993 /// ) 994 /// 996 998 4.2.1.9. fedfsFslHost 1000 A fedfsFslHost is the host component of an FSL. The fedfsFslHost 1001 attribute is a subclass of fedfsNetAddr, with the same encoding 1002 rules. 1004 This attribute is single-valued. 1006 1007 /// 1008 /// attributetype ( 1009 /// 1.3.6.1.4.1.31103.1.9 NAME 'fedfsFslHost' 1010 /// DESC 'Service location for a fileserver' 1011 /// SUP fedfsNetAddr 1012 /// SINGLE-VALUE 1013 /// ) 1014 /// 1016 1018 4.2.1.10. fedfsFslPort 1020 A fedfsFslPort is the decimal representation of a file service's port 1021 number. The fedfsFslPort attribute is a subclass of fedfsNetPort, 1022 with the same encoding rules. 1024 This attribute is single-valued. 1026 1028 /// 1029 /// attributetype ( 1030 /// 1.3.6.1.4.1.31103.1.10 NAME 'fedfsFslPort' 1031 /// DESC 'The file service transport port number' 1032 /// SUP fedfsNetPort 1033 /// SINGLE-VALUE 1034 /// ) 1035 /// 1037 1039 4.2.1.11. fedfsFslTTL 1041 A fedfsFslTTL is the amount of time in seconds an FSL SHOULD be 1042 cached by a fileserver. A fedfsFslTTL MUST be encoded as an Integer 1043 syntax value [RFC4517]. 1045 This attribute is single-valued. 1047 1048 /// 1049 /// attributetype ( 1050 /// 1.3.6.1.4.1.31103.1.11 NAME 'fedfsFslTTL' 1051 /// DESC 'Time to live of an FSL' 1052 /// EQUALITY integerMatch 1053 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1054 /// SINGLE-VALUE 1055 /// ) 1056 /// 1058 1060 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1062 4.2.1.12. fedfsAnnotation 1064 A fedfsAnnotation contains an object annotation formatted as a key/ 1065 value pair. 1067 This attribute is multi-valued; an object type that permits 1068 annotations may have any number of annotations per instance. 1070 A fedfsAnnotation attribute is a human-readable sequence of UTF-8 1071 characters with no non-terminal NUL characters. The value MUST be 1072 formatted according to the following ABNF [RFC5234] rules: 1074 ANNOTATION = KEY EQUALS VALUE 1075 KEY = ITEM 1076 VALUE = ITEM 1077 ITEM = BLANK DQUOTE STR DQUOTE BLANK 1078 BLANK = 0*EMPTY 1079 EMPTY = SPACE / HTAB 1080 HTAB = %x09 ; horizontal tab 1081 STR = 0*UTF8 1083 The DQUOTE, EQUALS, UTF8, and SPACE rules are defined in [RFC4512]. 1085 The following escape sequences are allowed: 1087 +-----------------+-------------+ 1088 | escape sequence | replacement | 1089 +-----------------+-------------+ 1090 | \\ | \ | 1091 | \" | " | 1092 +-----------------+-------------+ 1094 A fedfsAnnotation value SHOULD be processed as follows: 1096 1. Parse the attribute value according to the ANNOTATION rule, 1097 ignoring the escape sequences above. 1099 2. Scan through results of the previous step and replace the escape 1100 sequences above. 1102 A fedfsAnnotation attribute that does not adhere to this format 1103 SHOULD be ignored. 1105 The following are examples of valid fedfsAnnotation attributes: 1107 "key1" = "foo" 1108 "another key" = "x=3" 1109 "key-2" = "A string with \" and \\ characters." 1111 which correspond to the following key/value pairs: 1113 +-------------+-----------------------------------+ 1114 | key | value | 1115 +-------------+-----------------------------------+ 1116 | key1 | foo | 1117 | another key | x=3 | 1118 | key-2 | A string with " and \ characters. | 1119 +-------------+-----------------------------------+ 1121 1123 /// 1124 /// attributetype ( 1125 /// 1.3.6.1.4.1.31103.1.12 NAME 'fedfsAnnotation' 1126 /// DESC 'Annotation of an object' 1127 /// SUP name 1128 /// ) 1129 /// 1131 1133 4.2.1.13. fedfsDescr 1135 A fedfsDescr stores an object description. The description MUST be 1136 encoded as a UTF-8 string. 1138 This attribute is multi-valued which permits any number of 1139 descriptions per entry. 1141 1142 /// 1143 /// attributetype ( 1144 /// 1.3.6.1.4.1.31103.1.13 NAME 'fedfsDescr' 1145 /// DESC 'Description of an object' 1146 /// SUP name 1147 /// ) 1148 /// 1150 1152 4.2.1.14. fedfsNfsPath 1154 A fedfsNfsPath is the path attribute of an FSL. The path MUST be the 1155 XDR encoded NFS path as defined by the NFS pathname4 XDR type of the 1156 fs_location's rootpath [3530bis] and the fs_locations_item's 1157 fli_rootpath [RFC5661]. The NFS pathname4 XDR type is a variable 1158 length array of component4 elements. The NFS component4 XDR type is 1159 a variable length array of opaque data. A fedfsNfsPath attribute's 1160 component4 elements SHOULD be prepared using the component4 rules 1161 defined in Chapter 12 "Internationalization" of [3530bis]. 1163 This attribute is single-valued. 1165 1167 /// 1168 /// attributetype ( 1169 /// 1.3.6.1.4.1.31103.1.100 NAME 'fedfsNfsPath' 1170 /// DESC 'Server-local path to a fileset' 1171 /// EQUALITY octetStringMatch 1172 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 1173 /// SINGLE-VALUE 1174 /// ) 1175 /// 1177 1179 OID 1.3.6.1.4.1.1466.115.121.1.40 is the Octet String syntax 1180 [RFC4517]. 1182 4.2.1.15. fedfsNfsMajorVer 1184 A fedfsNfsMajorVer contains the NFS major version of the associated 1185 NFS FSL. A fedfsNfsMajorVer MUST be encoded as an Integer syntax 1186 value [RFC4517]. 1188 For example if the FSL was exported via NFS 4.1, the contents of this 1189 attribute would be the value 4. 1191 This attribute is single-valued. 1193 1195 /// 1196 /// attributetype ( 1197 /// 1.3.6.1.4.1.31103.1.101 NAME 'fedfsNfsMajorVer' 1198 /// DESC 'NFS major version' 1199 /// EQUALITY integerMatch 1200 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1201 /// SINGLE-VALUE 1202 /// ) 1203 /// 1205 1207 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1209 4.2.1.16. fedfsNfsMinorVer 1211 A fedfsNfsMinorVer contain the NFS minor version of the associated 1212 NFS FSL. A fedfsNfsMinorVer MUST be encoded as an Integer syntax 1213 value [RFC4517]. 1215 For example if the FSL was exported via NFS 4.1, the contents of this 1216 attribute would be the value 1. 1218 This attribute is single-valued. 1220 1222 /// 1223 /// attributetype ( 1224 /// 1.3.6.1.4.1.31103.1.102 NAME 'fedfsNfsMinorVer' 1225 /// DESC 'NFS minor version' 1226 /// EQUALITY integerMatch 1227 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1228 /// SINGLE-VALUE 1229 /// ) 1230 /// 1232 1234 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1236 4.2.1.17. fedfsNfsCurrency 1238 A fedfsNfsCurrency stores the NFSv4.1 fs_locations_server's 1239 fls_currency value [RFC5661]. A fedfsNfsCurrency MUST be encoded as 1240 an Integer syntax value [RFC4517] in the range [-2147483648, 1241 2147483647]. 1243 This attribute is single-valued. 1245 1247 /// 1248 /// attributetype ( 1249 /// 1.3.6.1.4.1.31103.1.103 NAME 'fedfsNfsCurrency' 1250 /// DESC 'up-to-date measure of the data' 1251 /// EQUALITY integerMatch 1252 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1253 /// SINGLE-VALUE 1254 /// ) 1255 /// 1257 1259 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1261 4.2.1.18. fedfsNfsGenFlagWritable 1263 A fedfsNfsGenFlagWritable stores the value of an FSL's NFSv4.1 1264 FSLI4GF_WRITABLE bit [RFC5661]. A value of "TRUE" indicates the bit 1265 is true. A value of "FALSE" indicates the bit is false. 1267 1269 /// 1270 /// attributetype ( 1271 /// 1.3.6.1.4.1.31103.1.104 NAME 'fedfsNfsGenFlagWritable' 1272 /// DESC 'Indicates if the filesystem is writable' 1273 /// EQUALITY booleanMatch 1274 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1275 /// SINGLE-VALUE 1276 /// ) 1277 /// 1279 1281 OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. 1283 4.2.1.19. fedfsNfsGenFlagGoing 1285 A fedfsNfsGenFlagGoing stores the value of an FSL's NFSv4.1 1286 FSLI4GF_GOING bit [RFC5661]. A value of "TRUE" indicates the bit is 1287 true. A value of "FALSE" indicates the bit is false. 1289 1291 /// 1292 /// attributetype ( 1293 /// 1.3.6.1.4.1.31103.1.105 NAME 'fedfsNfsGenFlagGoing' 1294 /// DESC 'Indicates if the filesystem is going' 1295 /// EQUALITY booleanMatch 1296 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1297 /// SINGLE-VALUE 1298 /// ) 1299 /// 1301 1303 OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. 1305 4.2.1.20. fedfsNfsGenFlagSplit 1307 A fedfsNfsGenFlagSplit stores the value of an FSL's NFSv4.1 1308 FSLI4GF_SPLIT bit [RFC5661]. A value of "TRUE" indicates the bit is 1309 true. A value of "FALSE" indicates the bit is false. 1311 1313 /// 1314 /// attributetype ( 1315 /// 1.3.6.1.4.1.31103.1.106 NAME 'fedfsNfsGenFlagSplit' 1316 /// DESC 'Indicates if there are multiple filesystems' 1317 /// EQUALITY booleanMatch 1318 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1319 /// SINGLE-VALUE 1320 /// ) 1321 /// 1323 1325 OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. 1327 4.2.1.21. fedfsNfsTransFlagRdma 1329 A fedfsNfsTransFlagRdma stores the value of an FSL's NFSv4.1 1330 FSLI4TF_RDMA bit [RFC5661]. A value of "TRUE" indicates the bit is 1331 true. A value of "FALSE" indicates the bit is false. 1333 1335 /// 1336 /// attributetype ( 1337 /// 1.3.6.1.4.1.31103.1.107 NAME 'fedfsNfsTransFlagRdma' 1338 /// DESC 'Indicates if the transport supports RDMA' 1339 /// EQUALITY booleanMatch 1340 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1341 /// SINGLE-VALUE 1342 /// ) 1343 /// 1345 1347 OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. 1349 4.2.1.22. fedfsNfsClassSimul 1351 A fedfsNfsClassSimul contains the FSL's NFSv4.1 FSLI4BX_CLSIMUL 1352 [RFC5661] value. A fedfsNfsClassSimul MUST be encoded as an Integer 1353 syntax value [RFC4517] in the range [0, 255]. 1355 1357 /// 1358 /// attributetype ( 1359 /// 1.3.6.1.4.1.31103.1.108 NAME 'fedfsNfsClassSimul' 1360 /// DESC 'The simultaneous-use class of the filesystem' 1361 /// EQUALITY integerMatch 1362 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1363 /// SINGLE-VALUE 1364 /// ) 1365 /// 1367 1369 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1371 4.2.1.23. fedfsNfsClassHandle 1373 A fedfsNfsClassHandle contains the FSL's NFSv4.1 FSLI4BX_CLHANDLE 1374 [RFC5661] value. A fedfsNfsClassHandle MUST be encoded as an Integer 1375 syntax value [RFC4517] in the range [0, 255]. 1377 1378 /// 1379 /// attributetype ( 1380 /// 1.3.6.1.4.1.31103.1.109 NAME 'fedfsNfsClassHandle' 1381 /// DESC 'The handle class of the filesystem' 1382 /// EQUALITY integerMatch 1383 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1384 /// SINGLE-VALUE 1385 /// ) 1386 /// 1388 1390 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1392 4.2.1.24. fedfsNfsClassFileid 1394 A fedfsNfsClassFileid contains the FSL's NFSv4.1 FSLI4BX_CLFILEID 1395 [RFC5661] value. A fedfsNfsClassFileid MUST be encoded as an Integer 1396 syntax value [RFC4517] in the range [0, 255]. 1398 1400 /// 1401 /// attributetype ( 1402 /// 1.3.6.1.4.1.31103.1.110 NAME 'fedfsNfsClassFileid' 1403 /// DESC 'The fileid class of the filesystem' 1404 /// EQUALITY integerMatch 1405 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1406 /// SINGLE-VALUE 1407 /// ) 1408 /// 1410 1412 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1414 4.2.1.25. fedfsNfsClassWritever 1416 A fedfsNfsClassWritever contains the FSL's NFSv4.1 FSLI4BX_CLWRITEVER 1417 [RFC5661] value. A fedfsNfsClassWritever MUST be encoded as an 1418 Integer syntax value [RFC4517] in the range [0, 255]. 1420 1421 /// 1422 /// attributetype ( 1423 /// 1.3.6.1.4.1.31103.1.111 NAME 'fedfsNfsClassWritever' 1424 /// DESC 'The write-verifier class of the filesystem' 1425 /// EQUALITY integerMatch 1426 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1427 /// SINGLE-VALUE 1428 /// ) 1429 /// 1431 1433 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1435 4.2.1.26. fedfsNfsClassChange 1437 A fedfsNfsClassChange contains the FSL's NFSv4.1 FSLI4BX_CLCHANGE 1438 [RFC5661] value. A fedfsNfsClassChange MUST be encoded as an Integer 1439 syntax value [RFC4517] in the range [0, 255]. 1441 1443 /// 1444 /// attributetype ( 1445 /// 1.3.6.1.4.1.31103.1.112 NAME 'fedfsNfsClassChange' 1446 /// DESC 'The change class of the filesystem' 1447 /// EQUALITY integerMatch 1448 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1449 /// SINGLE-VALUE 1450 /// ) 1451 /// 1453 1455 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1457 4.2.1.27. fedfsNfsClassReaddir 1459 A fedfsNfsClassReaddir contains the FSL's NFSv4.1 FSLI4BX_CLREADDIR 1460 [RFC5661] value. A fedfsNfsClassReaddir MUST be encoded as an 1461 Integer syntax value [RFC4517] in the range [0, 255]. 1463 1464 /// 1465 /// attributetype ( 1466 /// 1.3.6.1.4.1.31103.1.113 NAME 'fedfsNfsClassReaddir' 1467 /// DESC 'The readdir class of the filesystem' 1468 /// EQUALITY integerMatch 1469 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1470 /// SINGLE-VALUE 1471 /// ) 1472 /// 1474 1476 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1478 4.2.1.28. fedfsNfsReadRank 1480 A fedfsNfsReadRank contains the FSL's NFSv4.1 FSLI4BX_READRANK 1481 [RFC5661] value. A fedfsNfsReadRank MUST be encoded as an Integer 1482 syntax value [RFC4517] in the range [0, 255]. 1484 1486 /// 1487 /// attributetype ( 1488 /// 1.3.6.1.4.1.31103.1.114 NAME 'fedfsNfsReadRank' 1489 /// DESC 'The read rank of the filesystem' 1490 /// EQUALITY integerMatch 1491 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1492 /// SINGLE-VALUE 1493 /// ) 1494 /// 1496 1498 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1500 4.2.1.29. fedfsNfsReadOrder 1502 A fedfsNfsReadOrder contains the FSL's NFSv4.1 FSLI4BX_READORDER 1503 [RFC5661] value. A fedfsNfsReadOrder MUST be encoded as an Integer 1504 syntax value [RFC4517] in the range [0, 255]. 1506 1507 /// 1508 /// attributetype ( 1509 /// 1.3.6.1.4.1.31103.1.115 NAME 'fedfsNfsReadOrder' 1510 /// DESC 'The read order of the filesystem' 1511 /// EQUALITY integerMatch 1512 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1513 /// SINGLE-VALUE 1514 /// ) 1515 /// 1517 1519 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1521 4.2.1.30. fedfsNfsWriteRank 1523 A fedfsNfsWriteRank contains the FSL's FSLI4BX_WRITERANK [RFC5661] 1524 value. A fedfsNfsWriteRank MUST be encoded as an Integer syntax 1525 value [RFC4517] in the range [0, 255]. 1527 1529 /// 1530 /// attributetype ( 1531 /// 1.3.6.1.4.1.31103.1.116 NAME 'fedfsNfsWriteRank' 1532 /// DESC 'The write rank of the filesystem' 1533 /// EQUALITY integerMatch 1534 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1535 /// SINGLE-VALUE 1536 /// ) 1537 /// 1539 1541 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1543 4.2.1.31. fedfsNfsWriteOrder 1545 A fedfsNfsWriteOrder contains the FSL's FSLI4BX_WRITEORDER [RFC5661] 1546 value. A fedfsNfsWriteOrder MUST be encoded as an Integer syntax 1547 value [RFC4517] in the range [0, 255]. 1549 1550 /// 1551 /// attributetype ( 1552 /// 1.3.6.1.4.1.31103.1.117 NAME 'fedfsNfsWriteOrder' 1553 /// DESC 'The write order of the filesystem' 1554 /// EQUALITY integerMatch 1555 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1556 /// SINGLE-VALUE 1557 /// ) 1558 /// 1560 1562 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1564 4.2.1.32. fedfsNfsVarSub 1566 A fedfsNfsVarSub stores the value of an FSL's NFSv4.1 FSLI4F_VAR_SUB 1567 bit [RFC5661]. A value of "TRUE" indicates the bit is true. A value 1568 of "FALSE" indicates the bit is false. 1570 1572 /// 1573 /// attributetype ( 1574 /// 1.3.6.1.4.1.31103.1.118 NAME 'fedfsNfsVarSub' 1575 /// DESC 'Indicates if variable substitution is present' 1576 /// EQUALITY booleanMatch 1577 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1578 /// SINGLE-VALUE 1579 /// ) 1580 /// 1582 1584 OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. 1586 4.2.1.33. fedfsNfsValidFor 1588 A fedfsNfsValidFor stores an FSL's NFSv4.1 fs_locations_info 1589 fli_valid_for value [RFC5661]. A fedfsNfsValidFor MUST be encoded as 1590 an Integer syntax value [RFC4517] in the range [-2147483648, 1591 2147483647]. 1593 An FSL's fedfsFslTTL value and fedfsNfsValidFor value MAY be 1594 different. 1596 This attribute is single-valued. 1598 1600 /// 1601 /// attributetype ( 1602 /// 1.3.6.1.4.1.31103.1.19 NAME 'fedfsNfsValidFor' 1603 /// DESC 'Valid for time' 1604 /// EQUALITY integerMatch 1605 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1606 /// SINGLE-VALUE 1607 /// ) 1608 /// 1610 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1612 1614 4.2.2. LDAP Objects 1616 4.2.2.1. fedfsNsdbContainerInfo 1618 A fedfsNsdbContainerInfo describes the location of the NCE. 1620 A fedfsFsn's fedfsNcePrefix attribute is REQUIRED. 1622 A fedfsFsn's fedfsAnnotation and fedfsDescr attributes are OPTIONAL. 1624 1626 /// 1627 /// objectclass ( 1628 /// 1.3.6.1.4.1.31103.1.1001 NAME 'fedfsNsdbContainerInfo' 1629 /// DESC 'Describes NCE location' 1630 /// SUP top AUXILIARY 1631 /// MUST ( 1632 /// fedfsNcePrefix 1633 /// ) 1634 /// MAY ( 1635 /// fedfsAnnotation 1636 /// $ fedfsDescr 1637 /// )) 1638 /// 1640 1642 4.2.2.2. fedfsFsn 1644 A fedfsFsn represents an FSN. 1646 A fedfsFsn's fedfsNsdbName and fedfsFsnUuid attributes are REQUIRED. 1648 A fedfsFsn's fedfsNsdbPort, fedfsAnnotation, and fedfsDescr 1649 attributes are OPTIONAL. 1651 If the fedfsNsdbPort is omitted, the standard LDAP port number, 389, 1652 SHOULD be assumed. 1654 The DN of an FSN is REQUIRED to take the following form: 1655 "fedfsFsnUuid=$FSNUUID,$NCE", where $FSNUUID is the UUID of the FSN 1656 and $NCE is the DN of the NCE ("o=fedfs" by default). Since LDAP 1657 requires a DN to be unique, this ensures that each FSN entry has a 1658 unique UUID value within the LDAP directory. 1660 A fedfsFsn MAY also have additional attributes, but these attributes 1661 MUST NOT be referenced by any part of this document. 1663 1665 /// 1666 /// objectclass ( 1667 /// 1.3.6.1.4.1.31103.1.1002 NAME 'fedfsFsn' 1668 /// DESC 'Represents a fileset' 1669 /// SUP top STRUCTURAL 1670 /// MUST ( 1671 /// fedfsFsnUuid 1672 /// $ fedfsNsdbName 1673 /// ) 1674 /// MAY ( 1675 /// fedfsNsdbPort 1676 /// $ fedfsAnnotation 1677 /// $ fedfsDescr 1678 /// )) 1679 /// 1681 1683 4.2.2.3. fedfsFsl 1685 The fedfsFsl object class represents an FSL. 1687 The fedfsFsl is an abstract object class. Protocol specific subtypes 1688 of this object class are used to store FSL information. The 1689 fedfsNfsFsl object class defined below is used to record an NFS FSL's 1690 location. Other subtypes MAY be defined for other protocols (e.g. 1691 CIFS). 1693 A fedfsFsl's fedfsFslUuid, fedfsFsnUuid, fedfsNsdbName, fedfsFslHost, 1694 and fedfsFslTTL attributes are REQUIRED. 1696 A fedfsFsl's fedfsNsdbPort, fedfsFslPort, fedfsAnnotation, and 1697 fedfsDescr attributes are OPTIONAL. 1699 If the fedfsNsdbPort is omitted, the standard LDAP port number, 389, 1700 SHOULD be assumed. 1702 If the fedfsFslPort is omitted, a standard port number based on the 1703 type of FSL should be assumed. For an NFS FSL, the standard NFS port 1704 number, 2049, SHOULD be assumed. 1706 The DN of an FSL is REQUIRED to take the following form: 1707 "fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE" where $FSLUUID is 1708 the FSL's UUID, $FSNUUID is the FSN's UUID, and $NCE is the DN of the 1709 NCE ("o=fedfs" by default). Since LDAP requires a DN to be unique, 1710 this ensures that each FSL entry has a unique UUID value within the 1711 LDAP directory. 1713 1715 /// 1716 /// objectclass ( 1717 /// 1.3.6.1.4.1.31103.1.1003 NAME 'fedfsFsl' 1718 /// DESC 'A physical location of a fileset' 1719 /// SUP top ABSTRACT 1720 /// MUST ( 1721 /// fedfsFslUuid 1722 /// $ fedfsFsnUuid 1723 /// $ fedfsNsdbName 1724 /// $ fedfsFslHost 1725 /// $ fedfsFslTTL 1726 /// ) 1727 /// MAY ( 1728 /// fedfsNsdbPort 1729 /// $ fedfsFslPort 1730 /// $ fedfsAnnotation 1731 /// $ fedfsDescr 1732 /// )) 1733 /// 1735 1737 4.2.2.4. fedfsNfsFsl 1739 A fedfsNfsFsl is used to represent an NFS FSL. The fedfsNfsFsl 1740 inherits all of the attributes of the fedfsFsl and extends the 1741 fedfsFsl with information specific to the NFS protocol. 1743 The DN of an NFS FSL is REQUIRED to take the following form: 1744 "fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE" where $FSLUUID is 1745 the FSL's UUID, $FSNUUID is the FSN's UUID, and $NCE is the DN of the 1746 NCE ("o=fedfs" by default). Since LDAP requires a DN to be unique, 1747 this ensures that each NFS FSL entry has a unique UUID value within 1748 the LDAP directory. 1750 1752 /// 1753 /// objectclass ( 1754 /// 1.3.6.1.4.1.31103.1.1004 NAME 'fedfsNfsFsl' 1755 /// DESC 'An NFS location of a fileset' 1756 /// SUP fedfsFsl STRUCTURAL 1757 /// MUST ( 1758 /// fedfsNfsPath 1759 /// $ fedfsNfsMajorVer 1760 /// $ fedfsNfsMinorVer 1761 /// $ fedfsNfsCurrency 1762 /// $ fedfsNfsGenFlagWritable 1763 /// $ fedfsNfsGenFlagGoing 1764 /// $ fedfsNfsGenFlagSplit 1765 /// $ fedfsNfsTransFlagRdma 1766 /// $ fedfsNfsClassSimul 1767 /// $ fedfsNfsClassHandle 1768 /// $ fedfsNfsClassFileid 1769 /// $ fedfsNfsClassWritever 1770 /// $ fedfsNfsClassChange 1771 /// $ fedfsNfsClassReaddir 1772 /// $ fedfsNfsReadRank 1773 /// $ fedfsNfsReadOrder 1774 /// $ fedfsNfsWriteRank 1775 /// $ fedfsNfsWriteOrder 1776 /// $ fedfsNfsVarSub 1777 /// $ fedfsNfsValidFor 1778 /// )) 1779 /// 1781 1783 5. NSDB Operations 1785 The operations defined by the protocol can be described as several 1786 sub-protocols that are used by entities within the federation to 1787 perform different roles. 1789 The first of these sub-protocols defines how the state of an NSDB 1790 node can be initialized and updated. The primary use of this sub- 1791 protocol is by an administrator to add, edit, or delete filesets, 1792 their properties, and their fileset locations. 1794 The second of these sub-protocols defines the queries that are sent 1795 to an NSDB node in order to perform resolution (or to find other 1796 information about the data stored within that NSDB node) and the 1797 responses returned by the NSDB node. The primary use of this sub- 1798 protocol is by a fileserver in order to perform resolution, but it 1799 may also be used by an administrator to query the state of the 1800 system. 1802 The first and second sub-protocols are defined as LDAP operations, 1803 using the schema defined in the previous section. If each NSDB node 1804 is a standard LDAP server, then, in theory, it is unnecessary to 1805 describe the LDAP operations in detail, because the operations are 1806 ordinary LDAP operations to query and update records. However, we do 1807 not require that an NSDB node implement a complete LDAP service, and 1808 therefore we define in these sections the minimum level of LDAP 1809 functionality required to implement an NSDB node. 1811 The NSDB sub-protocols are defined in the next two sub-sections. The 1812 descriptions of LDAP messages in these sections use the LDAP Data 1813 Interchange Format (LDIF) [RFC2849]. In order to differentiate 1814 constant and variable strings in the LDIF specifications, variables 1815 are prefixed by a $ character and use all upper case characters. For 1816 example, a variable named FOO would be specified as $FOO. 1818 This document uses the term NSDB client to refer to an LDAP client 1819 that uses either of the NSDB sub-protocols 1821 The third sub-protocol defines the queries and other requests that 1822 are sent to a fileserver in order to get information from it or to 1823 modify the state of the fileserver in a manner related to the 1824 federation protocols. The primary purpose of this protocol is for an 1825 administrator to create or delete a junction or discover related 1826 information about a particular fileserver. 1828 The third sub-protocol is defined as an ONC RPC protocols. The 1829 reason for using ONC RPC instead of LDAP is that all fileservers 1830 support ONC RPC but some do not support an LDAP Directory server. 1832 The ONC RPC administration protocol is defined in [FEDFS-ADMIN]. 1834 5.1. NSDB Operations for Administrators 1836 The admin entity initiates and controls the commands to manage 1837 fileset and namespace information. The admin entity, however, is 1838 stateless. All state is maintained at the NSDB nodes or at the 1839 fileserver. 1841 We require that each NSDB node be able to act as an LDAP server and 1842 that the protocol used for communicating between the admin entity and 1843 each NSDB node is LDAP. 1845 The names we assign to these operations are entirely for the purpose 1846 of exposition in this document, and are not part of the LDAP dialogs. 1848 5.1.1. Create an FSN 1850 This operation creates a new FSN in the NSDB by adding a new fedfsFsn 1851 entry in the NSDB's LDAP directory. 1853 A fedfsFsn entry contains a fedfsFsnUuid and fedfsNsdbName. The 1854 administrator chooses the fedfsFsnUuid and fedfsNsdbName. The 1855 process for choosing the fedfsFsnUuid is described in 1856 Section 4.2.1.1). The fedfsNsdbName is the name of the NSDB node 1857 that will serve as the source of definitive information about the FSN 1858 for the life of the FSN. 1860 The NSDB node that receives the request SHOULD check that 1861 fedfsNsdbName value matches its own value and return an error if it 1862 does not. This is to ensure that an FSN is always created by the 1863 NSDB node encoded within the FSN as its owner. 1865 The NSDB node that receives the request SHOULD check all of the 1866 attributes for validity and consistency, but this is not generally 1867 possible for LDAP servers because the consistency requirements cannot 1868 be expressed in the LDAP schema (although many LDAP servers can be 1869 extended, via plug-ins or other mechanisms, to add functionality 1870 beyond the strict definition of LDAP). 1872 5.1.1.1. LDAP Request 1874 This operation is implemented using the LDAP ADD request described by 1875 the LDIF below. 1877 dn: fedfsFsnUuid=$FSNUUID,$NCE 1878 changeType: add 1879 objectClass: fedfsFsn 1880 fedfsFsnUuid: $FSNUUID 1881 fedfsNsdbName: $NSDBNAME 1883 For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- 1884 00a0c91e6bf6", the $NSDBNAME is "nsdb.example.com", and the $NCE is 1885 "o=fedfs" the operation would be: 1887 dn: fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 1888 changeType: add 1889 objectClass: fedfsFsn 1890 fedfsFsnUuid: f81d4fae-7dec-11d0-a765-00a0c91e6bf6 1891 fedfsNsdbName: nsdb.example.com 1893 5.1.2. Delete an FSN 1895 This operation deletes an FSN by removing a fedfsFsn entry in the 1896 NSDB's LDAP directory. 1898 If the FSN entry being deleted has child FSL entries, this function 1899 MUST return an error. This ensures that the NSDB will not contain 1900 any orphaned FSL entries. A compliant LDAP implementation will meet 1901 this requirement since Section 4.8 of [RFC4511] defines the LDAP 1902 delete operation to only be capable of removing leaf entries. 1904 Note that the FSN delete function only removes the fileset from the 1905 namespace (by removing the records for that FSN from the NSDB node 1906 that receives this request). The fileset and its data are not 1907 deleted. Any junction that has this FSN as its target may continue 1908 to point to this non-existent FSN. A dangling reference may be 1909 detected when a client tries to resolve the target of a junction that 1910 refers to the deleted FSN and the NSDB returns an error. 1912 5.1.2.1. LDAP Request 1914 This operation is implemented using the LDAP DELETE request described 1915 by the LDIF below. 1917 dn: fedfsFsnUuid=$FSNUUID,$NCE 1918 changeType: delete 1920 For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- 1921 00a0c91e6bf6" and $NCE is "o=fedfs", the operation would be: 1923 dn: fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 1924 changeType: delete 1926 5.1.3. Create an FSL 1928 This operation creates a new FSL for the given FSN by adding a new 1929 fedfsFsl entry in the NSDB's LDAP directory. 1931 A fedfsFsl entry contains a fedfsFslUuid, fedfsFsnUuid, 1932 fedfsNsdbName, fedfsFslHost, and fedfsFslTTL. The administrator 1933 chooses the fedfsFslUuid. The process for choosing the fedfsFslUuid 1934 is described in Section 4.2.1.1. The fedfsFsnUuid is the UUID of the 1935 FSL's FSN. The fedfsNsdbName is the name of the NSDB node that 1936 stores definitive information about the FSL's FSN. The fedfsFslHost 1937 value is the network location of the fileserver that stores the FSL. 1938 The fedfsFslTTL is chosen by the administrator as described in 1939 Section 2.8.2. 1941 The administrator will also set additional attributes depending on 1942 the FSL type. 1944 5.1.3.1. LDAP Request 1946 This operation is implemented using the LDAP ADD request described by 1947 the LDIF below (NOTE: the LDIF shows the creation of an NFS FSL) 1949 dn:fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE 1950 changeType: add 1951 objectClass: fedfsNfsFsl 1952 fedfsFslUuid: $FSLUUID 1953 fedfsFsnUuid: $FSNUUID 1954 fedfsNsdbName: $NSDBNAME 1955 fedfsFslHost: $HOST 1956 fedfsFslPort: $PORT 1957 fedfsFslTTL: $TTL 1958 fedfsNfsPath: $PATH 1959 fedfsNfsMajorVer: $MAJOR 1960 fedfsNfsMinorVer: $MINOR 1961 fedfsNfsCurrency: $CURRENCY 1962 fedfsNfsGenFlagWritable: $WRITABLE 1963 fedfsNfsGenFlagGoing: $GOING 1964 fedfsNfsGenFlagSplit: $SPLIT 1965 fedfsNfsTransFlagRdma: $RDMA 1966 fedfsNfsClassSimul: $CLASS_SIMUL 1967 fedfsNfsClassHandle:$CLASS_HANDLE 1968 fedfsNfsClassFileid:$CLASS_FILEID 1969 fedfsNfsClassWritever:$CLASS_WRITEVER 1970 fedfsNfsClassChange: $CLASS_CHANGE 1971 fedfsNfsClassReaddir: $CLASS_READDIR 1972 fedfsNfsReadRank: $READ_RANK 1973 fedfsNfsReadOrder: $READ_ORDER 1974 fedfsNfsWriteRank: $WRITE_RANK 1975 fedfsNfsWriteOrder: $WRITE_ORDER 1976 fedfsNfsVarSub: $VAR_SUB 1977 fedfsNfsValidFor: $TIME 1978 fedfsAnnotation: $ANNOTATION 1979 fedfsDescr: $DESCR 1981 For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- 1982 00a0c91e6bf6", the $FSLUUID is "84f775a7-8e31-14ae-b39d- 1983 10eeee060d2c", the $NSDBNAME is "nsdb.example.com", the $HOST is 1984 "server.example.com", $PORT is "2049", the $TTL is "300" seconds, the 1985 $PATH is stored in the file "/tmp/fsl_path", fileset is exported via 1986 NFSv4.1 ($MAJOR is "4" and $MINOR is "1"), $CURRENCY is "0" (an up to 1987 date copy), the FSL is writable, but not going, split, or accessible 1988 via RDMA, the simultaneous-use class is "1", the handle class is "0", 1989 the fileid class is "1", the write-verifier class is "1", the change 1990 class is "1", the readdir class is "9", the read rank is "7", the 1991 read order is "8", the write rank is "5", the write order is "6", 1992 variable substitution is false, $TIME is "300" seconds, $ANNOTATION 1993 is ""foo" = "bar"", $DESC is "This is a description.", and the $NCE 1994 is "o=fedfs", the operation would be (for readability the DN is split 1995 into two lines): 1997 dn:fedfsFslUuid=84f775a7-8e31-14ae-b39d-10eeee060d2c, 1998 fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 1999 changeType: add 2000 objectClass: fedfsNfsFsl 2001 fedfsFslUuid: 84f775a7-8e31-14ae-b39d-10eeee060d2c 2002 fedfsFsnUuid: f81d4fae-7dec-11d0-a765-00a0c91e6bf6 2003 fedfsNsdbName: nsdb.example.com 2004 fedfsFslHost: server.example.com 2005 fedfsFslPort: 2049 2006 fedfsFslTTL: 300 2007 fedfsNfsPath:< file:///tmp/fsl_path 2008 fedfsNfsMajorVer: 4 2009 fedfsNfsMinorVer: 1 2010 fedfsNfsCurrency: 0 2011 fedfsNfsGenFlagWritable: TRUE 2012 fedfsNfsGenFlagGoing: FALSE 2013 fedfsNfsGenFlagSplit: FALSE 2014 fedfsNfsTransFlagRdma: FALSE 2015 fedfsNfsClassSimul: 1 2016 fedfsNfsClassHandle: 0 2017 fedfsNfsClassFileid: 1 2018 fedfsNfsClassWritever: 1 2019 fedfsNfsClassChange: 1 2020 fedfsNfsClassReaddir: 9 2021 fedfsNfsReadRank: 7 2022 fedfsNfsReadOrder: 8 2023 fedfsNfsWriteRank: 5 2024 fedfsNfsWriteOrder: 6 2025 fedfsNfsVarSub: FALSE 2026 fedfsNfsValidFor: 300 2027 fedfsAnnotation: "foo" = "bar" 2028 fedfsDescr: This is a description. 2030 5.1.3.2. Selecting fedfsNfsFsl Values 2032 The fedfsNfsFSl object class is used to describe NFSv4 and NFSv4.1 2033 accessible filesets. For the reasons described in Section 2.8.3, 2034 administrators SHOULD choose reasonable values for all LDAP 2035 attributes of an NFSv4 accessible fedfsNfsFsl even though some of 2036 these LDAP attributes are not explicitly contained in the NFSv4 2037 fs_locations attribute returned to an NFSv4 client. 2039 When the administrator is unable to choose reasonable values for the 2040 LDAP attributes not explicitly contained in a NFSv4 fs_locations 2041 attribute, the values in the following table are RECOMMENDED. 2043 +-------------------------+----------+------------------------------+ 2044 | LDAP attribute | LDAP | Notes | 2045 | | value | | 2046 +-------------------------+----------+------------------------------+ 2047 | fedfsNfsCurrency | negative | Indicates that the server | 2048 | | value | does not know the currency | 2049 | | | (see 11.10.1 of [RFC5661]). | 2050 | fedfsNfsGenFlagWritable | FALSE | Leaving unset is not harmful | 2051 | | | (see 11.10.1 of [RFC5661]). | 2052 | fedfsNfsGenFlagGoing | FALSE | NFS client will detect a | 2053 | | | migration event if the FSL | 2054 | | | becomes unavailable. | 2055 | fedfsNfsGenFlagSplit | TRUE | Safe to assume that the FSL | 2056 | | | is split. | 2057 | fedfsNfsTransFlagRdma | TRUE | NFS client will detect if | 2058 | | | RDMA access is available. | 2059 | fedfsNfsClassSimul | 0 | 0 (zero) is treated as | 2060 | | | non-matching (see 11.10.1 of | 2061 | | | [RFC5661]). | 2062 | fedfsNfsClassHandle | 0 | See fedfsNfsClassSimul note. | 2063 | fedfsNfsClassFileid | 0 | See fedfsNfsClassSimul note. | 2064 | fedfsNfsClassWritever | 0 | See fedfsNfsClassSimul note. | 2065 | fedfsNfsClassChange | 0 | See fedfsNfsClassSimul note. | 2066 | fedfsNfsClassReaddir | 0 | See fedfsNfsClassSimul note. | 2067 | fedfsNfsReadRank | 0 | Highest value ensures FSL | 2068 | | | will be tried. | 2069 | fedfsNfsReadOrder | 0 | See fedfsNfsReadRank note. | 2070 | fedfsNfsWriteRank | 0 | See fedfsNfsReadRank note. | 2071 | fedfsNfsWriteOrder | 0 | See fedfsNfsReadRank note. | 2072 | fedfsNfsVarSub | FALSE | NFSv4 does not define | 2073 | | | variable substituion in | 2074 | | | paths. | 2075 | fedfsNfsValidFor | 0 | Indicates no appropriate | 2076 | | | refetch interval (see | 2077 | | | 11.10.2 of [RFC5661]). | 2078 +-------------------------+----------+------------------------------+ 2080 5.1.4. Delete an FSL 2082 This operation deletes the given Fileset location. The admin 2083 requests the NSDB node storing the fedfsFsl to delete it from its 2084 database. This operation does not result in the fileset location's 2085 data being deleted at the fileserver. 2087 5.1.4.1. LDAP Request 2089 The admin sends an LDAP DELETE request to the NSDB node to remove the 2090 FSL. 2092 dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE 2093 changeType: delete 2095 For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- 2096 00a0c91e6bf6", the $FSLUUID is "84f775a7-8e31-14ae-b39d- 2097 10eeee060d2c", and the $NCE is "o=fedfs", the operation would be (for 2098 readability the DN is split into two lines): 2100 dn: fedfsFslUuid=84f775a7-8e31-14ae-b39d-10eeee060d2c, 2101 fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 2102 changeType: delete 2104 5.1.5. Update an FSL 2106 This operation updates the attributes of a given FSL. This command 2107 results in a change in the attributes of the fedfsFsl at the NSDB 2108 node maintaining this FSL. The attributes that must not change are 2109 the fedfsFslUuid and the fedfsFsnUuid of the fileset this FSL 2110 implements. 2112 5.1.5.1. LDAP Request 2114 The admin sends an LDAP MODIFY request to the NSDB node to update the 2115 FSL. 2117 dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE 2118 changeType: modify 2119 replace: $ATTRIBUTE-TYPE 2121 For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- 2122 00a0c91e6bf6", the $FSLUUID is "84f775a7-8e31-14ae-b39d- 2123 10eeee060d2c", the $NCE is "o=fedfs", and the administrator wished to 2124 change the TTL to 10 minutes, the operation would be (for readability 2125 the DN is split into two lines): 2127 dn: fedfsFslUuid=84f775a7-8e31-14ae-b39d-10eeee060d2c, 2128 fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 2129 changeType: modify 2130 replace: fedfsFslTTL 2131 fedfsFslTTL: 600 2133 5.2. NSDB Operations for Fileservers 2135 5.2.1. NSDB Container Entry (NCE) Enumeration 2137 To find the NCEs for the NSDB foo.example.com, a fileserver would do 2138 the following: 2140 nce_list = empty 2141 connect to the LDAP directory at foo.example.com 2142 for each namingContext value $BAR in the root DSE 2143 /* $BAR is a DN */ 2144 query for a fedfsNcePrefix value at $BAR 2145 /* 2146 * The LDAP URL for this search would be 2147 * 2148 * ldap://foo.example.com:389/$BAR?fedfsNcePrefix?? 2149 * (objectClass=fedfsNsdbContainerInfo) 2150 * 2151 */ 2152 if a fedfsNcePrefix value is found 2153 nce = prepend the fedfsNcePrefix value to $BAR 2154 add nce to the nce_list 2156 5.2.2. Lookup FSLs for an FSN 2158 Using an LDAP search, the fileserver can obtain all of the FSLs for a 2159 given FSN. The FSN's fedfsFsnUuid is used as the search key. The 2160 following examples use the LDAP Universal Resource Identifier (URI) 2161 format defined in [RFC4516]. 2163 To obtain a list of all FSLs for $FSNUUID on the NSDB named 2164 $NSDBNAME, the following search can be used (for readability the URI 2165 is split into two lines): 2167 for each $NCE in nce_list 2168 ldap://$NSDBNAME/fsnUuid=$FSNUUID,$NCE??one? 2169 (objectClass=fedfsFsl) 2171 This search is for the children of the object with DN 2172 "fedfsFsnUuid=$FSNUUID,$NCE" with a filter for 2173 "objectClass=fedfsFsl". The scope value of "one" restricts the 2174 search to the entry's children (rather than the entire subtree below 2175 the entry) and the filter ensures that only FSL entries are returned. 2177 For example if $NSDBNAME is "nsdb.example.com", $FSNUUID is 2178 "f81d4fae-7dec-11d0-a765-00a0c91e6bf6", and $NCE is "o=fedfs", the 2179 search would be (for readability the URI is split into three lines): 2181 ldap://nsdb.example.com/ 2182 fsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 2183 ??one?(objectClass=fedfsFsl) 2185 The following search can be used to obtain only the NFS FSLs for 2186 $FSNUUID on the NSDB named $NSDBNAME (for readability the URI is 2187 split into two lines): 2189 for each $NCE in nce_list 2190 ldap://$NSDBNAME/fsnUuid=$FSNUUID,$NCE??one? 2191 (objectClass=fedfsNfsFsl) 2193 This also searches for the children of the object with DN 2194 "fedfsFsnUuid=$FSNUUID,$NCE", but the filter for "objectClass = 2195 fedfsNfsFsl" restricts the results to only NFS FSLs. 2197 For example if $NSDBNAME is nsdb.example.com, $FSNUUID is f81d4fae- 2198 7dec-11d0-a765-00a0c91e6bf6, and $NCE is "o=fedfs",the search would 2199 be (for readability the URI is split into three lines): 2201 ldap://nsdb.example.com/ 2202 fsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 2203 ??one?(objectClass=fedfsNfsFsl) 2205 The fileserver will generate a referral based on the set of FSLs 2206 returned by these queries using the process described in 2207 Section 2.8.3. 2209 5.3. NSDB Operations and LDAP Referrals 2211 The LDAPv3 protocol defines an LDAP referral mechanism that allows an 2212 LDAP server to redirect an LDAP client. LDAPv3 defines two types of 2213 LDAP referrals: the Referral type defined in Section 4.1.10 of 2214 [RFC4511] and the SearchResultReference type defined in Section 4.5.3 2215 of [RFC4511]. In both cases, the LDAP referral lists one or more 2216 URIs for services that can be used to complete the operation. In the 2217 remainder of this document, the term LDAP referral is used to 2218 indicate either of these types. 2220 If an NSDB operation results in an LDAP referral, the NSDB client MAY 2221 follow the LDAP referral. An NSDB client's decision to follow an 2222 LDAP referral is implementation and configuration dependent. For 2223 example, an NSDB client might be configured to follow only those LDAP 2224 referrals that were received over a secure channel, or only those 2225 that target an NSDB that supports encrypted communication. If an 2226 NSDB client chooses to follow an LDAP referral, the NSDB client MUST 2227 process the LDAP referral and prevent looping as described in Section 2228 4.1.10 of [RFC4511]. 2230 6. Security Considerations 2232 Both NFSv4/NFSv4.1 and LDAP provide security mechanisms. When used 2233 in conjunction with the federated filesystem protocols described in 2234 this document, the use of these mechanisms is RECOMMENDED. 2235 Specifically, the use of RPCSEC_GSS [RFC2203], which is built on the 2236 GSS-API [RFC2743], is RECOMMENDED on all NFS connections between a 2237 client and fileserver. The "Security Considerations" sections of the 2238 the NFSv4 [3530bis] and NFSv4.1 [RFC5661] specifications contain 2239 special considerations for the handling of GETATTR operations for the 2240 fs_locations and fs_locations_info attributes. For all LDAP 2241 connections established by the federated filesystem protocols, the 2242 use of TLS [RFC5246], as described in [RFC4513], is RECOMMENDED. 2244 If an NSDB client chooses to follow an LDAP referral, the NSDB client 2245 SHOULD authenticate the LDAP referral's target NSDB using the target 2246 NSDB's credentials (not the credentials of the NSDB that generated 2247 the LDAP referral). The NSDB client SHOULD NOT follow an LDAP 2248 referral that targets an NSDB for which it does not know the NSDB's 2249 credentials. 2251 Within a federation, there are two types of components an attacker 2252 may compromise: a fileserver and an NSDB. 2254 If an attacker compromises a fileserver, the attacker can interfere 2255 with the client's filesystem I/O operations (e.g. by returning 2256 fictitious data in the response to a read request) or fabricating a 2257 referral. The attacker's abilities are the same regardless of 2258 whether or not the federation protocols are in use. While the 2259 federation protocols do not give the attacker additional 2260 capabilities, they are additional targets for attack. The LDAP 2261 protocol described in Section 5.2 SHOULD be secured using the methods 2262 described above to defeat attacks on a fileserver via this channel. 2264 If an attacker compromises an NSDB, the attacker will be able to 2265 forge FSL information and thus poison the fileserver's referral 2266 information. Therefore an NSDB should be as secure as the 2267 fileservers which query it. The LDAP operations described in 2268 Section 5 SHOULD be secured using the methods described above to 2269 defeat attacks on an NSDB via this channel. 2271 It should be noted that the federation protocols do not directly 2272 provide access to filesystem data. The federation protocols only 2273 provide a mechanism for building a namespace. All data transfers 2274 occur between a client and server just as they would if the 2275 federation protocols were not in use. As a result, the federation 2276 protocols do not require new user authentication and authorization 2277 mechanisms or require a fileserver to act as a proxy for a client. 2279 7. IANA Considerations 2281 7.1. Registry for the fedfsAnnotation Key Namespace 2283 This document defines the fedfsAnnotation key in Section 4.2.1.12. 2284 The fedfsAnnotation key namespace is to be managed by IANA. IANA is 2285 to create and maintain a new registry entitled "FedFS Annotation 2286 Keys". Future registrations are to be administered by IANA using the 2287 "First Come First Served" policy defined in [RFC5226]. Registration 2288 requests MUST include the key (a valid UTF-8 string of any length), a 2289 brief description of the key's purpose, and an email contact for the 2290 registration. For viewing, the registry should be sorted 2291 lexicographically by key. There are no initial assignments for this 2292 registry. 2294 7.2. Registry for FedFS Object Identifiers 2296 Using the process described in [RFC2578], one of the authors was 2297 assigned the Internet Private Enterprise Numbers range 2298 1.3.6.1.4.1.31103.x. Within this range, the subrange 2299 1.3.6.1.4.1.31103.1.x is permanently dedicated for use by the 2300 federated file system protocols. 2302 IANA is to create and maintain a new registry entitled "FedFS Object 2303 Identifiers" for the purpose of administering the FedFS Object 2304 Identifier (OID) range. Future allocations from the 2305 1.3.6.1.4.1.31103.1.x range are to be assigned by IANA using the "RFC 2306 Required" policy defined in [RFC5226]. Registration requests MUST 2307 include an OID value from the 1.3.6.1.4.1.31103.1.x range, a short 2308 description of the OID, and a reference to the specification that 2309 defines the OID's usage. For viewing, the registry should be sorted 2310 numerically by OID value. The initial contents of the FedFS Object 2311 Identifiers registry are given in Table 1. 2313 +--------------------------+-------------------------+-----------+ 2314 | OID | Description | Reference | 2315 +--------------------------+-------------------------+-----------+ 2316 | 1.3.6.1.4.1.31103.1.1 | fedfsUuid | RFC-TBD1 | 2317 | 1.3.6.1.4.1.31103.1.2 | fedfsNetAddr | RFC-TBD1 | 2318 | 1.3.6.1.4.1.31103.1.3 | fedfsNetPort | RFC-TBD1 | 2319 | 1.3.6.1.4.1.31103.1.4 | fedfsFsnUuid | RFC-TBD1 | 2320 | 1.3.6.1.4.1.31103.1.5 | fedfsNsdbName | RFC-TBD1 | 2321 | 1.3.6.1.4.1.31103.1.6 | fedfsNsdbPort | RFC-TBD1 | 2322 | 1.3.6.1.4.1.31103.1.7 | fedfsNcePrefix | RFC-TBD1 | 2323 | 1.3.6.1.4.1.31103.1.8 | fedfsFslUuid | RFC-TBD1 | 2324 | 1.3.6.1.4.1.31103.1.9 | fedfsFslHost | RFC-TBD1 | 2325 | 1.3.6.1.4.1.31103.1.10 | fedfsFslPort | RFC-TBD1 | 2326 | 1.3.6.1.4.1.31103.1.11 | fedfsFslTTL | RFC-TBD1 | 2327 | 1.3.6.1.4.1.31103.1.12 | fedfsAnnotation | RFC-TBD1 | 2328 | 1.3.6.1.4.1.31103.1.13 | fedfsDescr | RFC-TBD1 | 2329 | 1.3.6.1.4.1.31103.1.100 | fedfsNfsPath | RFC-TBD1 | 2330 | 1.3.6.1.4.1.31103.1.101 | fedfsNfsMajorVer | RFC-TBD1 | 2331 | 1.3.6.1.4.1.31103.1.102 | fedfsNfsMinorVer | RFC-TBD1 | 2332 | 1.3.6.1.4.1.31103.1.103 | fedfsNfsCurrency | RFC-TBD1 | 2333 | 1.3.6.1.4.1.31103.1.104 | fedfsNfsGenFlagWritable | RFC-TBD1 | 2334 | 1.3.6.1.4.1.31103.1.105 | fedfsNfsGenFlagGoing | RFC-TBD1 | 2335 | 1.3.6.1.4.1.31103.1.106 | fedfsNfsGenFlagSplit | RFC-TBD1 | 2336 | 1.3.6.1.4.1.31103.1.107 | fedfsNfsTransFlagRdma | RFC-TBD1 | 2337 | 1.3.6.1.4.1.31103.1.108 | fedfsNfsClassSimul | RFC-TBD1 | 2338 | 1.3.6.1.4.1.31103.1.109 | fedfsNfsClassHandle | RFC-TBD1 | 2339 | 1.3.6.1.4.1.31103.1.110 | fedfsNfsClassFileid | RFC-TBD1 | 2340 | 1.3.6.1.4.1.31103.1.111 | fedfsNfsClassWritever | RFC-TBD1 | 2341 | 1.3.6.1.4.1.31103.1.112 | fedfsNfsClassChange | RFC-TBD1 | 2342 | 1.3.6.1.4.1.31103.1.113 | fedfsNfsClassReaddir | RFC-TBD1 | 2343 | 1.3.6.1.4.1.31103.1.114 | fedfsNfsReadRank | RFC-TBD1 | 2344 | 1.3.6.1.4.1.31103.1.115 | fedfsNfsReadOrder | RFC-TBD1 | 2345 | 1.3.6.1.4.1.31103.1.116 | fedfsNfsWriteRank | RFC-TBD1 | 2346 | 1.3.6.1.4.1.31103.1.117 | fedfsNfsWriteOrder | RFC-TBD1 | 2347 | 1.3.6.1.4.1.31103.1.118 | fedfsNfsVarSub | RFC-TBD1 | 2348 | 1.3.6.1.4.1.31103.1.119 | fedfsNfsValidFor | RFC-TBD1 | 2349 | 1.3.6.1.4.1.31103.1.1001 | fedfsNsdbContainerInfo | RFC-TBD1 | 2350 | 1.3.6.1.4.1.31103.1.1002 | fedfsFsn | RFC-TBD1 | 2351 | 1.3.6.1.4.1.31103.1.1003 | fedfsFsl | RFC-TBD1 | 2352 | 1.3.6.1.4.1.31103.1.1004 | fedfsNfsFsl | RFC-TBD1 | 2353 +--------------------------+-------------------------+-----------+ 2355 Table 1 2357 7.3. LDAP Descriptor Registration 2359 In accordance with Section 3.4 and Section 4 of [RFC4520], the object 2360 identifier descriptors defined in this document (listed below) will 2361 be registered via the Expert Review process. 2363 Subject: Request for LDAP Descriptor Registration 2364 Person & email address to contact for further information: See 2365 "Author/Change Controller" 2366 Specification: draft-ietf-nfsv4-federated-fs-protocol 2367 Author/Change Controller: [document authors] 2369 Object Identifier: 1.3.6.1.4.1.31103.1.1 2370 Descriptor (short name): fedfsUuid 2371 Usage: attribute type 2373 Object Identifier: 1.3.6.1.4.1.31103.1.2 2374 Descriptor (short name): fedfsNetAddr 2375 Usage: attribute type 2377 Object Identifier: 1.3.6.1.4.1.31103.1.3 2378 Descriptor (short name): fedfsNetPort 2379 Usage: attribute type 2381 Object Identifier: 1.3.6.1.4.1.31103.1.4 2382 Descriptor (short name): fedfsFsnUuid 2383 Usage: attribute type 2385 Object Identifier: 1.3.6.1.4.1.31103.1.5 2386 Descriptor (short name): fedfsNsdbName 2387 Usage: attribute type 2389 Object Identifier: 1.3.6.1.4.1.31103.1.6 2390 Descriptor (short name): fedfsNsdbPort 2391 Usage: attribute type 2393 Object Identifier: 1.3.6.1.4.1.31103.1.7 2394 Descriptor (short name): fedfsNcePrefix 2395 Usage: attribute type 2397 Object Identifier: 1.3.6.1.4.1.31103.1.8 2398 Descriptor (short name): fedfsFslUuid 2399 Usage: attribute type 2400 Object Identifier: 1.3.6.1.4.1.31103.1.9 2401 Descriptor (short name): fedfsFslHost 2402 Usage: attribute type 2404 Object Identifier: 1.3.6.1.4.1.31103.1.10 2405 Descriptor (short name): fedfsFslPort 2406 Usage: attribute type 2408 Object Identifier: 1.3.6.1.4.1.31103.1.11 2409 Descriptor (short name): fedfsFslTTL 2410 Usage: attribute type 2412 Object Identifier: 1.3.6.1.4.1.31103.1.12 2413 Descriptor (short name): fedfsAnnotation 2414 Usage: attribute type 2416 Object Identifier: 1.3.6.1.4.1.31103.1.13 2417 Descriptor (short name): fedfsDescr 2418 Usage: attribute type 2420 Object Identifier: 1.3.6.1.4.1.31103.1.100 2421 Descriptor (short name): fedfsNfsPath 2422 Usage: attribute type 2424 Object Identifier: 1.3.6.1.4.1.31103.1.101 2425 Descriptor (short name): fedfsNfsMajorVer 2426 Usage: attribute type 2428 Object Identifier: 1.3.6.1.4.1.31103.1.102 2429 Descriptor (short name): fedfsNfsMinorVer 2430 Usage: attribute type 2432 Object Identifier: 1.3.6.1.4.1.31103.1.103 2433 Descriptor (short name): fedfsNfsCurrency 2434 Usage: attribute type 2436 Object Identifier: 1.3.6.1.4.1.31103.1.104 2437 Descriptor (short name): fedfsNfsGenFlagWritable 2438 Usage: attribute type 2440 Object Identifier: 1.3.6.1.4.1.31103.1.105 2441 Descriptor (short name): fedfsNfsGenFlagGoing 2442 Usage: attribute type 2443 Object Identifier: 1.3.6.1.4.1.31103.1.106 2444 Descriptor (short name): fedfsNfsGenFlagSplit 2445 Usage: attribute type 2447 Object Identifier: 1.3.6.1.4.1.31103.1.107 2448 Descriptor (short name): fedfsNfsTransFlagRdma 2449 Usage: attribute type 2451 Object Identifier: 1.3.6.1.4.1.31103.1.108 2452 Descriptor (short name): fedfsNfsClassSimul 2453 Usage: attribute type 2455 Object Identifier: 1.3.6.1.4.1.31103.1.109 2456 Descriptor (short name): fedfsNfsClassHandle 2457 Usage: attribute type 2459 Object Identifier: 1.3.6.1.4.1.31103.1.110 2460 Descriptor (short name): fedfsNfsClassFileid 2461 Usage: attribute type 2463 Object Identifier: 1.3.6.1.4.1.31103.1.111 2464 Descriptor (short name): fedfsNfsClassWritever 2465 Usage: attribute type 2467 Object Identifier: 1.3.6.1.4.1.31103.1.112 2468 Descriptor (short name): fedfsNfsClassChange 2469 Usage: attribute type 2471 Object Identifier: 1.3.6.1.4.1.31103.1.113 2472 Descriptor (short name): fedfsNfsClassReaddir 2473 Usage: attribute type 2475 Object Identifier: 1.3.6.1.4.1.31103.1.114 2476 Descriptor (short name): fedfsNfsReadRank 2477 Usage: attribute type 2479 Object Identifier: 1.3.6.1.4.1.31103.1.115 2480 Descriptor (short name): fedfsNfsReadOrder 2481 Usage: attribute type 2483 Object Identifier: 1.3.6.1.4.1.31103.1.116 2484 Descriptor (short name): fedfsNfsWriteRank 2485 Usage: attribute type 2486 Object Identifier: 1.3.6.1.4.1.31103.1.117 2487 Descriptor (short name): fedfsNfsWriteOrder 2488 Usage: attribute type 2490 Object Identifier: 1.3.6.1.4.1.31103.1.118 2491 Descriptor (short name): fedfsNfsVarSub 2492 Usage: attribute type 2494 Object Identifier: 1.3.6.1.4.1.31103.1.119 2495 Descriptor (short name): fedfsNfsValidFor 2496 Usage: attribute type 2498 Object Identifier: 1.3.6.1.4.1.31103.1.1001 2499 Descriptor (short name): fedfsNsdbContainerInfo 2500 Usage: object class 2502 Object Identifier: 1.3.6.1.4.1.31103.1.1002 2503 Descriptor (short name): fedfsFsn 2504 Usage: object class 2506 Object Identifier: 1.3.6.1.4.1.31103.1.1003 2507 Descriptor (short name): fedfsFsl 2508 Usage: object class 2510 Object Identifier: 1.3.6.1.4.1.31103.1.1004 2511 Descriptor (short name): fedfsNfsFsl 2512 Usage: object class 2514 8. Glossary 2516 Administrator: user with the necessary authority to initiate 2517 administrative tasks on one or more servers. 2519 Admin Entity: A server or agent that administers a collection of 2520 fileservers and persistently stores the namespace information. 2522 Client: Any client that accesses the fileserver data using a 2523 supported filesystem access protocol. 2525 Federation: A set of server collections and singleton servers that 2526 use a common set of interfaces and protocols in order to provide 2527 to their clients a federated namespace accessible through a 2528 filesystem access protocol. 2530 Fileserver: A server exporting a filesystem via a network filesystem 2531 access protocol. 2533 Fileset: The abstraction of a set of files and the directory tree 2534 that contains them. A fileset is the fundamental unit of data 2535 management in the federation. 2537 Note that all files within a fileset are descendants of one 2538 directory, and that filesets do not span filesystems. 2540 Filesystem: A self-contained unit of export for a fileserver, and 2541 the mechanism used to implement filesets. The fileset does not 2542 need to be rooted at the root of the filesystem, nor at the export 2543 point for the filesystem. 2545 A single filesystem MAY implement more than one fileset, if the 2546 client protocol and the fileserver permit this. 2548 Filesystem Access Protocol: A network filesystem access protocol 2549 such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [3530bis], or CIFS 2550 (Common Internet File System) [MS-SMB] [MS-SMB2] [MS-CIFS]. 2552 FSL (Fileset Location): The location of the implementation of a 2553 fileset at a particular moment in time. An FSL MUST be something 2554 that can be translated into a protocol-specific description of a 2555 resource that a client can access directly, such as an fs_location 2556 (for NFSv4), or share name (for CIFS). Note that not all FSLs 2557 need to be explicitly exported as long as they are contained 2558 within an exported path on the fileserver. 2560 FSN (Fileset Name): A platform-independent and globally unique name 2561 for a fileset. Two FSLs that implement replicas of the same 2562 fileset MUST have the same FSN, and if a fileset is migrated from 2563 one location to another, the FSN of that fileset MUST remain the 2564 same. 2566 Junction: A filesystem object used to link a directory name in the 2567 current fileset with an object within another fileset. The 2568 server-side "link" from a leaf node in one fileset to the root of 2569 another fileset. 2571 Namespace: A filename/directory tree that a sufficiently authorized 2572 client can observe. 2574 NSDB (Namespace Database) Service: A service that maps FSNs to FSLs. 2575 The NSDB may also be used to store other information, such as 2576 annotations for these mappings and their components. 2578 NSDB Node: The name or location of a server that implements part of 2579 the NSDB service and is responsible for keeping track of the FSLs 2580 (and related info) that implement a given partition of the FSNs. 2582 Referral: A server response to a client access that directs the 2583 client to evaluate the current object as a reference to an object 2584 at a different location (specified by an FSL) in another fileset, 2585 and possibly hosted on another fileserver. The client re-attempts 2586 the access to the object at the new location. 2588 Replica: A replica is a redundant implementation of a fileset. Each 2589 replica shares the same FSN, but has a different FSL. 2591 Replicas may be used to increase availability or performance. 2592 Updates to replicas of the same fileset MUST appear to occur in 2593 the same order, and therefore each replica is self-consistent at 2594 any moment. 2596 We do not assume that updates to each replica occur 2597 simultaneously. If a replica is offline or unreachable, the other 2598 replicas may be updated. 2600 Server Collection: A set of fileservers administered as a unit. A 2601 server collection may be administered with vendor-specific 2602 software. 2604 The namespace provided by a server collection could be part of the 2605 federated namespace. 2607 Singleton Server: A server collection containing only one server; a 2608 stand-alone fileserver. 2610 9. References 2612 9.1. Normative References 2614 [3530bis] Haynes, T. and D. Noveck, "NFS Version 4 Protocol", 2615 draft-ietf-nfsv4-rfc3530bis (Work In Progress), 2010. 2617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2618 Requirement Levels", BCP 14, RFC 2119, March 1997. 2620 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 2621 Specification", RFC 2203, September 1997. 2623 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 2624 Schoenwaelder, Ed., "Structure of Management Information 2625 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 2627 [RFC2743] Linn, J., "Generic Security Service Application Program 2628 Interface Version 2, Update 1", RFC 2743, January 2000. 2630 [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - 2631 Technical Specification", RFC 2849, June 2000. 2633 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2634 Resource Identifier (URI): Generic Syntax", STD 66, 2635 RFC 3986, January 2005. 2637 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2638 Unique IDentifier (UUID) URN Namespace", RFC 4122, 2639 July 2005. 2641 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2642 Architecture", RFC 4291, February 2006. 2644 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 2645 (LDAP): Technical Specification Road Map", RFC 4510, 2646 June 2006. 2648 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 2649 (LDAP): The Protocol", RFC 4511, June 2006. 2651 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 2652 (LDAP): Directory Information Models", RFC 4512, 2653 June 2006. 2655 [RFC4513] Harrison, R., "Lightweight Directory Access Protocol 2656 (LDAP): Authentication Methods and Security Mechanisms", 2657 RFC 4513, June 2006. 2659 [RFC4516] Smith, M. and T. Howes, "Lightweight Directory Access 2660 Protocol (LDAP): Uniform Resource Locator", RFC 4516, 2661 June 2006. 2663 [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): 2664 Syntaxes and Matching Rules", RFC 4517, June 2006. 2666 [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol 2667 (LDAP): Schema for User Applications", RFC 4519, 2668 June 2006. 2670 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 2671 Considerations for the Lightweight Directory Access 2672 Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 2674 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2675 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2676 May 2008. 2678 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2679 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2681 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2682 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2684 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 2685 System (NFS) Version 4 Minor Version 1 Protocol", 2686 RFC 5661, January 2010. 2688 9.2. Informative References 2690 [AFS] Howard, J., "An Overview of the Andrew File System", 2691 Proceeding of the USENIX Winter Technical Conference , 2692 1988. 2694 [FEDFS-ADMIN] 2695 Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. 2696 Naik, "Administration Protocol for Federated Filesystems", 2697 draft-ietf-nfsv4-federated-fs-admin (Work In Progress), 2698 2010. 2700 [FEDFS-DNS-SRV] 2701 Everhart, C., Adamson, W., and J. Zhang, "Using DNS SRV to 2702 Specify a Global File Name Space with NFS version 4", 2703 draft-ietf-nfsv4-federated-fs-dns-srv-namespace (Work In 2704 Progress), 2010. 2706 [MS-CIFS] Microsoft Corporation, "Common Internet File System (CIFS) 2707 Protocol Specification", MS-CIFS 2.0, November 2009. 2709 [MS-SMB] Microsoft Corporation, "Server Message Block (SMB) 2710 Protocol Specification", MS-SMB 17.0, November 2009. 2712 [MS-SMB2] Microsoft Corporation, "Server Message Block (SMB) Version 2713 2 Protocol Specification", MS-SMB2 19.0, November 2009. 2715 [RFC1094] Nowicki, B., "NFS: Network File System Protocol 2716 specification", RFC 1094, March 1989. 2718 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 2719 Version 3 Protocol Specification", RFC 1813, June 1995. 2721 [RFC3254] Alvestrand, H., "Definitions for talking about 2722 directories", RFC 3254, April 2002. 2724 [RFC5662] Shepler, S., Eisler, M., and D. Noveck, "Network File 2725 System (NFS) Version 4 Minor Version 1 External Data 2726 Representation Standard (XDR) Description", RFC 5662, 2727 January 2010. 2729 [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. 2730 Naik, "Requirements for Federated File Systems", RFC 5716, 2731 January 2010. 2733 Appendix A. Acknowledgments 2735 We would like to thank Andy Adamson of NetApp, Paul Lemahieu of EMC, 2736 Robert Thurlow of Sun Microsystems, and Mario Wurzl of EMC for 2737 helping to author this document. 2739 We would also like to thank George Amvrosiadis, Chuck Lever, Trond 2740 Myklebust, and Nicolas Williams for their comments. 2742 The extract.sh shell script and formatting conventions were first 2743 described by the authors of the NFSv4.1 XDR specification [RFC5662]. 2745 Authors' Addresses 2747 James Lentini 2748 NetApp 2749 1601 Trapelo Rd, Suite 16 2750 Waltham, MA 02451 2751 US 2753 Phone: +1 781-768-5359 2754 Email: jlentini@netapp.com 2756 Craig Everhart 2757 NetApp 2758 800 Cranberry Woods Drive 2759 Cranberry Township, PA 16066 2760 US 2762 Phone: +1 724-741-5101 2763 Email: Craig.Everhart@netapp.com 2764 Daniel Ellard 2765 Raytheon BBN Technologies 2766 10 Moulton Street 2767 Cambridge, MA 02138 2768 US 2770 Phone: +1 617-873-8004 2771 Email: dellard@bbn.com 2773 Renu Tewari 2774 IBM Almaden 2775 650 Harry Rd 2776 San Jose, CA 95120 2777 US 2779 Email: tewarir@us.ibm.com 2781 Manoj Naik 2782 IBM Almaden 2783 650 Harry Rd 2784 San Jose, CA 95120 2785 US 2787 Email: manoj@almaden.ibm.com