idnits 2.17.1 draft-ietf-nfsv4-federated-fs-protocol-10.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 (November 19, 2010) is 4904 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 1545 -- Looks like a reference, but probably isn't: '255' on line 1545 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) Summary: 2 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: May 23, 2011 D. Ellard 6 Raytheon BBN Technologies 7 R. Tewari 8 M. Naik 9 IBM Almaden 10 November 19, 2010 12 NSDB Protocol for Federated Filesystems 13 draft-ietf-nfsv4-federated-fs-protocol-10 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 May 23, 2011. 48 Copyright Notice 49 Copyright (c) 2010 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. LDAP Descriptor Registration . . . . . . . . . . . . . . . 51 117 8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 118 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 119 9.1. Normative References . . . . . . . . . . . . . . . . . . . 57 120 9.2. Informative References . . . . . . . . . . . . . . . . . . 59 121 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 60 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 124 1. Introduction 126 A federated filesystem enables file access and namespace traversal in 127 a uniform, secure and consistent manner across multiple independent 128 fileservers within an enterprise or across multiple enterprises. 130 This document specifies a set of protocols that allow fileservers, 131 possibly from different vendors and with different administrators, to 132 cooperatively form a federation containing one or more federated 133 filesystems. Each federated filesystem's namespace is composed of 134 the filesystems physically hosted on and exported by the federation's 135 fileservers. A federation MAY contain a common namespace across all 136 its fileservers. A federation MAY project multiple namespaces and 137 enable clients to traverse each one. A federation MAY contain an 138 arbitrary number of namespace repositories, each belonging to a 139 different administrative entity, and each rendering a part of the 140 namespace. A federation MAY also have an arbitrary number of 141 administrative entities responsible for administering disjoint 142 subsets of the fileservers. 144 Traditionally, building a namespace that spans multiple fileservers 145 has been difficult for two reasons. First, the fileservers that 146 export pieces of the namespace are often not in the same 147 administrative domain. Second, there is no standard mechanism for 148 the fileservers to cooperatively present the namespace. Fileservers 149 may provide proprietary management tools and in some cases an 150 administrator may be able to use the proprietary tools to build a 151 shared namespace out of the exported filesystems. However, relying 152 on vendor-specific proprietary tools does not work in larger 153 enterprises or when collaborating across enterprises because the 154 fileservers are likely to be from multiple vendors or use different 155 software versions, each with their own namespace protocols, with no 156 common mechanism to manage the namespace or exchange namespace 157 information. 159 The federated filesystem protocols in this document define how to 160 construct a namespace accessible by an NFSv4 [3530bis] or NFSv4.1 161 [RFC5661] client and have been designed to accommodate other file 162 access protocols in the future. 164 The requirements for federated filesystems are described in 165 [RFC5716]. A protocol for administering a fileserver's namespace is 166 described in [FEDFS-ADMIN]. The mechanism for discovering the root 167 of an NFSv4 namespace is described in [FEDFS-DNS-SRV]. 169 In the rest of the document, the term fileserver denotes a fileserver 170 that is part of a federation. 172 2. Overview of Features and Concepts 174 2.1. File-access Protocol 176 A file-access protocol is a network protocol for accessing data. The 177 NFSv4 protocol and the NFSv4.1 protocol are both examples of a file- 178 access protocol. 180 2.2. File-access Client 182 File-access clients are standard off-the-shelf network attached 183 storage (NAS) clients that communicate with fileservers using the 184 NFSv4 protocol, the NFSv4.1 protocol, or some other file-access 185 protocol. 187 2.3. Fileserver 189 Fileservers are servers that store the physical fileset data or refer 190 the client to other fileservers. A fileserver can be implemented in 191 a number of different ways, including a single system, a cluster of 192 systems, or some other configuration. A fileserver provides access 193 to a federated filesystem via NFSv4, NFSv4.1, or some other file- 194 access protocol. 196 2.4. Referral 198 A referral is a mechanism by which a fileserver redirects a file- 199 access protocol client to a different fileserver. The exact 200 information contained in a referral varies from one file-access 201 protocol to another. The NFSv4 protocol defines the fs_locations 202 attribute for referral information. The NFSv4.1 protocol defines the 203 fs_locations_info attribute for referral information. 205 2.5. Namespace 207 The goal of a unified namespace is to make all managed data available 208 to all clients via the same path in a common filesystem-like 209 namespace. This should be achieved with minimal or zero client 210 configuration. In particular, updates to the common namespace should 211 not require configuration changes at the client. Filesets, which are 212 the unit of data management, are a set of files and directories. 213 From the perspective of the clients, the common namespace is 214 constructed by mounting filesets that are physically located on 215 different fileservers. The namespace, which is defined in terms of 216 fileset definitions, fileset identifiers, the location of each 217 fileset in the namespace, and the physical location of the 218 implementation(s) of each fileset, is stored in a set of namespace 219 repositories, each managed by an administrative entity. The 220 namespace schema defines the model used for populating, modifying, 221 and querying the namespace repositories. It is not required by the 222 federation that the namespace be common across all fileservers. It 223 should be possible to have several independently rooted namespaces. 225 2.6. Fileset 227 A fileset is defined to be a container of data and is the basic unit 228 of data management. Depending on the configuration, they may be 229 anything between an individual directory of an exported filesystem to 230 an entire exported filesystem at a fileserver. 232 2.7. Fileset Name (FSN) 234 A fileset is uniquely represented by its fileset name (FSN). An FSN 235 is considered unique across the federation. After an FSN is created, 236 it is associated with one or more fileset locations (FSLs) on a 237 fileserver. 239 The attributes of an FSN are: 241 NsdbName: the network location of the NSDB node that contains 242 authoritative information for this FSN. 244 FsnUuid: a 128-bit UUID (universally unique identifier), 245 conforming to [RFC4122], that is used to uniquely identify an 246 FSN. 248 2.8. Fileset Location (FSL) 250 An FSL describes the location where the fileset data resides. An FSL 251 contains generic and type specific information which together 252 describe how to access the fileset. An FSL's type indicates which 253 protocol(s) may be used to access its data. An FSL's attributes can 254 be used by a fileserver to decide which locations it will return to a 255 client. 257 All FSLs have the following attributes: 259 FslUuid: a 128-bit UUID, conforming to [RFC4122], that is used to 260 uniquely identify an FSL. 262 FsnUuid: the 128-bit UUID of the FSL's FSN. 264 NsdbName: the network location of the NSDB node that contains 265 authoritative information for this FSL. 267 FslHost: the network location of the host fileserver storing the 268 physical data 270 FslTTL: the time in seconds during which the FSL may be cached 272 Annotations: optional name/value pairs that can be interpreted by 273 a fileserver. The semantics of this field are not defined by 274 this document. These tuples are intended to be used by higher- 275 level protocols. 277 Descriptions: optional text descriptions. The semantics of this 278 field are not defined by this document. 280 This document defines an FSL subtype for NFS. An NFS FSL contains 281 information suitable for use in an NFSv4 fs_locations [3530bis] or 282 NFSv4.1 fs_locations_info attribute [RFC5661]. 284 A fileset MAY be accessible by protocols other than NFS. For each 285 such protocol, a corresponding FSL subtype SHOULD be defined. The 286 contents and format of such FSL subtypes are not defined in this 287 document. 289 2.8.1. Mutual Consistency across Fileset Locations 291 All of the FSLs that have the same FSN (and thereby reference the 292 same fileset) are equivalent from the point of view of client access; 293 the different locations of a fileset represent the same data, though 294 potentially at different points in time. Fileset locations are 295 equivalent but not identical. Locations may either be read-only or 296 read-write. Typically, multiple read-write locations are backed by a 297 clustered filesystem while read-only locations are replicas created 298 by a federation-initiated or external replication operation. Read- 299 only locations may represent consistent point-in-time copies of a 300 read-write location. The federation protocols, however, cannot 301 prevent subsequent changes to a read-only location nor guarantee 302 point-in-time consistency of a read-only location if the read-write 303 location is changing. 305 Regardless of the type, all locations exist at the same mount point 306 in the namespace and, thus, one client may be referred to one 307 location while another is directed to a different location. Since 308 updates to each fileset location are not controlled by the federation 309 protocol, it is the responsibility of administrators to guarantee the 310 functional equivalence of the data. 312 The federation protocol does not guarantee that the different 313 locations are mutually consistent in terms of the currency of the 314 data. It relies on the client file-access protocol (e.g., NFSv4) to 315 contain sufficient information to help the clients determine the 316 currency of the data at each location in order to ensure that the 317 clients do not revert back in time when switching locations. 319 2.8.2. Caching of Fileset Locations 321 To resolve an FSN to a set of FSL records, the fileserver queries the 322 appropriate NSDB for the FSL records. A fileserver MAY cache these 323 FSL records for a limited period of time. The period of time, if 324 any, during which FSL records MAY be cached is indicated by the FSL's 325 TTL field. 327 The combination of FSL caching and FSL migration presents a 328 challenge. For example, suppose there are three fileservers named A, 329 B, and C and fileserver A contains a junction to fileset X stored on 330 fileserver B. Now suppose that fileset X is migrated from fileserver 331 B to fileserver C and the corresponding FSL information for fileset X 332 in the appropriate NSDB is updated. If fileserver A has a cached FSL 333 for fileset X, a user traversing the junction on fileserver A will be 334 referred to fileserver B even though fileset X has migrated to 335 fileserver C. If fileserver A had not cached the FSL record, it would 336 have queried the NSDB and obtained the correct location of fileset X. 338 Administrators are advised to be aware of FSL caching when performing 339 a migration. When migrating a fileset, administrators SHOULD create 340 a junction at the fileset's old location referring back to the NSDB 341 entry for the fileset. This junction will redirect any users who 342 follow stale FSL information to the correct location. Thus, in the 343 above example, fileserver A would direct clients to fileserver B, but 344 fileserver B would in turn direct clients to fileserver C. 346 Such supplemental junctions (on fileserver B in the example) would 347 not be required to be in place forever. They need to stay in place 348 only until cached FSL entries for the target fileset are invalidated. 349 Each FSL contains a TTL field, a count in seconds of the time 350 interval the FSL MAY be cached. This is an upper bound for the 351 lifetime of the cached information and a lower bound for the lifetime 352 of the supplemental junctions. For example, suppose this field 353 contains the value 3600 seconds (one hour). In such a case, 354 administrators MUST keep the supplemental junctions in place for at 355 least one hour after the fileset move has taken place, and FSL data 356 MUST NOT be cached by a referring fileserver for more than one hour 357 without a refresh. 359 2.8.3. Generating A Referral from Fileset Locations 361 After resolving an FSN to a set of FSL records, the fileserver can 362 generate a referral to redirect the client to one or more of the 363 FSLs. The fileserver will convert the FSL records to a referral 364 format understood by the client, such as an NFSv4 fs_locations 365 attribute or NFSv4.1 fs_locations_info attribute. 367 In order to give the client as many options as possible, the 368 fileserver SHOULD include the maximum possible number of FSL records 369 in a referral. However, the fileserver MAY omit some of the FSL 370 records from the referral. For example, the fileserver might omit an 371 FSL record with a different file access protocol from the one in use 372 between the fileserver and client, or the fileserver might omit an 373 FSL record because of limitations in the file access protocol's 374 referral format, or the fileserver might omit an FSL record based on 375 some other criteria. 377 For a given FSL record, the fileserver MAY convert or reduce the FSL 378 record's contents in a manner appropriate to the referral format. 379 For example, an NFS FSL record contains all the data necessary to 380 construct an NFSv4.1 fs_locations_info attribute, but an NFSv4.1 381 fs_locations_info attribute contains several pieces of information 382 that are not found in an NFSv4 fs_locations attribute. A fileserver 383 will construct entries in an NFSv4 fs_locations attribute using the 384 relevant contents of an NFS FSL record. Whenever the fileserver 385 converts or reduces FSL data, the fileserver SHOULD attempt to 386 maintain the original meaning where possible. For example, an NFS 387 FSL record contains the rank and order information that is included 388 in an NFSv4.1 fs_locations_info attribute (see NFSv4.1's 389 FSLI4BX_READRANK, FSLI4BX_READORDER, FSLI4BX_WRITERANK, and 390 FSLI4BX_WRITEORDER). While this rank and order information is not 391 explicitly expressible in an NFSv4 fs_locations attribute, the 392 fileserver can arrange the NFSv4 fs_locations attribute's locations 393 list base on the rank and order values. 395 2.9. Namespace Database (NSDB) 397 The NSDB service is a federation-wide service that provides 398 interfaces to define, update, and query FSN information, FSL 399 information, and FSN to FSL mapping information. An individual 400 repository of namespace information is called an NSDB node. Each 401 NSDB node is managed by a single administrative entity. A single 402 admin entity can manage multiple NSDB nodes. 404 The difference between the NSDB service and an NSDB node is analogous 405 to that between the DNS service and a particular DNS server. 407 Each NSDB node stores the definition of the FSNs for which it is 408 authoritative. It also stores the definitions of the FSLs associated 409 with those FSNs. An NSDB node is authoritative for the filesets that 410 it defines. An NSDB node can cache information from a peer NSDB 411 node. The fileserver can always contact a local NSDB node (if it has 412 been defined) or directly contact any NSDB node to resolve a 413 junction. Each NSDB node supports an LDAP [RFC4510] interface and 414 can be accessed by an LDAP client. 416 An NSDB MAY be replicated throughout the federation. If an NSDB is 417 replicated, the NSDB MUST exhibit loose, converging consistency as 418 defined in [RFC3254]. The mechanism by which this is achieved is 419 outside the scope of this document. Many LDAP implementations 420 support replication. These features MAY be used to replicate the 421 NSDB. 423 2.10. Mount Points, Junctions and Referrals 425 A mount point is a directory in a parent fileset where a target 426 fileset may be attached. If a client traverses the path leading from 427 the root of the namespace to the mount point of a target fileset it 428 should be able to access the data in that target fileset (assuming 429 appropriate permissions). 431 The directory where a fileset is mounted is represented by a junction 432 in the underlying filesystem. In other words, a junction can be 433 viewed as a reference from a directory in one fileset to the root of 434 the target fileset. A junction can be implemented as a special 435 marker on a directory that is interpreted by the fileserver as a 436 mount point, or by some other mechanism in the underlying filesystem. 438 What data is used by the underlying filesystem to represent the 439 junction is not defined by this protocol. The essential property is 440 that the server must be able to find, given the junction, the FSN for 441 the target fileset. The mechanism by which the server maps a 442 junction to an FSN is outside the scope of this document. The FSN 443 (as described earlier) contains the authoritative NSDB node, the 444 optional NSDB search base if one is defined, and the FsnUuid (a UUID 445 for the fileset). 447 When a client traversal reaches a junction, the client is referred to 448 a list of FSLs associated with the FSN targeted by the junction. The 449 client can then redirect its connection to one of the FSLs. This act 450 is called a referral. For NFSv4 and NFSv4.1 clients, the FSL 451 information is returned in the fs_locations and fs_locations_info 452 attributes respectively. 454 The federation protocols do not limit where and how many times a 455 fileset is mounted in the namespace. Filesets can be nested; a 456 fileset can be mounted under another fileset. 458 2.11. Unified Namespace and the Root Fileset 460 The root fileset, when defined, is the top-level fileset of the 461 federation-wide namespace. The root of the unified namespace is the 462 top level directory of this fileset. A set of designated fileservers 463 in the federation can export the root fileset to render the 464 federation-wide unified namespace. When a client mounts the root 465 fileset from any of these designated fileservers it can view a common 466 federation-wide namespace. The root fileset could be implemented 467 either as an exported NFS file system or as data in the NSDB itself. 468 The properties and schema definition of an NSDB-based root fileset 469 and the protocol details that describe how to configure and replicate 470 the root fileset are not defined in this document. 472 3. Examples 474 In this section we provide examples and discussion of the basic 475 operations facilitated by the federated filesystem protocol: creating 476 a fileset, adding a replica of a fileset, resolving a junction, and 477 creating a junction. 479 3.1. Creating a Fileset and its FSL(s) 481 A fileset is the abstraction of a set of files and the directory tree 482 that contains them. The fileset abstraction is the fundamental unit 483 of data management in the federation. This abstraction is 484 implemented by an actual directory tree whose root location is 485 specified by a fileset location (FSL). 487 In this section, we describe the basic requirements for starting with 488 a directory tree and creating a fileset that can be used in the 489 federation protocols. Note that we do not assume that the process of 490 creating a fileset requires any transformation of the files or the 491 directory hierarchy. The only thing that is required by this process 492 is assigning the fileset a fileset name (FSN) and expressing the 493 location of the implementation of the fileset as an FSL. 495 There are many possible variations to this procedure, depending on 496 how the FSN that binds the FSL is created, and whether other replicas 497 of the fileset exist, are known to the federation, and need to be 498 bound to the same FSN. 500 It is easiest to describe this in terms of how to create the initial 501 implementation of the fileset, and then describe how to add replicas. 503 3.1.1. Creating a Fileset and an FSN 505 1. Choose the NSDB node that will keep track of the FSL(s) and 506 related information for the fileset. 508 2. Create an FSN in the NSDB node. 510 The FSN UUID is chosen by the administrator or generated 511 automatically by administration software. The former case is 512 used if the fileset is being restored, perhaps as part of 513 disaster recovery, and the administrator wishes to specify the 514 FSN UUID in order to permit existing junctions that reference 515 that FSN to work again. 517 At this point, the FSN exists, but its fileset locations are 518 unspecified. 520 3. For the FSN created above, create an FSL with the appropriate 521 information in the NSDB node. 523 3.1.2. Adding a Replica of a Fileset 525 Adding a replica is straightforward: the NSDB node and the FSN are 526 already known. The only remaining step is to add another FSL. 528 Note that the federation protocols only provide the mechanisms to 529 register and unregister replicas of a fileset. Fileserver-to- 530 fileserver replication protocols are not defined. 532 3.2. Junction Resolution 534 A fileset may contain references to other filesets. These references 535 are represented by junctions. If a client requests access to a 536 fileset object that is a junction, the fileserver resolves the 537 junction to discover one or more FSLs that implement the referenced 538 fileset. 540 There are many possible variations to this procedure, depending on 541 how the junctions are represented by the fileserver and how the 542 fileserver performs junction resolution. 544 Step 4 is the only step that interacts directly with the federation 545 protocols. The rest of the steps may use platform-specific 546 interfaces. 548 1. The fileserver determines that the object being accessed is a 549 junction. 551 2. The fileserver does a local lookup to find the FSN of the target 552 fileset. 554 3. Using the FSN, the fileserver finds the NSDB node responsible for 555 the target FSN. 557 4. The fileserver contacts that NSDB node and asks for the set of 558 FSLs that implement the target FSN. The NSDB node responds with 559 a (possibly empty) set of FSLs. 561 5. The fileserver converts one or more of the FSLs to the location 562 type used by the client (e.g., a Network File System (NFSv4) 563 fs_location, as described in [3530bis]). 565 6. The fileserver redirects (in whatever manner is appropriate for 566 the client) the client to the location(s). 568 3.3. Example Use Cases for Fileset Annotations 570 Fileset annotations MAY be used to convey additional attributes of a 571 fileset 573 For example, fileset annotations can be used to define relationships 574 between filesets that can be used by an auxiliary replication 575 protocol. Consider the scenario where a fileset is created and 576 mounted at some point in the namespace. A snapshot of the read-write 577 FSL of that fileset is taken periodically at different frequencies 578 say a daily snapshot or a weekly snapshot. The different snapshots 579 are mounted at different locations in the namespace. The daily 580 snapshots are considered as a different fileset from the weekly ones 581 but both are related to the source fileset. For this we can define 582 an annotation labeling the filesets as source and replica. The 583 replication protocol can use this information to copy data from one 584 or more FSLs of the source fileset to all the FSLs of the replica 585 fileset. The replica filesets are read-only while the source fileset 586 is read-write. 588 This follows the traditional Andrew File System (AFS) model of 589 mounting the read-only volume at a path in the namespace different 590 from that of the read-write volume [AFS]. 592 The federation protocol does not control or manage the relationship 593 among filesets. It merely enables annotating the filesets with user- 594 defined relationships. 596 Another potential use for annotations is recording references to an 597 FSN. A single annotation containing the number of references could 598 be defined or multiple annotations, one per reference, could be used 599 to store detailed information on the location of each reference. As 600 with the replication annotation described above, the maintenance of 601 reference information would not be controlled by the federation 602 protocol. The information would mostly likely be non-authoritative 603 because the the ability to create a junction does not require the 604 authority to update the FSN record. In any event, such annotations 605 could be useful to administrators for determining if an FSN is 606 referenced by a junction. 608 4. NSDB Configuration and Schema 610 This section describes how an NSDB is constructed using an LDAP 611 Version 3 [RFC4510] Directory. Section 4.1 describes the basic 612 properties of the LDAP configuration that MUST be used in order to 613 ensure compatibility between different implementations. Section 4.2 614 defines the new LDAP attribute types, the new object types, and 615 specifies how the distinguished name (DN) of each object instance 616 MUST be constructed. 618 4.1. LDAP Configuration 620 An NSDB is constructed using an LDAP Directory. This LDAP Directory 621 MAY have multiple naming contexts. For each naming context, the LDAP 622 Directory's root DSE will have a namingContext attribute. Each 623 namingContext attribute contains the DN of the naming context's root 624 entry. For each naming context that contains federation entries 625 (e.g. FSNs and FSLs): 627 1. There MUST be an LDAP entry that is superior to all of the naming 628 context's federation entries in the Directory Information Tree 629 (DIT) This entry is termed the NSDB Container Entry (NCE). The 630 NCE's children are FSNs. An FSNs children are FSLs. 632 2. The naming context's root entry MUST include the 633 fedfsNsdbContainerInfo (defined below) as one of its object 634 classes. The fedfsNsdbContainerInfo's fedfsNcePrefix attribute 635 is used to locate the naming context's NCE. 637 If a naming context does not contain federation entries, it will not 638 contain an NCE and its root entry will not include a 639 fedfsNsdbContainerInfo as one of its object classes. 641 A fedfsNsdbContainerInfo's fedfsNcePrefix attribute contains a 642 string. Prepending this string to the namingContext value produces 643 the Distinguished Name (DN) of the NSDB Container Entry. An empty 644 fedfsNcePrefix string value indicates that the NSDB Container Entry 645 is the namingContext's root entry. 647 For example, an LDAP directory might have the following entries: 649 -+ [root DSE] 650 | namingContext: o=fedfs 651 | namingContext: dc=example,dc=com 652 | namingContext: ou=system 653 | 654 | 655 +---- [o=fedfs] 656 | fedfsNcePrefix: 657 | 658 | 659 +---- [dc=example,dc=com] 660 | fedfsNcePrefix: ou=fedfs,ou=corp-it 661 | 662 | 663 +---- [ou=system] 665 In this case, the o=fedfs namingContext has an NSBD Container Entry 666 at o=fedfs, the dc=example,dc=com namingContext has an NSDB Container 667 Entry at ou=fedfs,ou=corp-it,dc=example,dc=com, and the ou=system 668 namingContext has no NSDB Container Entry. 670 The NSDB SHOULD be configured with one or more privileged LDAP users. 671 These users are able to modify the contents of the LDAP database. An 672 administrator that performs the operations described in Section 5.1 673 SHOULD authenticate using the DN of a privileged LDAP user. 675 It MUST be possible for an unprivileged (unauthenticated) user to 676 perform LDAP queries that access the NSDB data. A fileserver 677 performs the operations described in Section 5.2 as an unprivileged 678 user. 680 All implementations SHOULD use the same schema, or, at minimum, a 681 schema that includes all of the objects, with each of the attributes, 682 named in the following sections. 684 Given the above configuration guidelines, an NSDB SHOULD be 685 constructed using a dedicated LDAP directory. Separate LDAP 686 directories are RECOMMENDED for other purposes, such as storing user 687 account information. By using an LDAP directory dedicated to storing 688 NSDB records, there is no need to disturb the configuration of any 689 other LDAP directories that store information unrelated to an NSDB. 691 4.2. LDAP Schema 693 The schema definitions provided in this document use the LDAP schema 694 syntax defined in [RFC4512]. The definitions are formatted to allow 695 the reader to easily extract them from the document. The reader can 696 use the following shell script to extract the definitions: 698 700 #!/bin/sh 701 grep '^ *///' | sed 's?^ */// ??' | sed 's?^ *///$??' 703 705 If the above script is stored in a file called "extract.sh", and this 706 document is in a file called "spec.txt", then the reader can do: 708 710 sh extract.sh < spec.txt > fedfs.schema 712 714 The effect of the script is to remove leading white space from each 715 line, plus a sentinel sequence of "///". 717 As stated above, code components extracted from this document must 718 include the following license: 720 721 /// # 722 /// # Copyright (c) 2010 IETF Trust and the persons identified 723 /// # as authors of the code. All rights reserved. 724 /// # 725 /// # The authors of the code are the authors of 726 /// # [draft-ietf-nfsv4-federated-fs-protocol-xx.txt]: J. Lentini, 727 /// # C. Everhart, D. Ellard, R. Tewari, and M. Naik. 728 /// # 729 /// # Redistribution and use in source and binary forms, with 730 /// # or without modification, are permitted provided that the 731 /// # following conditions are met: 732 /// # 733 /// # - Redistributions of source code must retain the above 734 /// # copyright notice, this list of conditions and the 735 /// # following disclaimer. 736 /// # 737 /// # - Redistributions in binary form must reproduce the above 738 /// # copyright notice, this list of conditions and the 739 /// # following disclaimer in the documentation and/or other 740 /// # materials provided with the distribution. 741 /// # 742 /// # - Neither the name of Internet Society, IETF or IETF 743 /// # Trust, nor the names of specific contributors, may be 744 /// # used to endorse or promote products derived from this 745 /// # software without specific prior written permission. 746 /// # 747 /// # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 748 /// # AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED 749 /// # WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 750 /// # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 751 /// # FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO 752 /// # EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE 753 /// # LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 754 /// # EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 755 /// # NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 756 /// # SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 757 /// # INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 758 /// # LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 759 /// # OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING 760 /// # IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF 761 /// # ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 762 /// # 764 766 4.2.1. LDAP Attributes 768 This section describes the required attributes of the NSDB LDAP 769 schema. The following definitions are used below: 771 o The "name" attribute described in [RFC4519]. 773 o The Integer syntax (1.3.6.1.4.1.1466.115.121.1.27) described in 774 [RFC4517]. 776 o The "integerMatch" rule described in [RFC4517]. 778 o The Octet String syntax (1.3.6.1.4.1.1466.115.121.1.40) described 779 in [RFC4517]. 781 o The "octetStringMatch" rule described in [RFC4517]. 783 o The Boolean syntax (1.3.6.1.4.1.1466.115.121.1.7) described in 784 [RFC4517]. 786 o The "booleanMatch" rule described in [RFC4517]. 788 o The "distinguishedNameMatch" rule described in [RFC4517]. 790 o The DN syntax (1.3.6.1.4.1.1466.115.121.1.12) described in 791 [RFC4517]. 793 4.2.1.1. fedfsUuid 795 A fedfsUuid is the base type for all of the universally unique 796 identifiers (UUIDs) used by the federated filesystem protocols. 798 To minimize the probability of two UUIDs colliding, a consistent 799 procedure for generating UUIDs SHOULD be used throughout a 800 federation. Within a federation, UUIDs SHOULD be generated using the 801 procedure described for version 1 of the UUID variant specified in 802 [RFC4122]. This is the time-based UUID variant provided by many UUID 803 programming libraries (e.g., the OSF DCE uuid_generate_time(1) API). 805 The UUID's text representation (as defined in [RFC4122]) SHOULD be 806 encoded as a UTF-8 string. 808 A fedfsUuid is a single-valued LDAP attribute. 810 811 /// 812 /// attributetype ( 813 /// 1.3.6.1.4.1.31103.1.1 NAME 'fedfsUuid' 814 /// DESC 'A UUID used by NSDB' 815 /// SUP name 816 /// SINGLE-VALUE 817 /// ) 818 /// 820 822 4.2.1.2. fedfsNetAddr 824 A fedfsNetAddr is the locative name of a network service in either 825 IPv4, IPv6, or DNS name notation. It MUST be a UTF-8 string and 826 SHOULD be prepared using the server4 rules defined in Chapter 12 827 "Internationalization" of [3530bis]. 829 An IPv4 address MUST be represented using the standard dotted decimal 830 format defined by the IPv4address rule in Section 3.2.2 of RFC 3986 831 [RFC3986]. An IPv6 address MUST be represented using the format 832 defined in Section 2.2 of RFC 4291 [RFC4291]. 834 A DNS name MUST be represented using a fully qualified domain name. 835 A system (i.e. fileserver or administrative host) SHOULD resolve the 836 fully qualified domain name to a network address using the system's 837 standard resolution mechanisms. 839 This attribute is single-valued. 841 843 /// 844 /// attributetype ( 845 /// 1.3.6.1.4.1.31103.1.2 NAME 'fedfsNetAddr' 846 /// DESC 'The network name of a host or service' 847 /// SUP name 848 /// SINGLE-VALUE 849 /// ) 850 /// 852 854 4.2.1.3. fedfsNetPort 856 A fedfsNetPort is the decimal representation of a transport service's 857 port number. A fedfsNetPort MUST be encoded as an Integer syntax 858 value [RFC4517]. 860 This attribute is single-valued. 862 864 /// 865 /// attributetype ( 866 /// 1.3.6.1.4.1.31103.1.3 NAME 'fedfsNetPort' 867 /// DESC 'A transport port number of a service' 868 /// EQUALITY integerMatch 869 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 870 /// SINGLE-VALUE 871 /// ) 872 /// 874 876 4.2.1.4. fedfsFsnUuid 878 A fedfsFsnUuid represents the UUID component of an FSN. An NSDB 879 SHOULD ensure that no two FSNs it stores have the same fedfsFsnUuid. 881 The fedfsFsnUuid is a subclass of fedfsUuid, with the same encoding 882 rules. 884 This attribute is single-valued. 886 888 /// 889 /// attributetype ( 890 /// 1.3.6.1.4.1.31103.1.4 NAME 'fedfsFsnUuid' 891 /// DESC 'The FSN UUID component of an FSN' 892 /// SUP fedfsUuid 893 /// SINGLE-VALUE 894 /// ) 895 /// 897 899 4.2.1.5. fedfsNsdbName 901 A fedfsNsdbName is the NSDB component of an FSN. 903 It MUST be a UTF-8 string containing a DNS name. The DNS name MUST 904 be represented using a fully qualified domain name. A system (i.e. 905 fileserver or administrative host) SHOULD resolve the fully qualified 906 domain name to a network address using the system's standard 907 resolution mechanisms. 909 FSNs are immutable and invariant. The attributes of an FSN, 910 including the fedfsNsdbName, are expected to remain constant. 911 Therefore, a fedfsNsdbName SHOULD NOT contain a network address, such 912 as an IPv4 or IPv6 address, as this would indefinitely assign the 913 network address. 915 This attribute is single-valued. 917 919 /// 920 /// attributetype ( 921 /// 1.3.6.1.4.1.31103.1.5 NAME 'fedfsNsdbName' 922 /// DESC 'The NSDB node component of an FSN' 923 /// SUP name 924 /// SINGLE-VALUE 925 /// ) 926 /// 928 930 4.2.1.6. fedfsNsdbPort 932 A fedfsNsdbPort is the decimal representation of an NSDB's port 933 number. The fedfsNsdbPort attribute is a subclass of fedfsNetPort, 934 with the same encoding rules. 936 This attribute is single-valued. 938 940 /// 941 /// attributetype ( 942 /// 1.3.6.1.4.1.31103.1.6 NAME 'fedfsNsdbPort' 943 /// DESC 'The transport port number of an NSDB' 944 /// SUP fedfsNetPort 945 /// SINGLE-VALUE 946 /// ) 947 /// 949 951 4.2.1.7. fedfsNcePrefix 953 A fedfsNcePrefix stores a distinguished name (DN) prefix. 955 This attribute is single-valued. 957 959 /// 960 /// attributetype ( 961 /// 1.3.6.1.4.1.31103.1.7 NAME 'fedfsNcePrefix' 962 /// DESC 'NCE prefix' 963 /// EQUALITY distinguishedNameMatch 964 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 965 /// SINGLE-VALUE 966 /// ) 967 /// 969 971 OID 1.3.6.1.4.1.1466.115.121.1.12 is the DN syntax [RFC4517]. 973 4.2.1.8. fedfsFslUuid 975 A fedfsFslUuid represents the UUID of an FSL. An NSDB SHOULD ensure 976 that no two FSLs it stores have the same fedfsFslUuid. 978 The fedfsFslUuid attribute is a subclass of fedfsUuid, with the same 979 encoding rules. 981 This attribute is single-valued. 983 985 /// 986 /// attributetype ( 987 /// 1.3.6.1.4.1.31103.1.8 NAME 'fedfsFslUuid' 988 /// DESC 'UUID of an FSL' 989 /// SUP fedfsUuid 990 /// SINGLE-VALUE 991 /// ) 992 /// 994 996 4.2.1.9. fedfsFslHost 998 A fedfsFslHost is the host component of an FSL. The fedfsFslHost 999 attribute is a subclass of fedfsNetAddr, with the same encoding 1000 rules. 1002 This attribute is single-valued. 1004 1005 /// 1006 /// attributetype ( 1007 /// 1.3.6.1.4.1.31103.1.9 NAME 'fedfsFslHost' 1008 /// DESC 'Service location for a fileserver' 1009 /// SUP fedfsNetAddr 1010 /// SINGLE-VALUE 1011 /// ) 1012 /// 1014 1016 4.2.1.10. fedfsFslPort 1018 A fedfsFslPort is the decimal representation of a file service's port 1019 number. The fedfsFslPort attribute is a subclass of fedfsNetPort, 1020 with the same encoding rules. 1022 This attribute is single-valued. 1024 1026 /// 1027 /// attributetype ( 1028 /// 1.3.6.1.4.1.31103.1.10 NAME 'fedfsFslPort' 1029 /// DESC 'The file service transport port number' 1030 /// SUP fedfsNetPort 1031 /// SINGLE-VALUE 1032 /// ) 1033 /// 1035 1037 4.2.1.11. fedfsFslTTL 1039 A fedfsFslTTL is the amount of time in seconds an FSL SHOULD be 1040 cached by a fileserver. A fedfsFslTTL MUST be encoded as an Integer 1041 syntax value [RFC4517]. 1043 This attribute is single-valued. 1045 1046 /// 1047 /// attributetype ( 1048 /// 1.3.6.1.4.1.31103.1.11 NAME 'fedfsFslTTL' 1049 /// DESC 'Time to live of an FSL' 1050 /// EQUALITY integerMatch 1051 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1052 /// SINGLE-VALUE 1053 /// ) 1054 /// 1056 1058 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1060 4.2.1.12. fedfsAnnotation 1062 A fedfsAnnotation contains an object annotation formatted as a key/ 1063 value pair. 1065 This attribute is multi-valued; an object type that permits 1066 annotations may have any number of annotations per instance. 1068 A fedfsAnnotation attribute is a human-readable sequence of UTF-8 1069 characters with no non-terminal NUL characters. The value MUST be 1070 formatted according to the following ABNF [RFC5234] rules: 1072 ANNOTATION = KEY EQUALS VALUE 1073 KEY = ITEM 1074 VALUE = ITEM 1075 ITEM = BLANK DQUOTE STR DQUOTE BLANK 1076 BLANK = 0*EMPTY 1077 EMPTY = SPACE / HTAB 1078 HTAB = %x09 ; horizontal tab 1079 STR = 0*UTF8 1081 The DQUOTE, EQUALS, UTF8, and SPACE rules are defined in [RFC4512]. 1083 The following escape sequences are allowed: 1085 +-----------------+-------------+ 1086 | escape sequence | replacement | 1087 +-----------------+-------------+ 1088 | \\ | \ | 1089 | \" | " | 1090 +-----------------+-------------+ 1092 A fedfsAnnotation value SHOULD be processed as follows: 1094 1. Scan through the attribute value and replace the above escape 1095 sequences. 1097 2. Parse the results of the previous step according to the 1098 ANNOTATION rule. 1100 A fedfsAnnotation attribute that does not adhere to this format 1101 SHOULD be ignored. 1103 The following are examples of valid fedfsAnnotation attributes: 1105 "key1" = "foo" 1106 "another key" = "x=3" 1107 "key-2" = "A string with \" and \\ characters." 1109 which correspond to the following key/value pairs: 1111 +-------------+-----------------------------------+ 1112 | key | value | 1113 +-------------+-----------------------------------+ 1114 | key1 | foo | 1115 | another key | x=3 | 1116 | key-2 | A string with " and \ characters. | 1117 +-------------+-----------------------------------+ 1119 1121 /// 1122 /// attributetype ( 1123 /// 1.3.6.1.4.1.31103.1.12 NAME 'fedfsAnnotation' 1124 /// DESC 'Annotation of an object' 1125 /// SUP name 1126 /// ) 1127 /// 1129 1131 4.2.1.13. fedfsDescr 1133 A fedfsDescr stores an object description. The description MUST be 1134 encoded as a UTF-8 string. 1136 This attribute is multi-valued which permits any number of 1137 descriptions per entry. 1139 1140 /// 1141 /// attributetype ( 1142 /// 1.3.6.1.4.1.31103.1.13 NAME 'fedfsDescr' 1143 /// DESC 'Description of an object' 1144 /// SUP name 1145 /// ) 1146 /// 1148 1150 4.2.1.14. fedfsNfsPath 1152 A fedfsNfsPath is the path attribute of an FSL. The path MUST be the 1153 XDR encoded NFS path as defined by the NFS pathname4 XDR type of the 1154 fs_location's rootpath [3530bis] and the fs_locations_item's 1155 fli_rootpath [RFC5661]. The NFS pathname4 XDR type is a variable 1156 length array of component4 elements. The NFS component4 XDR type is 1157 a variable length array of opaque data. A fedfsNfsPath attribute's 1158 component4 elements SHOULD be prepared using the component4 rules 1159 defined in Chapter 12 "Internationalization" of [3530bis]. 1161 This attribute is single-valued. 1163 1165 /// 1166 /// attributetype ( 1167 /// 1.3.6.1.4.1.31103.1.100 NAME 'fedfsNfsPath' 1168 /// DESC 'Server-local path to a fileset' 1169 /// EQUALITY octetStringMatch 1170 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 1171 /// SINGLE-VALUE 1172 /// ) 1173 /// 1175 1177 OID 1.3.6.1.4.1.1466.115.121.1.40 is the Octet String syntax 1178 [RFC4517]. 1180 4.2.1.15. fedfsNfsMajorVer 1182 A fedfsNfsMajorVer contains the NFS major version of the associated 1183 NFS FSL. A fedfsNfsMajorVer MUST be encoded as an Integer syntax 1184 value [RFC4517]. 1186 For example if the FSL was exported via NFS 4.1, the contents of this 1187 attribute would be the value 4. 1189 This attribute is single-valued. 1191 1193 /// 1194 /// attributetype ( 1195 /// 1.3.6.1.4.1.31103.1.101 NAME 'fedfsNfsMajorVer' 1196 /// DESC 'NFS major version' 1197 /// EQUALITY integerMatch 1198 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1199 /// SINGLE-VALUE 1200 /// ) 1201 /// 1203 1205 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1207 4.2.1.16. fedfsNfsMinorVer 1209 A fedfsNfsMinorVer contain the NFS minor version of the associated 1210 NFS FSL. A fedfsNfsMinorVer MUST be encoded as an Integer syntax 1211 value [RFC4517]. 1213 For example if the FSL was exported via NFS 4.1, the contents of this 1214 attribute would be the value 1. 1216 This attribute is single-valued. 1218 1220 /// 1221 /// attributetype ( 1222 /// 1.3.6.1.4.1.31103.1.102 NAME 'fedfsNfsMinorVer' 1223 /// DESC 'NFS minor version' 1224 /// EQUALITY integerMatch 1225 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1226 /// SINGLE-VALUE 1227 /// ) 1228 /// 1230 1232 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1234 4.2.1.17. fedfsNfsCurrency 1236 A fedfsNfsCurrency stores the NFSv4.1 fs_locations_server's 1237 fls_currency value [RFC5661]. A fedfsNfsCurrency MUST be encoded as 1238 an Integer syntax value [RFC4517] in the range [-2147483648, 1239 2147483647]. 1241 This attribute is single-valued. 1243 1245 /// 1246 /// attributetype ( 1247 /// 1.3.6.1.4.1.31103.1.103 NAME 'fedfsNfsCurrency' 1248 /// DESC 'up-to-date measure of the data' 1249 /// EQUALITY integerMatch 1250 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1251 /// SINGLE-VALUE 1252 /// ) 1253 /// 1255 1257 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1259 4.2.1.18. fedfsNfsGenFlagWritable 1261 A fedfsNfsGenFlagWritable stores the value of an FSL's NFSv4.1 1262 FSLI4GF_WRITABLE bit [RFC5661]. A value of "TRUE" indicates the bit 1263 is true. A value of "FALSE" indicates the bit is false. 1265 1267 /// 1268 /// attributetype ( 1269 /// 1.3.6.1.4.1.31103.1.104 NAME 'fedfsNfsGenFlagWritable' 1270 /// DESC 'Indicates if the filesystem is writable' 1271 /// EQUALITY booleanMatch 1272 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1273 /// SINGLE-VALUE 1274 /// ) 1275 /// 1277 1279 OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. 1281 4.2.1.19. fedfsNfsGenFlagGoing 1283 A fedfsNfsGenFlagGoing stores the value of an FSL's NFSv4.1 1284 FSLI4GF_GOING bit [RFC5661]. A value of "TRUE" indicates the bit is 1285 true. A value of "FALSE" indicates the bit is false. 1287 1289 /// 1290 /// attributetype ( 1291 /// 1.3.6.1.4.1.31103.1.105 NAME 'fedfsNfsGenFlagGoing' 1292 /// DESC 'Indicates if the filesystem is going' 1293 /// EQUALITY booleanMatch 1294 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1295 /// SINGLE-VALUE 1296 /// ) 1297 /// 1299 1301 OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. 1303 4.2.1.20. fedfsNfsGenFlagSplit 1305 A fedfsNfsGenFlagSplit stores the value of an FSL's NFSv4.1 1306 FSLI4GF_SPLIT bit [RFC5661]. A value of "TRUE" indicates the bit is 1307 true. A value of "FALSE" indicates the bit is false. 1309 1311 /// 1312 /// attributetype ( 1313 /// 1.3.6.1.4.1.31103.1.106 NAME 'fedfsNfsGenFlagSplit' 1314 /// DESC 'Indicates if there are multiple filesystems' 1315 /// EQUALITY booleanMatch 1316 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1317 /// SINGLE-VALUE 1318 /// ) 1319 /// 1321 1323 OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. 1325 4.2.1.21. fedfsNfsTransFlagRdma 1327 A fedfsNfsTransFlagRdma stores the value of an FSL's NFSv4.1 1328 FSLI4TF_RDMA bit [RFC5661]. A value of "TRUE" indicates the bit is 1329 true. A value of "FALSE" indicates the bit is false. 1331 1333 /// 1334 /// attributetype ( 1335 /// 1.3.6.1.4.1.31103.1.107 NAME 'fedfsNfsTransFlagRdma' 1336 /// DESC 'Indicates if the transport supports RDMA' 1337 /// EQUALITY booleanMatch 1338 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1339 /// SINGLE-VALUE 1340 /// ) 1341 /// 1343 1345 OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. 1347 4.2.1.22. fedfsNfsClassSimul 1349 A fedfsNfsClassSimul contains the FSL's NFSv4.1 FSLI4BX_CLSIMUL 1350 [RFC5661] value. A fedfsNfsClassSimul MUST be encoded as an Integer 1351 syntax value [RFC4517] in the range [0, 255]. 1353 1355 /// 1356 /// attributetype ( 1357 /// 1.3.6.1.4.1.31103.1.108 NAME 'fedfsNfsClassSimul' 1358 /// DESC 'The simultaneous-use class of the filesystem' 1359 /// EQUALITY integerMatch 1360 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1361 /// SINGLE-VALUE 1362 /// ) 1363 /// 1365 1367 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1369 4.2.1.23. fedfsNfsClassHandle 1371 A fedfsNfsClassHandle contains the FSL's NFSv4.1 FSLI4BX_CLHANDLE 1372 [RFC5661] value. A fedfsNfsClassHandle MUST be encoded as an Integer 1373 syntax value [RFC4517] in the range [0, 255]. 1375 1376 /// 1377 /// attributetype ( 1378 /// 1.3.6.1.4.1.31103.1.109 NAME 'fedfsNfsClassHandle' 1379 /// DESC 'The handle class of the filesystem' 1380 /// EQUALITY integerMatch 1381 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1382 /// SINGLE-VALUE 1383 /// ) 1384 /// 1386 1388 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1390 4.2.1.24. fedfsNfsClassFileid 1392 A fedfsNfsClassFileid contains the FSL's NFSv4.1 FSLI4BX_CLFILEID 1393 [RFC5661] value. A fedfsNfsClassFileid MUST be encoded as an Integer 1394 syntax value [RFC4517] in the range [0, 255]. 1396 1398 /// 1399 /// attributetype ( 1400 /// 1.3.6.1.4.1.31103.1.110 NAME 'fedfsNfsClassFileid' 1401 /// DESC 'The fileid class of the filesystem' 1402 /// EQUALITY integerMatch 1403 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1404 /// SINGLE-VALUE 1405 /// ) 1406 /// 1408 1410 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1412 4.2.1.25. fedfsNfsClassWritever 1414 A fedfsNfsClassWritever contains the FSL's NFSv4.1 FSLI4BX_CLWRITEVER 1415 [RFC5661] value. A fedfsNfsClassWritever MUST be encoded as an 1416 Integer syntax value [RFC4517] in the range [0, 255]. 1418 1419 /// 1420 /// attributetype ( 1421 /// 1.3.6.1.4.1.31103.1.111 NAME 'fedfsNfsClassWritever' 1422 /// DESC 'The write-verifier class of the filesystem' 1423 /// EQUALITY integerMatch 1424 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1425 /// SINGLE-VALUE 1426 /// ) 1427 /// 1429 1431 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1433 4.2.1.26. fedfsNfsClassChange 1435 A fedfsNfsClassChange contains the FSL's NFSv4.1 FSLI4BX_CLCHANGE 1436 [RFC5661] value. A fedfsNfsClassChange MUST be encoded as an Integer 1437 syntax value [RFC4517] in the range [0, 255]. 1439 1441 /// 1442 /// attributetype ( 1443 /// 1.3.6.1.4.1.31103.1.112 NAME 'fedfsNfsClassChange' 1444 /// DESC 'The change class of the filesystem' 1445 /// EQUALITY integerMatch 1446 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1447 /// SINGLE-VALUE 1448 /// ) 1449 /// 1451 1453 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1455 4.2.1.27. fedfsNfsClassReaddir 1457 A fedfsNfsClassReaddir contains the FSL's NFSv4.1 FSLI4BX_CLREADDIR 1458 [RFC5661] value. A fedfsNfsClassReaddir MUST be encoded as an 1459 Integer syntax value [RFC4517] in the range [0, 255]. 1461 1462 /// 1463 /// attributetype ( 1464 /// 1.3.6.1.4.1.31103.1.113 NAME 'fedfsNfsClassReaddir' 1465 /// DESC 'The readdir class of the filesystem' 1466 /// EQUALITY integerMatch 1467 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1468 /// SINGLE-VALUE 1469 /// ) 1470 /// 1472 1474 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1476 4.2.1.28. fedfsNfsReadRank 1478 A fedfsNfsReadRank contains the FSL's NFSv4.1 FSLI4BX_READRANK 1479 [RFC5661] value. A fedfsNfsReadRank MUST be encoded as an Integer 1480 syntax value [RFC4517] in the range [0, 255]. 1482 1484 /// 1485 /// attributetype ( 1486 /// 1.3.6.1.4.1.31103.1.114 NAME 'fedfsNfsReadRank' 1487 /// DESC 'The read rank of the filesystem' 1488 /// EQUALITY integerMatch 1489 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1490 /// SINGLE-VALUE 1491 /// ) 1492 /// 1494 1496 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1498 4.2.1.29. fedfsNfsReadOrder 1500 A fedfsNfsReadOrder contains the FSL's NFSv4.1 FSLI4BX_READORDER 1501 [RFC5661] value. A fedfsNfsReadOrder MUST be encoded as an Integer 1502 syntax value [RFC4517] in the range [0, 255]. 1504 1505 /// 1506 /// attributetype ( 1507 /// 1.3.6.1.4.1.31103.1.115 NAME 'fedfsNfsReadOrder' 1508 /// DESC 'The read order of the filesystem' 1509 /// EQUALITY integerMatch 1510 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1511 /// SINGLE-VALUE 1512 /// ) 1513 /// 1515 1517 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1519 4.2.1.30. fedfsNfsWriteRank 1521 A fedfsNfsWriteRank contains the FSL's FSLI4BX_WRITERANK [RFC5661] 1522 value. A fedfsNfsWriteRank MUST be encoded as an Integer syntax 1523 value [RFC4517] in the range [0, 255]. 1525 1527 /// 1528 /// attributetype ( 1529 /// 1.3.6.1.4.1.31103.1.116 NAME 'fedfsNfsWriteRank' 1530 /// DESC 'The write rank of the filesystem' 1531 /// EQUALITY integerMatch 1532 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1533 /// SINGLE-VALUE 1534 /// ) 1535 /// 1537 1539 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1541 4.2.1.31. fedfsNfsWriteOrder 1543 A fedfsNfsWriteOrder contains the FSL's FSLI4BX_WRITEORDER [RFC5661] 1544 value. A fedfsNfsWriteOrder MUST be encoded as an Integer syntax 1545 value [RFC4517] in the range [0, 255]. 1547 1548 /// 1549 /// attributetype ( 1550 /// 1.3.6.1.4.1.31103.1.117 NAME 'fedfsNfsWriteOrder' 1551 /// DESC 'The write order of the filesystem' 1552 /// EQUALITY integerMatch 1553 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1554 /// SINGLE-VALUE 1555 /// ) 1556 /// 1558 1560 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1562 4.2.1.32. fedfsNfsVarSub 1564 A fedfsNfsVarSub stores the value of an FSL's NFSv4.1 FSLI4F_VAR_SUB 1565 bit [RFC5661]. A value of "TRUE" indicates the bit is true. A value 1566 of "FALSE" indicates the bit is false. 1568 1570 /// 1571 /// attributetype ( 1572 /// 1.3.6.1.4.1.31103.1.118 NAME 'fedfsNfsVarSub' 1573 /// DESC 'Indicates if variable substitution is present' 1574 /// EQUALITY booleanMatch 1575 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1576 /// SINGLE-VALUE 1577 /// ) 1578 /// 1580 1582 OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. 1584 4.2.1.33. fedfsNfsValidFor 1586 A fedfsNfsValidFor stores an FSL's NFSv4.1 fs_locations_info 1587 fli_valid_for value [RFC5661]. A fedfsNfsValidFor MUST be encoded as 1588 an Integer syntax value [RFC4517] in the range [-2147483648, 1589 2147483647]. 1591 An FSL's fedfsFslTTL value and fedfsNfsValidFor value MAY be 1592 different. 1594 This attribute is single-valued. 1596 1598 /// 1599 /// attributetype ( 1600 /// 1.3.6.1.4.1.31103.1.19 NAME 'fedfsNfsValidFor' 1601 /// DESC 'Valid for time' 1602 /// EQUALITY integerMatch 1603 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1604 /// SINGLE-VALUE 1605 /// ) 1606 /// 1608 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1610 1612 4.2.2. LDAP Objects 1614 4.2.2.1. fedfsNsdbContainerInfo 1616 A fedfsNsdbContainerInfo describes the location of the NCE. 1618 A fedfsFsn's fedfsNcePrefix attribute is REQUIRED. 1620 A fedfsFsn's fedfsAnnotation and fedfsDescr attributes are OPTIONAL. 1622 1624 /// 1625 /// objectclass ( 1626 /// 1.3.6.1.4.1.31103.1.1001 NAME 'fedfsNsdbContainerInfo' 1627 /// DESC 'Describes NCE location' 1628 /// SUP top AUXILIARY 1629 /// MUST ( 1630 /// fedfsNcePrefix 1631 /// ) 1632 /// MAY ( 1633 /// fedfsAnnotation 1634 /// $ fedfsDescr 1635 /// )) 1636 /// 1638 1640 4.2.2.2. fedfsFsn 1642 A fedfsFsn represents an FSN. 1644 A fedfsFsn's fedfsNsdbName and fedfsFsnUuid attributes are REQUIRED. 1646 A fedfsFsn's fedfsNsdbPort, fedfsAnnotation, and fedfsDescr 1647 attributes are OPTIONAL. 1649 If the fedfsNsdbPort is omitted, the standard LDAP port number, 389, 1650 SHOULD be assumed. 1652 The DN of an FSN is REQUIRED to take the following form: 1653 "fedfsFsnUuid=$FSNUUID,$NCE", where $FSNUUID is the UUID of the FSN 1654 and $NCE is the DN of the NCE ("o=fedfs" by default). Since LDAP 1655 requires a DN to be unique, this ensures that each FSN entry has a 1656 unique UUID value within the LDAP directory. 1658 A fedfsFsn MAY also have additional attributes, but these attributes 1659 MUST NOT be referenced by any part of this document. 1661 1663 /// 1664 /// objectclass ( 1665 /// 1.3.6.1.4.1.31103.1.1002 NAME 'fedfsFsn' 1666 /// DESC 'Represents a fileset' 1667 /// SUP top STRUCTURAL 1668 /// MUST ( 1669 /// fedfsFsnUuid 1670 /// $ fedfsNsdbName 1671 /// ) 1672 /// MAY ( 1673 /// fedfsNsdbPort 1674 /// $ fedfsAnnotation 1675 /// $ fedfsDescr 1676 /// )) 1677 /// 1679 1681 4.2.2.3. fedfsFsl 1683 The fedfsFsl object class represents an FSL. 1685 The fedfsFsl is an abstract object class. Protocol specific subtypes 1686 of this object class are used to store FSL information. The 1687 fedfsNfsFsl object class defined below is used to record an NFS FSL's 1688 location. Other subtypes MAY be defined for other protocols (e.g. 1689 CIFS). 1691 A fedfsFsl's fedfsFslUuid, fedfsFsnUuid, fedfsNsdbName, fedfsFslHost, 1692 and fedfsFslTTL attributes are REQUIRED. 1694 A fedfsFsl's fedfsNsdbPort, fedfsFslPort, fedfsAnnotation, and 1695 fedfsDescr attributes are OPTIONAL. 1697 If the fedfsNsdbPort is omitted, the standard LDAP port number, 389, 1698 SHOULD be assumed. 1700 If the fedfsFslPort is omitted, a standard port number based on the 1701 type of FSL should be assumed. For an NFS FSL, the standard NFS port 1702 number, 2049, SHOULD be assumed. 1704 The DN of an FSL is REQUIRED to take the following form: 1705 "fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE" where $FSLUUID is 1706 the FSL's UUID, $FSNUUID is the FSN's UUID, and $NCE is the DN of the 1707 NCE ("o=fedfs" by default). Since LDAP requires a DN to be unique, 1708 this ensures that each FSL entry has a unique UUID value within the 1709 LDAP directory. 1711 1713 /// 1714 /// objectclass ( 1715 /// 1.3.6.1.4.1.31103.1.1003 NAME 'fedfsFsl' 1716 /// DESC 'A physical location of a fileset' 1717 /// SUP top ABSTRACT 1718 /// MUST ( 1719 /// fedfsFslUuid 1720 /// $ fedfsFsnUuid 1721 /// $ fedfsNsdbName 1722 /// $ fedfsFslHost 1723 /// $ fedfsFslTTL 1724 /// ) 1725 /// MAY ( 1726 /// fedfsNsdbPort 1727 /// $ fedfsFslPort 1728 /// $ fedfsAnnotation 1729 /// $ fedfsDescr 1730 /// )) 1731 /// 1733 1735 4.2.2.4. fedfsNfsFsl 1737 A fedfsNfsFsl is used to represent an NFS FSL. The fedfsNfsFsl 1738 inherits all of the attributes of the fedfsFsl and extends the 1739 fedfsFsl with information specific to the NFS protocol. 1741 The DN of an NFS FSL is REQUIRED to take the following form: 1742 "fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE" where $FSLUUID is 1743 the FSL's UUID, $FSNUUID is the FSN's UUID, and $NCE is the DN of the 1744 NCE ("o=fedfs" by default). Since LDAP requires a DN to be unique, 1745 this ensures that each NFS FSL entry has a unique UUID value within 1746 the LDAP directory. 1748 1750 /// 1751 /// objectclass ( 1752 /// 1.3.6.1.4.1.31103.1.1004 NAME 'fedfsNfsFsl' 1753 /// DESC 'An NFS location of a fileset' 1754 /// SUP fedfsFsl STRUCTURAL 1755 /// MUST ( 1756 /// fedfsNfsPath 1757 /// $ fedfsNfsMajorVer 1758 /// $ fedfsNfsMinorVer 1759 /// $ fedfsNfsCurrency 1760 /// $ fedfsNfsGenFlagWritable 1761 /// $ fedfsNfsGenFlagGoing 1762 /// $ fedfsNfsGenFlagSplit 1763 /// $ fedfsNfsTransFlagRdma 1764 /// $ fedfsNfsClassSimul 1765 /// $ fedfsNfsClassHandle 1766 /// $ fedfsNfsClassFileid 1767 /// $ fedfsNfsClassWritever 1768 /// $ fedfsNfsClassChange 1769 /// $ fedfsNfsClassReaddir 1770 /// $ fedfsNfsReadRank 1771 /// $ fedfsNfsReadOrder 1772 /// $ fedfsNfsWriteRank 1773 /// $ fedfsNfsWriteOrder 1774 /// $ fedfsNfsVarSub 1775 /// $ fedfsNfsValidFor 1776 /// )) 1777 /// 1779 1781 5. NSDB Operations 1783 The operations defined by the protocol can be described as several 1784 sub-protocols that are used by entities within the federation to 1785 perform different roles. 1787 The first of these sub-protocols defines how the state of an NSDB 1788 node can be initialized and updated. The primary use of this sub- 1789 protocol is by an administrator to add, edit, or delete filesets, 1790 their properties, and their fileset locations. 1792 The second of these sub-protocols defines the queries that are sent 1793 to an NSDB node in order to perform resolution (or to find other 1794 information about the data stored within that NSDB node) and the 1795 responses returned by the NSDB node. The primary use of this sub- 1796 protocol is by a fileserver in order to perform resolution, but it 1797 may also be used by an administrator to query the state of the 1798 system. 1800 The first and second sub-protocols are defined as LDAP operations, 1801 using the schema defined in the previous section. If each NSDB node 1802 is a standard LDAP server, then, in theory, it is unnecessary to 1803 describe the LDAP operations in detail, because the operations are 1804 ordinary LDAP operations to query and update records. However, we do 1805 not require that an NSDB node implement a complete LDAP service, and 1806 therefore we define in these sections the minimum level of LDAP 1807 functionality required to implement an NSDB node. 1809 The NSDB sub-protocols are defined in the next two sub-sections. The 1810 descriptions of LDAP messages in these sections use the LDAP Data 1811 Interchange Format (LDIF) [RFC2849]. In order to differentiate 1812 constant and variable strings in the LDIF specifications, variables 1813 are prefixed by a $ character and use all upper case characters. For 1814 example, a variable named FOO would be specified as $FOO. 1816 This document uses the term NSDB client to refer to an LDAP client 1817 that uses either of the NSDB sub-protocols 1819 The third sub-protocol defines the queries and other requests that 1820 are sent to a fileserver in order to get information from it or to 1821 modify the state of the fileserver in a manner related to the 1822 federation protocols. The primary purpose of this protocol is for an 1823 administrator to create or delete a junction or discover related 1824 information about a particular fileserver. 1826 The third sub-protocol is defined as an ONC RPC protocols. The 1827 reason for using ONC RPC instead of LDAP is that all fileservers 1828 support ONC RPC but some do not support an LDAP Directory server. 1830 The ONC RPC administration protocol is defined in [FEDFS-ADMIN]. 1832 5.1. NSDB Operations for Administrators 1834 The admin entity initiates and controls the commands to manage 1835 fileset and namespace information. The admin entity, however, is 1836 stateless. All state is maintained at the NSDB nodes or at the 1837 fileserver. 1839 We require that each NSDB node be able to act as an LDAP server and 1840 that the protocol used for communicating between the admin entity and 1841 each NSDB node is LDAP. 1843 The names we assign to these operations are entirely for the purpose 1844 of exposition in this document, and are not part of the LDAP dialogs. 1846 5.1.1. Create an FSN 1848 This operation creates a new FSN in the NSDB by adding a new fedfsFsn 1849 entry in the NSDB's LDAP directory. 1851 A fedfsFsn entry contains a fedfsFsnUuid and fedfsNsdbName. The 1852 administrator chooses the fedfsFsnUuid and fedfsNsdbName. The 1853 process for choosing the fedfsFsnUuid is described in 1854 Section 4.2.1.1). The fedfsNsdbName is the name of the NSDB node 1855 that will serve as the source of definitive information about the FSN 1856 for the life of the FSN. 1858 The NSDB node that receives the request SHOULD check that 1859 fedfsNsdbName value matches its own value and return an error if it 1860 does not. This is to ensure that an FSN is always created by the 1861 NSDB node encoded within the FSN as its owner. 1863 The NSDB node that receives the request SHOULD check all of the 1864 attributes for validity and consistency, but this is not generally 1865 possible for LDAP servers because the consistency requirements cannot 1866 be expressed in the LDAP schema (although many LDAP servers can be 1867 extended, via plug-ins or other mechanisms, to add functionality 1868 beyond the strict definition of LDAP). 1870 5.1.1.1. LDAP Request 1872 This operation is implemented using the LDAP ADD request described by 1873 the LDIF below. 1875 dn: fedfsFsnUuid=$FSNUUID,$NCE 1876 changeType: add 1877 objectClass: fedfsFsn 1878 fedfsFsnUuid: $FSNUUID 1879 fedfsNsdbName: $NSDBNAME 1881 For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- 1882 00a0c91e6bf6", the $NSDBNAME is "nsdb.example.com", and the $NCE is 1883 "o=fedfs" the operation would be: 1885 dn: fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 1886 changeType: add 1887 objectClass: fedfsFsn 1888 fedfsFsnUuid: f81d4fae-7dec-11d0-a765-00a0c91e6bf6 1889 fedfsNsdbName: nsdb.example.com 1891 5.1.2. Delete an FSN 1893 This operation deletes an FSN by removing a fedfsFsn entry in the 1894 NSDB's LDAP directory. 1896 If the FSN entry being deleted has child FSL entries, this function 1897 MUST return an error. This ensures that the NSDB will not contain 1898 any orphaned FSL entries. A compliant LDAP implementation will meet 1899 this requirement since Section 4.8 of [RFC4511] defines the LDAP 1900 delete operation to only be capable of removing leaf entries. 1902 Note that the FSN delete function only removes the fileset from the 1903 namespace (by removing the records for that FSN from the NSDB node 1904 that receives this request). The fileset and its data are not 1905 deleted. Any junction that has this FSN as its target may continue 1906 to point to this non-existent FSN. A dangling reference may be 1907 detected when a client tries to resolve the target of a junction that 1908 refers to the deleted FSN and the NSDB returns an error. 1910 5.1.2.1. LDAP Request 1912 This operation is implemented using the LDAP DELETE request described 1913 by the LDIF below. 1915 dn: fedfsFsnUuid=$FSNUUID,$NCE 1916 changeType: delete 1918 For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- 1919 00a0c91e6bf6" and $NCE is "o=fedfs", the operation would be: 1921 dn: fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 1922 changeType: delete 1924 5.1.3. Create an FSL 1926 This operation creates a new FSL for the given FSN by adding a new 1927 fedfsFsl entry in the NSDB's LDAP directory. 1929 A fedfsFsl entry contains a fedfsFslUuid, fedfsFsnUuid, 1930 fedfsNsdbName, fedfsFslHost, and fedfsFslTTL. The administrator 1931 chooses the fedfsFslUuid. The process for choosing the fedfsFslUuid 1932 is described in Section 4.2.1.1. The fedfsFsnUuid is the UUID of the 1933 FSL's FSN. The fedfsNsdbName is the name of the NSDB node that 1934 stores definitive information about the FSL's FSN. The fedfsFslHost 1935 value is the network location of the fileserver that stores the FSL. 1936 The fedfsFslTTL is chosen by the administrator as described in 1937 Section 2.8.2. 1939 The administrator will also set additional attributes depending on 1940 the FSL type. 1942 5.1.3.1. LDAP Request 1944 This operation is implemented using the LDAP ADD request described by 1945 the LDIF below (NOTE: the LDIF shows the creation of an NFS FSL) 1947 dn:fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE 1948 changeType: add 1949 objectClass: fedfsNfsFsl 1950 fedfsFslUuid: $FSLUUID 1951 fedfsFsnUuid: $FSNUUID 1952 fedfsNsdbName: $NSDBNAME 1953 fedfsFslHost: $HOST 1954 fedfsFslPort: $PORT 1955 fedfsFslTTL: $TTL 1956 fedfsNfsPath: $PATH 1957 fedfsNfsMajorVer: $MAJOR 1958 fedfsNfsMinorVer: $MINOR 1959 fedfsNfsCurrency: $CURRENCY 1960 fedfsNfsGenFlagWritable: $WRITABLE 1961 fedfsNfsGenFlagGoing: $GOING 1962 fedfsNfsGenFlagSplit: $SPLIT 1963 fedfsNfsTransFlagRdma: $RDMA 1964 fedfsNfsClassSimul: $CLASS_SIMUL 1965 fedfsNfsClassHandle:$CLASS_HANDLE 1966 fedfsNfsClassFileid:$CLASS_FILEID 1967 fedfsNfsClassWritever:$CLASS_WRITEVER 1968 fedfsNfsClassChange: $CLASS_CHANGE 1969 fedfsNfsClassReaddir: $CLASS_READDIR 1970 fedfsNfsReadRank: $READ_RANK 1971 fedfsNfsReadOrder: $READ_ORDER 1972 fedfsNfsWriteRank: $WRITE_RANK 1973 fedfsNfsWriteOrder: $WRITE_ORDER 1974 fedfsNfsVarSub: $VAR_SUB 1975 fedfsNfsValidFor: $TIME 1976 fedfsAnnotation: $ANNOTATION 1977 fedfsDescr: $DESCR 1979 For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- 1980 00a0c91e6bf6", the $FSLUUID is "84f775a7-8e31-14ae-b39d- 1981 10eeee060d2c", the $NSDBNAME is "nsdb.example.com", the $HOST is 1982 "server.example.com", $PORT is "2049", the $TTL is "300" seconds, the 1983 $PATH is stored in the file "/tmp/fsl_path", fileset is exported via 1984 NFSv4.1 ($MAJOR is "4" and $MINOR is "1"), $CURRENCY is "0" (an up to 1985 date copy), the FSL is writable, but not going, split, or accessible 1986 via RDMA, the simultaneous-use class is "1", the handle class is "0", 1987 the fileid class is "1", the write-verifier class is "1", the change 1988 class is "1", the readdir class is "9", the read rank is "7", the 1989 read order is "8", the write rank is "5", the write order is "6", 1990 variable substitution is false, $TIME is "300" seconds, $ANNOTATION 1991 is ""foo" = "bar"", $DESC is "This is a description.", and the $NCE 1992 is "o=fedfs", the operation would be (for readability the DN is split 1993 into two lines): 1995 dn:fedfsFslUuid=84f775a7-8e31-14ae-b39d-10eeee060d2c, 1996 fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 1997 changeType: add 1998 objectClass: fedfsNfsFsl 1999 fedfsFslUuid: 84f775a7-8e31-14ae-b39d-10eeee060d2c 2000 fedfsFsnUuid: f81d4fae-7dec-11d0-a765-00a0c91e6bf6 2001 fedfsNsdbName: nsdb.example.com 2002 fedfsFslHost: server.example.com 2003 fedfsFslPort: 2049 2004 fedfsFslTTL: 300 2005 fedfsNfsPath:< file:///tmp/fsl_path 2006 fedfsNfsMajorVer: 4 2007 fedfsNfsMinorVer: 1 2008 fedfsNfsCurrency: 0 2009 fedfsNfsGenFlagWritable: TRUE 2010 fedfsNfsGenFlagGoing: FALSE 2011 fedfsNfsGenFlagSplit: FALSE 2012 fedfsNfsTransFlagRdma: FALSE 2013 fedfsNfsClassSimul: 1 2014 fedfsNfsClassHandle: 0 2015 fedfsNfsClassFileid: 1 2016 fedfsNfsClassWritever: 1 2017 fedfsNfsClassChange: 1 2018 fedfsNfsClassReaddir: 9 2019 fedfsNfsReadRank: 7 2020 fedfsNfsReadOrder: 8 2021 fedfsNfsWriteRank: 5 2022 fedfsNfsWriteOrder: 6 2023 fedfsNfsVarSub: FALSE 2024 fedfsNfsValidFor: 300 2025 fedfsAnnotation: "foo" = "bar" 2026 fedfsDescr: This is a description. 2028 5.1.3.2. Selecting fedfsNfsFsl Values 2030 The fedfsNfsFSl object class is used to describe NFSv4 and NFSv4.1 2031 accessible filesets. For the reasons described in Section 2.8.3, 2032 administrators SHOULD choose reasonable values for all LDAP 2033 attributes of an NFSv4 accessible fedfsNfsFsl even though some of 2034 these LDAP attributes are not explicitly contained in the NFSv4 2035 fs_locations attribute returned to an NFSv4 client. 2037 When the administrator is unable to choose reasonable values for the 2038 LDAP attributes not explicitly contained in a NFSv4 fs_locations 2039 attribute, the values in the following table are RECOMMENDED. 2041 +-------------------------+----------+------------------------------+ 2042 | LDAP attribute | LDAP | Notes | 2043 | | value | | 2044 +-------------------------+----------+------------------------------+ 2045 | fedfsNfsCurrency | negative | Indicates that the server | 2046 | | value | does not know the currency | 2047 | | | (see 11.10.1 of [RFC5661]). | 2048 | fedfsNfsGenFlagWritable | FALSE | Leaving unset is not harmful | 2049 | | | (see 11.10.1 of [RFC5661]). | 2050 | fedfsNfsGenFlagGoing | FALSE | NFS client will detect a | 2051 | | | migration event if the FSL | 2052 | | | becomes unavailable. | 2053 | fedfsNfsGenFlagSplit | TRUE | Safe to assume that the FSL | 2054 | | | is split. | 2055 | fedfsNfsTransFlagRdma | TRUE | NFS client will detect if | 2056 | | | RDMA access is available. | 2057 | fedfsNfsClassSimul | 0 | 0 (zero) is treated as | 2058 | | | non-matching (see 11.10.1 of | 2059 | | | [RFC5661]). | 2060 | fedfsNfsClassHandle | 0 | See fedfsNfsClassSimul note. | 2061 | fedfsNfsClassFileid | 0 | See fedfsNfsClassSimul note. | 2062 | fedfsNfsClassWritever | 0 | See fedfsNfsClassSimul note. | 2063 | fedfsNfsClassChange | 0 | See fedfsNfsClassSimul note. | 2064 | fedfsNfsClassReaddir | 0 | See fedfsNfsClassSimul note. | 2065 | fedfsNfsReadRank | 0 | Highest value ensures FSL | 2066 | | | will be tried. | 2067 | fedfsNfsReadOrder | 0 | See fedfsNfsReadRank note. | 2068 | fedfsNfsWriteRank | 0 | See fedfsNfsReadRank note. | 2069 | fedfsNfsWriteOrder | 0 | See fedfsNfsReadRank note. | 2070 | fedfsNfsVarSub | FALSE | NFSv4 does not define | 2071 | | | variable substituion in | 2072 | | | paths. | 2073 | fedfsNfsValidFor | 0 | Indicates no appropriate | 2074 | | | refetch interval (see | 2075 | | | 11.10.2 of [RFC5661]). | 2076 +-------------------------+----------+------------------------------+ 2078 5.1.4. Delete an FSL 2080 This operation deletes the given Fileset location. The admin 2081 requests the NSDB node storing the fedfsFsl to delete it from its 2082 database. This operation does not result in the fileset location's 2083 data being deleted at the fileserver. 2085 5.1.4.1. LDAP Request 2087 The admin sends an LDAP DELETE request to the NSDB node to remove the 2088 FSL. 2090 dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE 2091 changeType: delete 2093 For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- 2094 00a0c91e6bf6", the $FSLUUID is "84f775a7-8e31-14ae-b39d- 2095 10eeee060d2c", and the $NCE is "o=fedfs", the operation would be (for 2096 readability the DN is split into two lines): 2098 dn: fedfsFslUuid=84f775a7-8e31-14ae-b39d-10eeee060d2c, 2099 fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 2100 changeType: delete 2102 5.1.5. Update an FSL 2104 This operation updates the attributes of a given FSL. This command 2105 results in a change in the attributes of the fedfsFsl at the NSDB 2106 node maintaining this FSL. The attributes that must not change are 2107 the fedfsFslUuid and the fedfsFsnUuid of the fileset this FSL 2108 implements. 2110 5.1.5.1. LDAP Request 2112 The admin sends an LDAP MODIFY request to the NSDB node to update the 2113 FSL. 2115 dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE 2116 changeType: modify 2117 replace: $ATTRIBUTE-TYPE 2119 For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- 2120 00a0c91e6bf6", the $FSLUUID is "84f775a7-8e31-14ae-b39d- 2121 10eeee060d2c", the $NCE is "o=fedfs", and the administrator wished to 2122 change the TTL to 10 minutes, the operation would be (for readability 2123 the DN is split into two lines): 2125 dn: fedfsFslUuid=84f775a7-8e31-14ae-b39d-10eeee060d2c, 2126 fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 2127 changeType: modify 2128 replace: fedfsFslTTL 2129 fedfsFslTTL: 600 2131 5.2. NSDB Operations for Fileservers 2133 5.2.1. NSDB Container Entry (NCE) Enumeration 2135 To find the NCEs for the NSDB foo.example.com, a fileserver would do 2136 the following: 2138 nce_list = empty 2139 connect to the LDAP directory at foo.example.com 2140 for each namingContext value $BAR in the root DSE 2141 /* $BAR is a DN */ 2142 query for a fedfsNcePrefix value at $BAR 2143 /* 2144 * The LDAP URL for this search would be 2145 * 2146 * ldap://foo.example.com:389/$BAR?fedfsNcePrefix?? 2147 * (objectClass=fedfsNsdbContainerInfo) 2148 * 2149 */ 2150 if a fedfsNcePrefix value is found 2151 nce = prepend the fedfsNcePrefix value to $BAR 2152 add nce to the nce_list 2154 5.2.2. Lookup FSLs for an FSN 2156 Using an LDAP search, the fileserver can obtain all of the FSLs for a 2157 given FSN. The FSN's fedfsFsnUuid is used as the search key. The 2158 following examples use the LDAP Universal Resource Identifier (URI) 2159 format defined in [RFC4516]. 2161 To obtain a list of all FSLs for $FSNUUID on the NSDB named 2162 $NSDBNAME, the following search can be used (for readability the URI 2163 is split into two lines): 2165 for each $NCE in nce_list 2166 ldap://$NSDBNAME/fsnUuid=$FSNUUID,$NCE??one? 2167 (objectClass=fedfsFsl) 2169 This search is for the children of the object with DN 2170 "fedfsFsnUuid=$FSNUUID,$NCE" with a filter for 2171 "objectClass=fedfsFsl". The scope value of "one" restricts the 2172 search to the entry's children (rather than the entire subtree below 2173 the entry) and the filter ensures that only FSL entries are returned. 2175 For example if $NSDBNAME is "nsdb.example.com", $FSNUUID is 2176 "f81d4fae-7dec-11d0-a765-00a0c91e6bf6", and $NCE is "o=fedfs", the 2177 search would be (for readability the URI is split into three lines): 2179 ldap://nsdb.example.com/ 2180 fsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 2181 ??one?(objectClass=fedfsFsl) 2183 The following search can be used to obtain only the NFS FSLs for 2184 $FSNUUID on the NSDB named $NSDBNAME (for readability the URI is 2185 split into two lines): 2187 for each $NCE in nce_list 2188 ldap://$NSDBNAME/fsnUuid=$FSNUUID,$NCE??one? 2189 (objectClass=fedfsNfsFsl) 2191 This also searches for the children of the object with DN 2192 "fedfsFsnUuid=$FSNUUID,$NCE", but the filter for "objectClass = 2193 fedfsNfsFsl" restricts the results to only NFS FSLs. 2195 For example if $NSDBNAME is nsdb.example.com, $FSNUUID is f81d4fae- 2196 7dec-11d0-a765-00a0c91e6bf6, and $NCE is "o=fedfs",the search would 2197 be (for readability the URI is split into three lines): 2199 ldap://nsdb.example.com/ 2200 fsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 2201 ??one?(objectClass=fedfsNfsFsl) 2203 The fileserver will generate a referral based on the set of FSLs 2204 returned by these queries using the process described in 2205 Section 2.8.3. 2207 5.3. NSDB Operations and LDAP Referrals 2209 The LDAPv3 protocol defines an LDAP referral mechanism that allows an 2210 LDAP server to redirect an LDAP client. LDAPv3 defines two types of 2211 LDAP referrals: the Referral type defined in Section 4.1.10 of 2212 [RFC4511] and the SearchResultReference type defined in Section 4.5.3 2213 of [RFC4511]. In both cases, the LDAP referral lists one or more 2214 URIs for services that can be used to complete the operation. In the 2215 remainder of this document, the term LDAP referral is used to 2216 indicate either of these types. 2218 If an NSDB operation results in an LDAP referral, the NSDB client MAY 2219 follow the LDAP referral. An NSDB client's decision to follow an 2220 LDAP referral is implementation and configuration dependent. For 2221 example, an NSDB client might be configured to follow only those LDAP 2222 referrals that were received over a secure channel, or only those 2223 that target an NSDB that supports encrypted communication. If an 2224 NSDB client chooses to follow an LDAP referral, the NSDB client MUST 2225 process the LDAP referral and prevent looping as described in Section 2226 4.1.10 of [RFC4511]. 2228 6. Security Considerations 2230 Both NFSv4/NFSv4.1 and LDAP provide security mechanisms. When used 2231 in conjunction with the federated filesystem protocols described in 2232 this document, the use of these mechanisms is RECOMMENDED. 2233 Specifically, the use of RPCSEC_GSS [RFC2203], which is built on the 2234 GSS-API [RFC2743], is RECOMMENDED on all NFS connections between a 2235 client and fileserver. The "Security Considerations" sections of the 2236 the NFSv4 [3530bis] and NFSv4.1 [RFC5661] specifications contain 2237 special considerations for the handling of GETATTR operations for the 2238 fs_locations and fs_locations_info attributes. For all LDAP 2239 connections established by the federated filesystem protocols, the 2240 use of TLS [RFC5246], as described in [RFC4513], is RECOMMENDED. 2242 If an NSDB client chooses to follow an LDAP referral, the NSDB client 2243 SHOULD authenticate the LDAP referral's target NSDB using the target 2244 NSDB's credentials (not the credentials of the NSDB that generated 2245 the LDAP referral). The NSDB client SHOULD NOT follow an LDAP 2246 referral that targets an NSDB for which it does not know the NSDB's 2247 credentials. 2249 Within a federation, there are two types of components an attacker 2250 may compromise: a fileserver and an NSDB. 2252 If an attacker compromises a fileserver, the attacker can interfere 2253 with the client's filesystem I/O operations (e.g. by returning 2254 fictitious data in the response to a read request) or fabricating a 2255 referral. The attacker's abilities are the same regardless of 2256 whether or not the federation protocols are in use. While the 2257 federation protocols do not give the attacker additional 2258 capabilities, they are additional targets for attack. The LDAP 2259 protocol described in Section 5.2 SHOULD be secured using the methods 2260 described above to defeat attacks on a fileserver via this channel. 2262 If an attacker compromises an NSDB, the attacker will be able to 2263 forge FSL information and thus poison the fileserver's referral 2264 information. Therefore an NSDB should be as secure as the 2265 fileservers which query it. The LDAP operations described in 2266 Section 5 SHOULD be secured using the methods described above to 2267 defeat attacks on an NSDB via this channel. 2269 It should be noted that the federation protocols do not directly 2270 provide access to filesystem data. The federation protocols only 2271 provide a mechanism for building a namespace. All data transfers 2272 occur between a client and server just as they would if the 2273 federation protocols were not in use. As a result, the federation 2274 protocols do not require new user authentication and authorization 2275 mechanisms or require a fileserver to act as a proxy for a client. 2277 7. IANA Considerations 2279 Using the process described in [RFC2578], one of the authors was 2280 assigned the Internet Private Enterprise Numbers range 2281 1.3.6.1.4.1.31103.x. Within this range, the subrange 2282 1.3.6.1.4.1.31103.1.x is permanently dedicated for use by the 2283 federated file system protocols. All of the LDAP attributes and 2284 object classes defined in this document are assigned object 2285 identifier (OID) values within the range 1.3.6.1.4.1.31103.1.x. 2287 In accordance with Section 3.4 and Section 4 of [RFC4520], the object 2288 identifier descriptors defined in this document (listed below) will 2289 be registered via the Expert Review process. 2291 7.1. LDAP Descriptor Registration 2292 Subject: Request for LDAP Descriptor Registration 2293 Person & email address to contact for further information: See 2294 "Author/Change Controller" 2295 Specification: draft-ietf-nfsv4-federated-fs-protocol 2296 Author/Change Controller: [document authors] 2298 Object Identifier: 1.3.6.1.4.1.31103.1.1 2299 Descriptor (short name): fedfsUuid 2300 Usage: attribute type 2302 Object Identifier: 1.3.6.1.4.1.31103.1.2 2303 Descriptor (short name): fedfsNetAddr 2304 Usage: attribute type 2306 Object Identifier: 1.3.6.1.4.1.31103.1.3 2307 Descriptor (short name): fedfsNetPort 2308 Usage: attribute type 2310 Object Identifier: 1.3.6.1.4.1.31103.1.4 2311 Descriptor (short name): fedfsFsnUuid 2312 Usage: attribute type 2314 Object Identifier: 1.3.6.1.4.1.31103.1.5 2315 Descriptor (short name): fedfsNsdbName 2316 Usage: attribute type 2318 Object Identifier: 1.3.6.1.4.1.31103.1.6 2319 Descriptor (short name): fedfsNsdbPort 2320 Usage: attribute type 2322 Object Identifier: 1.3.6.1.4.1.31103.1.7 2323 Descriptor (short name): fedfsNcePrefix 2324 Usage: attribute type 2326 Object Identifier: 1.3.6.1.4.1.31103.1.8 2327 Descriptor (short name): fedfsFslUuid 2328 Usage: attribute type 2330 Object Identifier: 1.3.6.1.4.1.31103.1.9 2331 Descriptor (short name): fedfsFslHost 2332 Usage: attribute type 2334 Object Identifier: 1.3.6.1.4.1.31103.1.10 2335 Descriptor (short name): fedfsFslPort 2336 Usage: attribute type 2338 Object Identifier: 1.3.6.1.4.1.31103.1.11 2339 Descriptor (short name): fedfsFslTTL 2340 Usage: attribute type 2342 Object Identifier: 1.3.6.1.4.1.31103.1.12 2343 Descriptor (short name): fedfsAnnotation 2344 Usage: attribute type 2346 Object Identifier: 1.3.6.1.4.1.31103.1.13 2347 Descriptor (short name): fedfsDescr 2348 Usage: attribute type 2350 Object Identifier: 1.3.6.1.4.1.31103.1.100 2351 Descriptor (short name): fedfsNfsPath 2352 Usage: attribute type 2354 Object Identifier: 1.3.6.1.4.1.31103.1.101 2355 Descriptor (short name): fedfsNfsMajorVer 2356 Usage: attribute type 2358 Object Identifier: 1.3.6.1.4.1.31103.1.102 2359 Descriptor (short name): fedfsNfsMinorVer 2360 Usage: attribute type 2362 Object Identifier: 1.3.6.1.4.1.31103.1.103 2363 Descriptor (short name): fedfsNfsCurrency 2364 Usage: attribute type 2366 Object Identifier: 1.3.6.1.4.1.31103.1.104 2367 Descriptor (short name): fedfsNfsGenFlagWritable 2368 Usage: attribute type 2370 Object Identifier: 1.3.6.1.4.1.31103.1.105 2371 Descriptor (short name): fedfsNfsGenFlagGoing 2372 Usage: attribute type 2374 Object Identifier: 1.3.6.1.4.1.31103.1.106 2375 Descriptor (short name): fedfsNfsGenFlagSplit 2376 Usage: attribute type 2378 Object Identifier: 1.3.6.1.4.1.31103.1.107 2379 Descriptor (short name): fedfsNfsTransFlagRdma 2380 Usage: attribute type 2382 Object Identifier: 1.3.6.1.4.1.31103.1.108 2383 Descriptor (short name): fedfsNfsClassSimul 2384 Usage: attribute type 2386 Object Identifier: 1.3.6.1.4.1.31103.1.109 2387 Descriptor (short name): fedfsNfsClassHandle 2388 Usage: attribute type 2390 Object Identifier: 1.3.6.1.4.1.31103.1.110 2391 Descriptor (short name): fedfsNfsClassFileid 2392 Usage: attribute type 2394 Object Identifier: 1.3.6.1.4.1.31103.1.111 2395 Descriptor (short name): fedfsNfsClassWritever 2396 Usage: attribute type 2398 Object Identifier: 1.3.6.1.4.1.31103.1.112 2399 Descriptor (short name): fedfsNfsClassChange 2400 Usage: attribute type 2402 Object Identifier: 1.3.6.1.4.1.31103.1.113 2403 Descriptor (short name): fedfsNfsClassReaddir 2404 Usage: attribute type 2406 Object Identifier: 1.3.6.1.4.1.31103.1.114 2407 Descriptor (short name): fedfsNfsReadRank 2408 Usage: attribute type 2410 Object Identifier: 1.3.6.1.4.1.31103.1.115 2411 Descriptor (short name): fedfsNfsReadOrder 2412 Usage: attribute type 2414 Object Identifier: 1.3.6.1.4.1.31103.1.116 2415 Descriptor (short name): fedfsNfsWriteRank 2416 Usage: attribute type 2418 Object Identifier: 1.3.6.1.4.1.31103.1.117 2419 Descriptor (short name): fedfsNfsWriteOrder 2420 Usage: attribute type 2422 Object Identifier: 1.3.6.1.4.1.31103.1.118 2423 Descriptor (short name): fedfsNfsVarSub 2424 Usage: attribute type 2426 Object Identifier: 1.3.6.1.4.1.31103.1.119 2427 Descriptor (short name): fedfsNfsValidFor 2428 Usage: attribute type 2430 Object Identifier: 1.3.6.1.4.1.31103.1.1001 2431 Descriptor (short name): fedfsNsdbContainerInfo 2432 Usage: object class 2434 Object Identifier: 1.3.6.1.4.1.31103.1.1002 2435 Descriptor (short name): fedfsFsn 2436 Usage: object class 2438 Object Identifier: 1.3.6.1.4.1.31103.1.1003 2439 Descriptor (short name): fedfsFsl 2440 Usage: object class 2442 Object Identifier: 1.3.6.1.4.1.31103.1.1004 2443 Descriptor (short name): fedfsNfsFsl 2444 Usage: object class 2446 8. Glossary 2448 Administrator: user with the necessary authority to initiate 2449 administrative tasks on one or more servers. 2451 Admin Entity: A server or agent that administers a collection of 2452 fileservers and persistently stores the namespace information. 2454 Client: Any client that accesses the fileserver data using a 2455 supported filesystem access protocol. 2457 Federation: A set of server collections and singleton servers that 2458 use a common set of interfaces and protocols in order to provide 2459 to their clients a federated namespace accessible through a 2460 filesystem access protocol. 2462 Fileserver: A server exporting a filesystem via a network filesystem 2463 access protocol. 2465 Fileset: The abstraction of a set of files and the directory tree 2466 that contains them. A fileset is the fundamental unit of data 2467 management in the federation. 2469 Note that all files within a fileset are descendants of one 2470 directory, and that filesets do not span filesystems. 2472 Filesystem: A self-contained unit of export for a fileserver, and 2473 the mechanism used to implement filesets. The fileset does not 2474 need to be rooted at the root of the filesystem, nor at the export 2475 point for the filesystem. 2477 A single filesystem MAY implement more than one fileset, if the 2478 client protocol and the fileserver permit this. 2480 Filesystem Access Protocol: A network filesystem access protocol 2481 such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [3530bis], or CIFS 2482 (Common Internet File System) [MS-SMB] [MS-SMB2] [MS-CIFS]. 2484 FSL (Fileset Location): The location of the implementation of a 2485 fileset at a particular moment in time. An FSL MUST be something 2486 that can be translated into a protocol-specific description of a 2487 resource that a client can access directly, such as an fs_location 2488 (for NFSv4), or share name (for CIFS). Note that not all FSLs 2489 need to be explicitly exported as long as they are contained 2490 within an exported path on the fileserver. 2492 FSN (Fileset Name): A platform-independent and globally unique name 2493 for a fileset. Two FSLs that implement replicas of the same 2494 fileset MUST have the same FSN, and if a fileset is migrated from 2495 one location to another, the FSN of that fileset MUST remain the 2496 same. 2498 Junction: A filesystem object used to link a directory name in the 2499 current fileset with an object within another fileset. The 2500 server-side "link" from a leaf node in one fileset to the root of 2501 another fileset. 2503 Namespace: A filename/directory tree that a sufficiently authorized 2504 client can observe. 2506 NSDB (Namespace Database) Service: A service that maps FSNs to FSLs. 2507 The NSDB may also be used to store other information, such as 2508 annotations for these mappings and their components. 2510 NSDB Node: The name or location of a server that implements part of 2511 the NSDB service and is responsible for keeping track of the FSLs 2512 (and related info) that implement a given partition of the FSNs. 2514 Referral: A server response to a client access that directs the 2515 client to evaluate the current object as a reference to an object 2516 at a different location (specified by an FSL) in another fileset, 2517 and possibly hosted on another fileserver. The client re-attempts 2518 the access to the object at the new location. 2520 Replica: A replica is a redundant implementation of a fileset. Each 2521 replica shares the same FSN, but has a different FSL. 2523 Replicas may be used to increase availability or performance. 2524 Updates to replicas of the same fileset MUST appear to occur in 2525 the same order, and therefore each replica is self-consistent at 2526 any moment. 2528 We do not assume that updates to each replica occur 2529 simultaneously. If a replica is offline or unreachable, the other 2530 replicas may be updated. 2532 Server Collection: A set of fileservers administered as a unit. A 2533 server collection may be administered with vendor-specific 2534 software. 2536 The namespace provided by a server collection could be part of the 2537 federated namespace. 2539 Singleton Server: A server collection containing only one server; a 2540 stand-alone fileserver. 2542 9. References 2544 9.1. Normative References 2546 [3530bis] Haynes, T. and D. Noveck, "NFS Version 4 Protocol", 2547 draft-ietf-nfsv4-rfc3530bis (Work In Progress), 2010. 2549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2550 Requirement Levels", BCP 14, RFC 2119, March 1997. 2552 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 2553 Specification", RFC 2203, September 1997. 2555 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 2556 Schoenwaelder, Ed., "Structure of Management Information 2557 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 2559 [RFC2743] Linn, J., "Generic Security Service Application Program 2560 Interface Version 2, Update 1", RFC 2743, January 2000. 2562 [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - 2563 Technical Specification", RFC 2849, June 2000. 2565 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2566 Resource Identifier (URI): Generic Syntax", STD 66, 2567 RFC 3986, January 2005. 2569 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2570 Unique IDentifier (UUID) URN Namespace", RFC 4122, 2571 July 2005. 2573 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2574 Architecture", RFC 4291, February 2006. 2576 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 2577 (LDAP): Technical Specification Road Map", RFC 4510, 2578 June 2006. 2580 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 2581 (LDAP): The Protocol", RFC 4511, June 2006. 2583 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 2584 (LDAP): Directory Information Models", RFC 4512, 2585 June 2006. 2587 [RFC4513] Harrison, R., "Lightweight Directory Access Protocol 2588 (LDAP): Authentication Methods and Security Mechanisms", 2589 RFC 4513, June 2006. 2591 [RFC4516] Smith, M. and T. Howes, "Lightweight Directory Access 2592 Protocol (LDAP): Uniform Resource Locator", RFC 4516, 2593 June 2006. 2595 [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): 2596 Syntaxes and Matching Rules", RFC 4517, June 2006. 2598 [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol 2599 (LDAP): Schema for User Applications", RFC 4519, 2600 June 2006. 2602 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 2603 Considerations for the Lightweight Directory Access 2604 Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 2606 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2607 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2609 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2610 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2612 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 2613 System (NFS) Version 4 Minor Version 1 Protocol", 2614 RFC 5661, January 2010. 2616 9.2. Informative References 2618 [AFS] Howard, J., "An Overview of the Andrew File System", 2619 Proceeding of the USENIX Winter Technical Conference , 2620 1988. 2622 [FEDFS-ADMIN] 2623 Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. 2624 Naik, "Administration Protocol for Federated Filesystems", 2625 draft-ietf-nfsv4-federated-fs-admin (Work In Progress), 2626 2010. 2628 [FEDFS-DNS-SRV] 2629 Everhart, C., Adamson, W., and J. Zhang, "Using DNS SRV to 2630 Specify a Global File Name Space with NFS version 4", 2631 draft-ietf-nfsv4-federated-fs-dns-srv-namespace (Work In 2632 Progress), 2010. 2634 [MS-CIFS] Microsoft Corporation, "Common Internet File System (CIFS) 2635 Protocol Specification", MS-CIFS 2.0, November 2009. 2637 [MS-SMB] Microsoft Corporation, "Server Message Block (SMB) 2638 Protocol Specification", MS-SMB 17.0, November 2009. 2640 [MS-SMB2] Microsoft Corporation, "Server Message Block (SMB) Version 2641 2 Protocol Specification", MS-SMB2 19.0, November 2009. 2643 [RFC1094] Nowicki, B., "NFS: Network File System Protocol 2644 specification", RFC 1094, March 1989. 2646 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 2647 Version 3 Protocol Specification", RFC 1813, June 1995. 2649 [RFC3254] Alvestrand, H., "Definitions for talking about 2650 directories", RFC 3254, April 2002. 2652 [RFC5662] Shepler, S., Eisler, M., and D. Noveck, "Network File 2653 System (NFS) Version 4 Minor Version 1 External Data 2654 Representation Standard (XDR) Description", RFC 5662, 2655 January 2010. 2657 [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. 2658 Naik, "Requirements for Federated File Systems", RFC 5716, 2659 January 2010. 2661 Appendix A. Acknowledgments 2663 We would like to thank Andy Adamson of NetApp, Paul Lemahieu of EMC, 2664 Robert Thurlow of Sun Microsystems, and Mario Wurzl of EMC for 2665 helping to author this document. 2667 We would also like to thank George Amvrosiadis, Chuck Lever, Trond 2668 Myklebust, and Nicolas Williams for their comments. 2670 The extract.sh shell script and formatting conventions were first 2671 described by the authors of the NFSv4.1 XDR specification [RFC5662]. 2673 Authors' Addresses 2675 James Lentini 2676 NetApp 2677 1601 Trapelo Rd, Suite 16 2678 Waltham, MA 02451 2679 US 2681 Phone: +1 781-768-5359 2682 Email: jlentini@netapp.com 2684 Craig Everhart 2685 NetApp 2686 800 Cranberry Woods Drive 2687 Cranberry Township, PA 16066 2688 US 2690 Phone: +1 724-741-5101 2691 Email: Craig.Everhart@netapp.com 2693 Daniel Ellard 2694 Raytheon BBN Technologies 2695 10 Moulton Street 2696 Cambridge, MA 02138 2697 US 2699 Phone: +1 617-873-8004 2700 Email: dellard@bbn.com 2701 Renu Tewari 2702 IBM Almaden 2703 650 Harry Rd 2704 San Jose, CA 95120 2705 US 2707 Email: tewarir@us.ibm.com 2709 Manoj Naik 2710 IBM Almaden 2711 650 Harry Rd 2712 San Jose, CA 95120 2713 US 2715 Email: manoj@almaden.ibm.com