idnits 2.17.1 draft-ietf-nfsv4-federated-fs-protocol-08.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 (August 18, 2010) is 5000 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 1465 -- Looks like a reference, but probably isn't: '255' on line 1465 ** 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: February 19, 2011 D. Ellard 6 Raytheon BBN Technologies 7 R. Tewari 8 M. Naik 9 IBM Almaden 10 August 18, 2010 12 NSDB Protocol for Federated Filesystems 13 draft-ietf-nfsv4-federated-fs-protocol-08 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 February 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Overview of Features and Concepts . . . . . . . . . . . . . . 5 78 2.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 5 79 2.2. Fileset . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 2.3. Fileset Name (FSN) . . . . . . . . . . . . . . . . . . . . 5 81 2.4. Fileset Location (FSL) . . . . . . . . . . . . . . . . . . 6 82 2.4.1. Mutual Consistency across Fileset Locations . . . . . 6 83 2.4.2. Caching of Fileset Locations . . . . . . . . . . . . . 7 84 2.4.3. Generating A Referral from Fileset Locations . . . . . 8 85 2.5. Namespace Database (NSDB) . . . . . . . . . . . . . . . . 9 86 2.6. Mount Points, Junctions and Referrals . . . . . . . . . . 9 87 2.7. Unified Namespace and the Root Fileset . . . . . . . . . . 10 88 2.8. Fileservers . . . . . . . . . . . . . . . . . . . . . . . 10 89 2.9. File-access Clients . . . . . . . . . . . . . . . . . . . 10 90 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 3.1. Creating a Fileset and its FSL(s) . . . . . . . . . . . . 11 92 3.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 11 93 3.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 12 94 3.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 12 95 3.3. Example Use Cases for Fileset Annotations . . . . . . . . 13 96 4. NSDB Configuration and Schema . . . . . . . . . . . . . . . . 13 97 4.1. LDAP Configuration . . . . . . . . . . . . . . . . . . . . 14 98 4.2. LDAP Schema . . . . . . . . . . . . . . . . . . . . . . . 15 99 4.2.1. LDAP Attributes . . . . . . . . . . . . . . . . . . . 16 100 4.2.2. LDAP Objects . . . . . . . . . . . . . . . . . . . . . 34 101 5. NSDB Operations . . . . . . . . . . . . . . . . . . . . . . . 37 102 5.1. NSDB Operations for Administrators . . . . . . . . . . . . 38 103 5.1.1. Create an FSN . . . . . . . . . . . . . . . . . . . . 39 104 5.1.2. Delete an FSN . . . . . . . . . . . . . . . . . . . . 40 105 5.1.3. Create an FSL . . . . . . . . . . . . . . . . . . . . 40 106 5.1.4. Delete an FSL . . . . . . . . . . . . . . . . . . . . 44 107 5.1.5. Update an FSL . . . . . . . . . . . . . . . . . . . . 44 108 5.2. NSDB Operations for Fileservers . . . . . . . . . . . . . 45 109 5.2.1. NSDB Container Entry (NCE) Enumeration . . . . . . . . 45 110 5.2.2. Lookup FSLs for an FSN . . . . . . . . . . . . . . . . 45 111 6. Security Considerations . . . . . . . . . . . . . . . . . . . 47 112 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 113 7.1. LDAP Descriptor Registration . . . . . . . . . . . . . . . 48 114 8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 115 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 116 9.1. Normative References . . . . . . . . . . . . . . . . . . . 53 117 9.2. Informative References . . . . . . . . . . . . . . . . . . 55 118 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 56 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 121 1. Introduction 123 A federated filesystem enables file access and namespace traversal in 124 a uniform, secure and consistent manner across multiple independent 125 fileservers within an enterprise or across multiple enterprises. 127 This document specifies a set of protocols that allow fileservers, 128 possibly from different vendors and with different administrators, to 129 cooperatively form a federation containing one or more federated 130 filesystems. Each federated filesystem's namespace is composed of 131 the filesystems physically hosted on and exported by the federation's 132 fileservers. A federation MAY contain a common namespace across all 133 its fileservers. A federation MAY project multiple namespaces and 134 enable clients to traverse each one. A federation MAY contain an 135 arbitrary number of namespace repositories, each belonging to a 136 different administrative entity, and each rendering a part of the 137 namespace. A federation MAY also have an arbitrary number of 138 administrative entities responsible for administering disjoint 139 subsets of the fileservers. 141 Traditionally, building a namespace that spans multiple fileservers 142 has been difficult for two reasons. First, the fileservers that 143 export pieces of the namespace are often not in the same 144 administrative domain. Second, there is no standard mechanism for 145 the fileservers to cooperatively present the namespace. Fileservers 146 may provide proprietary management tools and in some cases an 147 administrator may be able to use the proprietary tools to build a 148 shared namespace out of the exported filesystems. However, relying 149 on vendor-specific proprietary tools does not work in larger 150 enterprises or when collaborating across enterprises because the 151 fileservers are likely to be from multiple vendors or use different 152 software versions, each with their own namespace protocols, with no 153 common mechanism to manage the namespace or exchange namespace 154 information. 156 The federated filesystem protocols in this document define how to 157 construct a namespace accessible by an NFSv4 [3530bis] or NFSv4.1 158 [RFC5661] client and have been designed to accommodate other file 159 access protocols in the future. 161 The requirements for federated filesystems are described in 162 [RFC5716]. A protocol for administering a fileserver's namespace is 163 described in [FEDFS-ADMIN]. The mechanism for discovering the root 164 of an NFSv4 namespace is described in [FEDFS-DNS-SRV]. In the rest 165 of the document, the term fileserver denotes a fileserver that is 166 part of a federation. 168 2. Overview of Features and Concepts 170 2.1. Namespace 172 The goal of a unified namespace is to make all managed data available 173 to all clients via the same path in a common filesystem-like 174 namespace. This should be achieved with minimal or zero client 175 configuration. In particular, updates to the common namespace should 176 not require configuration changes at the client. Filesets, which are 177 the unit of data management, are a set of files and directories. 178 From the perspective of the clients, the common namespace is 179 constructed by mounting filesets that are physically located on 180 different fileservers. The namespace, which is defined in terms of 181 fileset definitions, fileset identifiers, the location of each 182 fileset in the namespace, and the physical location of the 183 implementation(s) of each fileset, is stored in a set of namespace 184 repositories, each managed by an administrative entity. The 185 namespace schema defines the model used for populating, modifying, 186 and querying the namespace repositories. It is not required by the 187 federation that the namespace be common across all fileservers. It 188 should be possible to have several independently rooted namespaces. 190 2.2. Fileset 192 A fileset is defined to be a container of data and is the basic unit 193 of data management. Depending on the configuration, they may be 194 anything between an individual directory of an exported filesystem to 195 an entire exported filesystem at a fileserver. 197 2.3. Fileset Name (FSN) 199 A fileset is uniquely represented by its fileset name (FSN). An FSN 200 is considered unique across the federation. After an FSN is created, 201 it is associated with one or more fileset locations (FSLs) on a 202 fileserver. 204 The attributes of an FSN are: 206 NsdbName: the network location of the NSDB node that contains 207 authoritative information for this FSN. 209 FsnUuid: a 128-bit UUID (universally unique identifier), 210 conforming to [RFC4122], that is used to uniquely identify an 211 FSN. 213 2.4. Fileset Location (FSL) 215 An FSL describes the location where the fileset data resides. An FSL 216 contains generic and type specific information which together 217 describe how to access the fileset. An FSL's type indicates which 218 protocol(s) may be used to access its data. An FSL's attributes can 219 be used by a fileserver to decide which locations it will return to a 220 client. 222 All FSLs have the following attributes: 224 FslUuid: a 128-bit UUID, conforming to [RFC4122], that is used to 225 uniquely identify an FSL. 227 FsnUuid: the 128-bit UUID of the FSL's FSN. 229 NsdbName: the network location of the NSDB node that contains 230 authoritative information for this FSL. 232 FslHost: the network location of the host fileserver storing the 233 physical data 235 FslTTL: the time in seconds during which the FSL may be cached 237 Annotations: optional name/value pairs that can be interpreted by 238 a fileserver. The semantics of this field are not defined by 239 this document. These tuples are intended to be used by higher- 240 level protocols. 242 Descriptions: optional text descriptions. The semantics of this 243 field are not defined by this document. 245 This document defines an FSL subtype for NFS. An NFS FSL contains 246 information suitable for use in an NFSv4 fs_locations [3530bis] or 247 NFSv4.1 fs_locations_info attribute [RFC5661]. 249 A fileset MAY be accessible by protocols other than NFS. For each 250 such protocol, a corresponding FSL subtype SHOULD be defined. The 251 contents and format of such FSL subtypes are not defined in this 252 document. 254 2.4.1. Mutual Consistency across Fileset Locations 256 All of the FSLs that have the same FSN (and thereby reference the 257 same fileset) are equivalent from the point of view of client access; 258 the different locations of a fileset represent the same data, though 259 potentially at different points in time. Fileset locations are 260 equivalent but not identical. Locations may either be read-only or 261 read-write. Typically, multiple read-write locations are backed by a 262 clustered filesystem while read-only locations are replicas created 263 by a federation-initiated or external replication operation. Read- 264 only locations may represent consistent point-in-time copies of a 265 read-write location. The federation protocols, however, cannot 266 prevent subsequent changes to a read-only location nor guarantee 267 point-in-time consistency of a read-only location if the read-write 268 location is changing. 270 Regardless of the type, all locations exist at the same mount point 271 in the namespace and, thus, one client may be referred to one 272 location while another is directed to a different location. Since 273 updates to each fileset location are not controlled by the federation 274 protocol, it is the responsibility of administrators to guarantee the 275 functional equivalence of the data. 277 The federation protocol does not guarantee that the different 278 locations are mutually consistent in terms of the currency of the 279 data. It relies on the client file-access protocol (e.g., NFSv4) to 280 contain sufficient information to help the clients determine the 281 currency of the data at each location in order to ensure that the 282 clients do not revert back in time when switching locations. 284 2.4.2. Caching of Fileset Locations 286 To resolve an FSN to a set of FSL records, the fileserver queries the 287 appropriate NSDB for the FSL records. A fileserver MAY cache these 288 FSL records for a limited period of time. The period of time, if 289 any, during which FSL records MAY be cached is indicated by the FSL's 290 TTL field. 292 The combination of FSL caching and FSL migration presents a 293 challenge. For example, suppose there are three fileservers named A, 294 B, and C and fileserver A contains a junction to fileset X stored on 295 fileserver B. Now suppose that fileset X is migrated from fileserver 296 B to fileserver C and the corresponding FSL information for fileset X 297 in the appropriate NSDB is updated. If fileserver A has a cached FSL 298 for fileset X, a user traversing the junction on fileserver A will be 299 referred to fileserver B even though fileset X has migrated to 300 fileserver C. If fileserver A had not cached the FSL record, it would 301 have queried the NSDB and obtained the correct location of fileset X. 303 Administrators are advised to be aware of FSL caching when performing 304 a migration. When migrating a fileset, administrators SHOULD create 305 a junction at the fileset's old location referring back to the NSDB 306 entry for the fileset. This junction will redirect any users who 307 follow stale FSL information to the correct location. Thus, in the 308 above example, fileserver A would direct clients to fileserver B, but 309 fileserver B would in turn direct clients to fileserver C. 311 Such supplemental junctions (on fileserver B in the example) would 312 not be required to be in place forever. They need to stay in place 313 only until cached FSL entries for the target fileset are invalidated. 314 Each FSL contains a TTL field, a count in seconds of the time 315 interval the FSL MAY be cached. This is an upper bound for the 316 lifetime of the cached information and a lower bound for the lifetime 317 of the supplemental junctions. For example, suppose this field 318 contains the value 3600 seconds (one hour). In such a case, 319 administrators MUST keep the supplemental junctions in place for at 320 least one hour after the fileset move has taken place, and FSL data 321 MUST NOT be cached by a referring fileserver for more than one hour 322 without a refresh. 324 2.4.3. Generating A Referral from Fileset Locations 326 After resolving an FSN to a set of FSL records, the fileserver can 327 generate a referral to redirect the client to one or more of the 328 FSLs. The fileserver will convert the FSL records to a referral 329 format understood by the client, such as an NFSv4 fs_locations 330 attribute or NFSv4.1 fs_locations_info attribute. 332 In order to give the client as many options as possible, the 333 fileserver SHOULD include the maximum possible number of FSL records 334 in a referral. However, the fileserver MAY omit some of the FSL 335 records from the referral. For example, the fileserver might omit an 336 FSL record with a different file access protocol from the one in use 337 between the fileserver and client, or the fileserver might omit an 338 FSL record because of limitations in the file access protocol's 339 referral format, or the fileserver might omit an FSL record based on 340 some other criteria. 342 For a given FSL record, the fileserver MAY convert or reduce the FSL 343 record's contents in a manner appropriate to the referral format. 344 For example, an NFS FSL record contains all the data necessary to 345 construct an NFSv4.1 fs_locations_info attribute, but an NFSv4.1 346 fs_locations_info attribute contains several pieces of information 347 that are not found in an NFSv4 fs_locations attribute. A fileserver 348 will construct entries in an NFSv4 fs_locations attribute using the 349 relevant contents of an NFS FSL record. Whenever the fileserver 350 converts or reduces FSL data, the fileserver SHOULD attempt to 351 maintain the original meaning where possible. For example, an NFS 352 FSL record contains the rank and order information that is included 353 in an NFSv4.1 fs_locations_info attribute (see NFSv4.1's 354 FSLI4BX_READRANK, FSLI4BX_READORDER, FSLI4BX_WRITERANK, and 355 FSLI4BX_WRITEORDER). While this rank and order information is not 356 explicitly expressible in an NFSv4 fs_locations attribute, the 357 fileserver can arrange the NFSv4 fs_locations attribute's locations 358 list base on the rank and order values. 360 2.5. Namespace Database (NSDB) 362 The NSDB service is a federation-wide service that provides 363 interfaces to define, update, and query FSN information, FSL 364 information, and FSN to FSL mapping information. An individual 365 repository of namespace information is called an NSDB node. Each 366 NSDB node is managed by a single administrative entity. A single 367 admin entity can manage multiple NSDB nodes. 369 The difference between the NSDB service and an NSDB node is analogous 370 to that between the DNS service and a particular DNS server. 372 Each NSDB node stores the definition of the FSNs for which it is 373 authoritative. It also stores the definitions of the FSLs associated 374 with those FSNs. An NSDB node is authoritative for the filesets that 375 it defines. An NSDB node can cache information from a peer NSDB 376 node. The fileserver can always contact a local NSDB node (if it has 377 been defined) or directly contact any NSDB node to resolve a 378 junction. Each NSDB node supports an LDAP [RFC4510] interface and 379 can be accessed by an LDAP client. 381 An NSDB MAY be replicated throughout the federation. If an NSDB is 382 replicated, the NSDB MUST exhibit loose, converging consistency as 383 defined in [RFC3254]. The mechanism by which this is achieved is 384 outside the scope of this document. Many LDAP implementations 385 support replication. These features MAY be used to replicate the 386 NSDB. 388 2.6. Mount Points, Junctions and Referrals 390 A mount point is a directory in a parent fileset where a target 391 fileset may be attached. If a client traverses the path leading from 392 the root of the namespace to the mount point of a target fileset it 393 should be able to access the data in that target fileset (assuming 394 appropriate permissions). 396 The directory where a fileset is mounted is represented by a junction 397 in the underlying filesystem. In other words, a junction can be 398 viewed as a reference from a directory in one fileset to the root of 399 the target fileset. A junction can be implemented as a special 400 marker on a directory that is interpreted by the fileserver as a 401 mount point, or by some other mechanism in the underlying filesystem. 403 What data is used by the underlying filesystem to represent the 404 junction is not defined by this protocol. The essential property is 405 that the server must be able to find, given the junction, the FSN for 406 the target fileset. The mechanism by which the server maps a 407 junction to an FSN is outside the scope of this document. The FSN 408 (as described earlier) contains the authoritative NSDB node, the 409 optional NSDB search base if one is defined, and the FsnUuid (a UUID 410 for the fileset). 412 When a client traversal reaches a junction, the client is referred to 413 a list of FSLs associated with the FSN targeted by the junction. The 414 client can then redirect its connection to one of the FSLs. This act 415 is called a referral. For NFSv4 and NFSv4.1 clients, the FSL 416 information is returned in the fs_locations and fs_locations_info 417 attributes respectively. 419 The federation protocols do not limit where and how many times a 420 fileset is mounted in the namespace. Filesets can be nested; a 421 fileset can be mounted under another fileset. 423 2.7. Unified Namespace and the Root Fileset 425 The root fileset, when defined, is the top-level fileset of the 426 federation-wide namespace. The root of the unified namespace is the 427 top level directory of this fileset. A set of designated fileservers 428 in the federation can export the root fileset to render the 429 federation-wide unified namespace. When a client mounts the root 430 fileset from any of these designated fileservers it can view a common 431 federation-wide namespace. The root fileset could be implemented 432 either as an exported NFS file system or as data in the NSDB itself. 433 The properties and schema definition of an NSDB-based root fileset 434 and the protocol details that describe how to configure and replicate 435 the root fileset are not defined in this document. 437 2.8. Fileservers 439 Fileservers are servers that store the physical fileset data or refer 440 the client to other fileservers. A fileserver can be implemented in 441 a number of different ways, including a single system, a cluster of 442 systems, or some other configuration. A fileserver provides access 443 to a federated filesystem via NFSv4, NFSv4.1, or some other protocol. 445 2.9. File-access Clients 447 File access clients are standard off-the-shelf network attached 448 storage (NAS) clients that access file data using the NFSv4 protocol, 449 the NFSv4.1 protocol, or some other protocol. 451 3. Examples 453 In this section we provide examples and discussion of the basic 454 operations facilitated by the federated filesystem protocol: creating 455 a fileset, adding a replica of a fileset, resolving a junction, and 456 creating a junction. 458 3.1. Creating a Fileset and its FSL(s) 460 A fileset is the abstraction of a set of files and the directory tree 461 that contains them. The fileset abstraction is the fundamental unit 462 of data management in the federation. This abstraction is 463 implemented by an actual directory tree whose root location is 464 specified by a fileset location (FSL). 466 In this section, we describe the basic requirements for starting with 467 a directory tree and creating a fileset that can be used in the 468 federation protocols. Note that we do not assume that the process of 469 creating a fileset requires any transformation of the files or the 470 directory hierarchy. The only thing that is required by this process 471 is assigning the fileset a fileset name (FSN) and expressing the 472 location of the implementation of the fileset as an FSL. 474 There are many possible variations to this procedure, depending on 475 how the FSN that binds the FSL is created, and whether other replicas 476 of the fileset exist, are known to the federation, and need to be 477 bound to the same FSN. 479 It is easiest to describe this in terms of how to create the initial 480 implementation of the fileset, and then describe how to add replicas. 482 3.1.1. Creating a Fileset and an FSN 484 1. Choose the NSDB node that will keep track of the FSL(s) and 485 related information for the fileset. 487 2. Create an FSN in the NSDB node. 489 The FSN UUID is chosen by the administrator or generated 490 automatically by administration software. The former case is 491 used if the fileset is being restored, perhaps as part of 492 disaster recovery, and the administrator wishes to specify the 493 FSN UUID in order to permit existing junctions that reference 494 that FSN to work again. 496 At this point, the FSN exists, but its fileset locations are 497 unspecified. 499 3. For the FSN created above, create an FSL with the appropriate 500 information in the NSDB node. 502 3.1.2. Adding a Replica of a Fileset 504 Adding a replica is straightforward: the NSDB node and the FSN are 505 already known. The only remaining step is to add another FSL. 507 Note that the federation protocols only provide the mechanisms to 508 register and unregister replicas of a fileset. Fileserver-to- 509 fileserver replication protocols are not defined. 511 3.2. Junction Resolution 513 A fileset may contain references to other filesets. These references 514 are represented by junctions. If a client requests access to a 515 fileset object that is a junction, the fileserver resolves the 516 junction to discover one or more FSLs that implement the referenced 517 fileset. 519 There are many possible variations to this procedure, depending on 520 how the junctions are represented by the fileserver and how the 521 fileserver performs junction resolution. 523 Step 4 is the only step that interacts directly with the federation 524 protocols. The rest of the steps may use platform-specific 525 interfaces. 527 1. The fileserver determines that the object being accessed is a 528 junction. 530 2. The fileserver does a local lookup to find the FSN of the target 531 fileset. 533 3. Using the FSN, the fileserver finds the NSDB node responsible for 534 the target FSN. 536 4. The fileserver contacts that NSDB node and asks for the set of 537 FSLs that implement the target FSN. The NSDB node responds with 538 a (possibly empty) set of FSLs. 540 5. The fileserver converts one or more of the FSLs to the location 541 type used by the client (e.g., a Network File System (NFSv4) 542 fs_location, as described in [3530bis]). 544 6. The fileserver redirects (in whatever manner is appropriate for 545 the client) the client to the location(s). 547 3.3. Example Use Cases for Fileset Annotations 549 Fileset annotations MAY be used to convey additional attributes of a 550 fileset 552 For example, fileset annotations can be used to define relationships 553 between filesets that can be used by an auxiliary replication 554 protocol. Consider the scenario where a fileset is created and 555 mounted at some point in the namespace. A snapshot of the read-write 556 FSL of that fileset is taken periodically at different frequencies 557 say a daily snapshot or a weekly snapshot. The different snapshots 558 are mounted at different locations in the namespace. The daily 559 snapshots are considered as a different fileset from the weekly ones 560 but both are related to the source fileset. For this we can define 561 an annotation labeling the filesets as source and replica. The 562 replication protocol can use this information to copy data from one 563 or more FSLs of the source fileset to all the FSLs of the replica 564 fileset. The replica filesets are read-only while the source fileset 565 is read-write. 567 This follows the traditional Andrew File System (AFS) model of 568 mounting the read-only volume at a path in the namespace different 569 from that of the read-write volume [AFS]. 571 The federation protocol does not control or manage the relationship 572 among filesets. It merely enables annotating the filesets with user- 573 defined relationships. 575 Another potential use for annotations is recording references to an 576 FSN. A single annotation containing the number of references could 577 be defined or multiple annotations, one per reference, could be used 578 to store detailed information on the location of each reference. As 579 with the replication annotation described above, the maintenance of 580 reference information would not be controlled by the federation 581 protocol. The information would mostly likely be non-authoritative 582 because the the ability to create a junction does not require the 583 authority to update the FSN record. In any event, such annotations 584 could be useful to administrators for determining if an FSN is 585 referenced by a junction. 587 4. NSDB Configuration and Schema 589 This section describes how an NSDB is constructed using an LDAP 590 Version 3 [RFC4510] Directory. Section 4.1 describes the basic 591 properties of the LDAP configuration that MUST be used in order to 592 ensure compatibility between different implementations. Section 4.2 593 defines the new LDAP attribute types, the new object types, and 594 specifies how the distinguished name (DN) of each object instance 595 MUST be constructed. 597 4.1. LDAP Configuration 599 An NSDB is constructed using an LDAP Directory. This LDAP Directory 600 MAY have multiple naming contexts. For each naming context, the LDAP 601 Directory's root DSE will have a namingContext attribute. Each 602 namingContext attribute contains the DN of the naming context's root 603 entry. For each naming context that contains federation entries 604 (e.g. FSNs and FSLs): 606 1. There MUST be an LDAP entry that is superior to all of the naming 607 context's federation entries in the Directory Information Tree 608 (DIT) This entry is termed the NSDB Container Entry (NCE). The 609 NCE's children are FSNs. An FSNs children are FSLs. 611 2. The naming context's root entry MUST include the 612 fedfsNsdbContainerInfo (defined below) as one of its object 613 classes. The fedfsNsdbContainerInfo's fedfsNcePrefix attribute 614 is used to locate the naming context's NCE. 616 If a naming context does not contain federation entries, it will not 617 contain an NCE and its root entry will not include a 618 fedfsNsdbContainerInfo as one of its object classes. 620 A fedfsNsdbContainerInfo's fedfsNcePrefix attribute contains a 621 string. Prepending this string to the namingContext value produces 622 the Distinguished Name (DN) of the NSDB Container Entry. An empty 623 fedfsNcePrefix string value indicates that the NSDB Container Entry 624 is the namingContext's root entry. 626 For example, an LDAP directory might have the following entries: 628 -+ [root DSE] 629 | namingContext: o=fedfs 630 | namingContext: dc=example,dc=com 631 | namingContext: ou=system 632 | 633 | 634 +---- [o=fedfs] 635 | fedfsNcePrefix: 636 | 637 | 638 +---- [dc=example,dc=com] 639 | fedfsNcePrefix: ou=fedfs,ou=corp-it 640 | 641 | 642 +---- [ou=system] 644 In this case, the o=fedfs namingContext has an NSBD Container Entry 645 at o=fedfs, the dc=example,dc=com namingContext has an NSDB Container 646 Entry at ou=fedfs,ou=corp-it,dc=example,dc=com, and the ou=system 647 namingContext has no NSDB Container Entry. 649 The NSDB SHOULD be configured with one or more privileged LDAP users. 650 These users are able to modify the contents of the LDAP database. An 651 administrator that performs the operations described in Section 5.1 652 SHOULD authenticate using the DN of a privileged LDAP user. 654 It MUST be possible for an unprivileged (unauthenticated) user to 655 perform LDAP queries that access the NSDB data. A fileserver 656 performs the operations described in Section 5.2 as an unprivileged 657 user. 659 All implementations SHOULD use the same schema, or, at minimum, a 660 schema that includes all of the objects, with each of the attributes, 661 named in the following sections. 663 Given the above configuration guidelines, an NSDB SHOULD be 664 constructed using a dedicated LDAP directory. Separate LDAP 665 directories are RECOMMENDED for other purposes, such as storing user 666 account information. By using an LDAP directory dedicated to storing 667 NSDB records, there is no need to disturb the configuration of any 668 other LDAP directories that store information unrelated to an NSDB. 670 4.2. LDAP Schema 672 The schema definitions provided in this document use the LDAP schema 673 syntax defined in [RFC4512]. The definitions are formatted to allow 674 the reader to easily extract them from the document. The reader can 675 use the following shell script to extract the definitions: 677 679 #!/bin/sh 680 grep '^ *///' | sed 's?^ */// ??' | sed 's?^ *///$??' 682 684 If the above script is stored in a file called "extract.sh", and this 685 document is in a file called "spec.txt", then the reader can do: 687 689 sh extract.sh < spec.txt > fedfs.schema 691 693 The effect of the script is to remove leading white space from each 694 line, plus a sentinel sequence of "///". 696 4.2.1. LDAP Attributes 698 This section describes the required attributes of the NSDB LDAP 699 schema. The following definitions are used below: 701 o The "name" attribute described in [RFC4519]. 703 o The Integer syntax (1.3.6.1.4.1.1466.115.121.1.27) described in 704 [RFC4517]. 706 o The "integerMatch" rule described in [RFC4517]. 708 o The Octet String syntax (1.3.6.1.4.1.1466.115.121.1.40) described 709 in [RFC4517]. 711 o The "octetStringMatch" rule described in [RFC4517]. 713 o The Boolean syntax (1.3.6.1.4.1.1466.115.121.1.7) described in 714 [RFC4517]. 716 o The "booleanMatch" rule described in [RFC4517]. 718 o The "distinguishedNameMatch" rule described in [RFC4517]. 720 o The DN syntax (1.3.6.1.4.1.1466.115.121.1.12) described in 721 [RFC4517]. 723 4.2.1.1. fedfsUuid 725 A fedfsUuid is the base type for all of the universally unique 726 identifiers (UUIDs) used by the federated filesystem protocols. 728 To minimize the probability of two UUIDs colliding, a consistent 729 procedure for generating UUIDs SHOULD be used throughout a 730 federation. Within a federation, UUIDs SHOULD be generated using the 731 procedure described for version 1 of the UUID variant specified in 732 [RFC4122]. 734 The UUID's text representation (as defined in [RFC4122]) SHOULD be 735 encoded as a UTF-8 string. 737 It MAY also be useful, for purposes of debugging or annotation, to 738 permit a fedfsUuid to include members of a more general class of 739 strings. 741 A fedfsUuid is a single-valued LDAP attribute. 743 745 /// 746 /// attributetype ( 747 /// 1.3.6.1.4.1.31103.1.1 NAME 'fedfsUuid' 748 /// DESC 'A UUID used by NSDB' 749 /// SUP name 750 /// SINGLE-VALUE 751 /// ) 752 /// 754 756 4.2.1.2. fedfsNetAddr 758 A fedfsNetAddr is the locative name of a network service in either 759 IPv4, IPv6, or DNS name notation. It MUST be a UTF-8 string and 760 SHOULD be prepared using the server4 rules defined in Chapter 12 761 "Internationalization" of [3530bis]. 763 An IPv4 address MUST be represented using the standard dotted decimal 764 format defined by the IPv4address rule in Section 3.2.2 of RFC 3986 765 [RFC3986]. An IPv6 address MUST be represented using the format 766 defined in Section 2.2 of RFC 4291 [RFC4291]. 768 A DNS name MUST be represented using a fully qualified domain name. 769 A system (i.e. fileserver or administrative host) SHOULD resolve the 770 fully qualified domain name to a network address using the system's 771 standard resolution mechanisms. 773 This attribute is single-valued. 775 776 /// 777 /// attributetype ( 778 /// 1.3.6.1.4.1.31103.1.2 NAME 'fedfsNetAddr' 779 /// DESC 'The network name of a host or service' 780 /// SUP name 781 /// SINGLE-VALUE 782 /// ) 783 /// 785 787 4.2.1.3. fedfsNetPort 789 A fedfsNetPort is the decimal representation of a transport service's 790 port number. A fedfsNetPort MUST be encoded as an Integer syntax 791 value [RFC4517]. 793 This attribute is single-valued. 795 797 /// 798 /// attributetype ( 799 /// 1.3.6.1.4.1.31103.1.3 NAME 'fedfsNetPort' 800 /// DESC 'A transport port number of a service' 801 /// EQUALITY integerMatch 802 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 803 /// SINGLE-VALUE 804 /// ) 805 /// 807 809 4.2.1.4. fedfsFsnUuid 811 A fedfsFsnUuid represents the UUID component of an FSN. An NSDB 812 SHOULD ensure that no two FSNs it stores have the same fedfsFsnUuid. 814 The fedfsFsnUuid is a subclass of fedfsUuid, with the same encoding 815 rules. 817 This attribute is single-valued. 819 820 /// 821 /// attributetype ( 822 /// 1.3.6.1.4.1.31103.1.4 NAME 'fedfsFsnUuid' 823 /// DESC 'The FSN UUID component of an FSN' 824 /// SUP fedfsUuid 825 /// SINGLE-VALUE 826 /// ) 827 /// 829 831 4.2.1.5. fedfsNsdbName 833 A fedfsNsdbName is the NSDB component of an FSN. 835 It MUST be a UTF-8 string containing a DNS name. The DNS name MUST 836 be represented using a fully qualified domain name. A system (i.e. 837 fileserver or administrative host) SHOULD resolve the fully qualified 838 domain name to a network address using the system's standard 839 resolution mechanisms. 841 FSNs are immutable and invariant. The attributes of an FSN, 842 including the fedfsNsdbName, are expected to remain constant. 843 Therefore, a fedfsNsdbName SHOULD NOT contain a network address, such 844 as an IPv4 or IPv6 address, as this would indefinitely assign the 845 network address. 847 This attribute is single-valued. 849 851 /// 852 /// attributetype ( 853 /// 1.3.6.1.4.1.31103.1.5 NAME 'fedfsNsdbName' 854 /// DESC 'The NSDB node component of an FSN' 855 /// SUP name 856 /// SINGLE-VALUE 857 /// ) 858 /// 860 862 4.2.1.6. fedfsNsdbPort 864 A fedfsNsdbPort is the decimal representation of an NSDB's port 865 number. The fedfsNsdbPort attribute is a subclass of fedfsNetPort, 866 with the same encoding rules. 868 This attribute is single-valued. 870 872 /// 873 /// attributetype ( 874 /// 1.3.6.1.4.1.31103.1.6 NAME 'fedfsNsdbPort' 875 /// DESC 'The transport port number of an NSDB' 876 /// SUP fedfsNetPort 877 /// SINGLE-VALUE 878 /// ) 879 /// 881 883 4.2.1.7. fedfsNcePrefix 885 A fedfsNcePrefix stores a distinguished name (DN) prefix. 887 This attribute is single-valued. 889 891 /// 892 /// attributetype ( 893 /// 1.3.6.1.4.1.31103.1.7 NAME 'fedfsNcePrefix' 894 /// DESC 'NCE prefix' 895 /// EQUALITY distinguishedNameMatch 896 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 897 /// SINGLE-VALUE 898 /// ) 899 /// 901 903 OID 1.3.6.1.4.1.1466.115.121.1.12 is the DN syntax [RFC4517]. 905 4.2.1.8. fedfsFslUuid 907 A fedfsFslUuid represents the UUID of an FSL. An NSDB SHOULD ensure 908 that no two FSLs it stores have the same fedfsFslUuid. 910 The fedfsFslUuid attribute is a subclass of fedfsUuid, with the same 911 encoding rules. 913 This attribute is single-valued. 915 916 /// 917 /// attributetype ( 918 /// 1.3.6.1.4.1.31103.1.8 NAME 'fedfsFslUuid' 919 /// DESC 'UUID of an FSL' 920 /// SUP fedfsUuid 921 /// SINGLE-VALUE 922 /// ) 923 /// 925 927 4.2.1.9. fedfsFslHost 929 A fedfsFslHost is the host component of an FSL. The fedfsFslHost 930 attribute is a subclass of fedfsNetAddr, with the same encoding 931 rules. 933 This attribute is single-valued. 935 937 /// 938 /// attributetype ( 939 /// 1.3.6.1.4.1.31103.1.9 NAME 'fedfsFslHost' 940 /// DESC 'Service location for a fileserver' 941 /// SUP fedfsNetAddr 942 /// SINGLE-VALUE 943 /// ) 944 /// 946 948 4.2.1.10. fedfsFslPort 950 A fedfsFslPort is the decimal representation of a file service's port 951 number. The fedfsFslPort attribute is a subclass of fedfsNetPort, 952 with the same encoding rules. 954 This attribute is single-valued. 956 957 /// 958 /// attributetype ( 959 /// 1.3.6.1.4.1.31103.1.10 NAME 'fedfsFslPort' 960 /// DESC 'The file service transport port number' 961 /// SUP fedfsNetPort 962 /// SINGLE-VALUE 963 /// ) 964 /// 966 968 4.2.1.11. fedfsFslTTL 970 A fedfsFslTTL is the amount of time in seconds an FSL SHOULD be 971 cached by a fileserver. A fedfsFslTTL MUST be encoded as an Integer 972 syntax value [RFC4517]. 974 This attribute is single-valued. 976 978 /// 979 /// attributetype ( 980 /// 1.3.6.1.4.1.31103.1.11 NAME 'fedfsFslTTL' 981 /// DESC 'Time to live of an FSL' 982 /// EQUALITY integerMatch 983 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 984 /// SINGLE-VALUE 985 /// ) 986 /// 988 990 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 992 4.2.1.12. fedfsAnnotation 994 A fedfsAnnotation contains an object annotation. 996 This attribute is multi-valued; an object type that permits 997 annotations may have any number of annotations per instance. 999 A fedfsAnnotation attribute MUST be an UTF-8 string formatted as 1000 follows: 1002 "KEY" = "VAL" 1004 White space, defined as space, form-feed ('\f'), newline ('\n'), 1005 carriage return ('\r'), horizontal tab ('\t'), and vertical tab 1006 ('\v') characters, is ignored. 1008 KEY and VAL MAY may contain any UTF-8 characters. The following 1009 escape sequences are allowed: 1011 +-----------------+-------------+ 1012 | escape sequence | replacement | 1013 +-----------------+-------------+ 1014 | \\ | \ | 1015 | \" | " | 1016 +-----------------+-------------+ 1018 A fedfsAnnotation attribute that does not adhere to this format 1019 SHOULD be ignored. 1021 The following are examples of valid fedfsAnnotation attributes: 1023 "key1" = "foo" 1024 "another key" = "x=3" 1025 "key-2" = "A string with \" and \\ characters." 1027 which correspond to the following key/value pairs: 1029 +-------------+-----------------------------------+ 1030 | key | value | 1031 +-------------+-----------------------------------+ 1032 | key1 | foo | 1033 | another key | x=3 | 1034 | key-2 | A string with " and \ characters. | 1035 +-------------+-----------------------------------+ 1037 1039 /// 1040 /// attributetype ( 1041 /// 1.3.6.1.4.1.31103.1.12 NAME 'fedfsAnnotation' 1042 /// DESC 'Annotation of an object' 1043 /// SUP name 1044 /// ) 1045 /// 1047 1049 4.2.1.13. fedfsDescr 1051 A fedfsDescr stores an object description. The description MUST be 1052 encoded as a UTF-8 string. 1054 This attribute is multi-valued which permits any number of 1055 descriptions per entry. 1057 1059 /// 1060 /// attributetype ( 1061 /// 1.3.6.1.4.1.31103.1.13 NAME 'fedfsDescr' 1062 /// DESC 'Description of an object' 1063 /// SUP name 1064 /// ) 1065 /// 1067 1069 4.2.1.14. fedfsNfsPath 1071 A fedfsNfsPath is the path attribute of an FSL. The path MUST be the 1072 XDR encoded NFS path as defined by the NFS pathname4 XDR type of the 1073 fs_location's rootpath [3530bis] and the fs_locations_item's 1074 fli_rootpath [RFC5661]. The NFS pathname4 XDR type is a variable 1075 length array of component4 elements. The NFS component4 XDR type is 1076 a variable length array of opaque data. A fedfsNfsPath attribute's 1077 component4 elements SHOULD be prepared using the component4 rules 1078 defined in Chapter 12 "Internationalization" of [3530bis]. 1080 This attribute is single-valued. 1082 1084 /// 1085 /// attributetype ( 1086 /// 1.3.6.1.4.1.31103.1.100 NAME 'fedfsNfsPath' 1087 /// DESC 'Server-local path to a fileset' 1088 /// EQUALITY octetStringMatch 1089 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 1090 /// SINGLE-VALUE 1091 /// ) 1092 /// 1094 1096 OID 1.3.6.1.4.1.1466.115.121.1.40 is the Octet String syntax 1097 [RFC4517]. 1099 4.2.1.15. fedfsNfsMajorVer 1101 A fedfsNfsMajorVer contains the NFS major version of the associated 1102 NFS FSL. A fedfsNfsMajorVer MUST be encoded as an Integer syntax 1103 value [RFC4517]. 1105 For example if the FSL was exported via NFS 4.1, the contents of this 1106 attribute would be the value 4. 1108 This attribute is single-valued. 1110 1112 /// 1113 /// attributetype ( 1114 /// 1.3.6.1.4.1.31103.1.101 NAME 'fedfsNfsMajorVer' 1115 /// DESC 'NFS major version' 1116 /// EQUALITY integerMatch 1117 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1118 /// SINGLE-VALUE 1119 /// ) 1120 /// 1122 1124 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1126 4.2.1.16. fedfsNfsMinorVer 1128 A fedfsNfsMinorVer contain the NFS minor version of the associated 1129 NFS FSL. A fedfsNfsMinorVer MUST be encoded as an Integer syntax 1130 value [RFC4517]. 1132 For example if the FSL was exported via NFS 4.1, the contents of this 1133 attribute would be the value 1. 1135 This attribute is single-valued. 1137 1139 /// 1140 /// attributetype ( 1141 /// 1.3.6.1.4.1.31103.1.102 NAME 'fedfsNfsMinorVer' 1142 /// DESC 'NFS minor version' 1143 /// EQUALITY integerMatch 1144 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1145 /// SINGLE-VALUE 1146 /// ) 1147 /// 1149 1151 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1153 4.2.1.17. fedfsNfsCurrency 1155 A fedfsNfsCurrency stores the NFSv4.1 fs_locations_server's 1156 fls_currency value [RFC5661]. A fedfsNfsCurrency MUST be encoded as 1157 an Integer syntax value [RFC4517] in the range [-2147483648, 1158 2147483647]. 1160 This attribute is single-valued. 1162 1164 /// 1165 /// attributetype ( 1166 /// 1.3.6.1.4.1.31103.1.103 NAME 'fedfsNfsCurrency' 1167 /// DESC 'up-to-date measure of the data' 1168 /// EQUALITY integerMatch 1169 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1170 /// SINGLE-VALUE 1171 /// ) 1172 /// 1174 1176 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1178 4.2.1.18. fedfsNfsGenFlagWritable 1180 A fedfsNfsGenFlagWritable stores the value of an FSL's NFSv4.1 1181 FSLI4GF_WRITABLE bit [RFC5661]. A value of "TRUE" indicates the bit 1182 is true. A value of "FALSE" indicates the bit is false. 1184 1186 /// 1187 /// attributetype ( 1188 /// 1.3.6.1.4.1.31103.1.104 NAME 'fedfsNfsGenFlagWritable' 1189 /// DESC 'Indicates if the filesystem is writable' 1190 /// EQUALITY booleanMatch 1191 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1192 /// SINGLE-VALUE 1193 /// ) 1194 /// 1196 1198 OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. 1200 4.2.1.19. fedfsNfsGenFlagGoing 1202 A fedfsNfsGenFlagGoing stores the value of an FSL's NFSv4.1 1203 FSLI4GF_GOING bit [RFC5661]. A value of "TRUE" indicates the bit is 1204 true. A value of "FALSE" indicates the bit is false. 1206 1208 /// 1209 /// attributetype ( 1210 /// 1.3.6.1.4.1.31103.1.105 NAME 'fedfsNfsGenFlagGoing' 1211 /// DESC 'Indicates if the filesystem is going' 1212 /// EQUALITY booleanMatch 1213 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1214 /// SINGLE-VALUE 1215 /// ) 1216 /// 1218 1220 OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. 1222 4.2.1.20. fedfsNfsGenFlagSplit 1224 A fedfsNfsGenFlagSplit stores the value of an FSL's NFSv4.1 1225 FSLI4GF_SPLIT bit [RFC5661]. A value of "TRUE" indicates the bit is 1226 true. A value of "FALSE" indicates the bit is false. 1228 1230 /// 1231 /// attributetype ( 1232 /// 1.3.6.1.4.1.31103.1.106 NAME 'fedfsNfsGenFlagSplit' 1233 /// DESC 'Indicates if there are multiple filesystems' 1234 /// EQUALITY booleanMatch 1235 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1236 /// SINGLE-VALUE 1237 /// ) 1238 /// 1240 1242 OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. 1244 4.2.1.21. fedfsNfsTransFlagRdma 1246 A fedfsNfsTransFlagRdma stores the value of an FSL's NFSv4.1 1247 FSLI4TF_RDMA bit [RFC5661]. A value of "TRUE" indicates the bit is 1248 true. A value of "FALSE" indicates the bit is false. 1250 1252 /// 1253 /// attributetype ( 1254 /// 1.3.6.1.4.1.31103.1.107 NAME 'fedfsNfsTransFlagRdma' 1255 /// DESC 'Indicates if the transport supports RDMA' 1256 /// EQUALITY booleanMatch 1257 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1258 /// SINGLE-VALUE 1259 /// ) 1260 /// 1262 1264 OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. 1266 4.2.1.22. fedfsNfsClassSimul 1268 A fedfsNfsClassSimul contains the FSL's NFSv4.1 FSLI4BX_CLSIMUL 1269 [RFC5661] value. A fedfsNfsClassSimul MUST be encoded as an Integer 1270 syntax value [RFC4517] in the range [0, 255]. 1272 1274 /// 1275 /// attributetype ( 1276 /// 1.3.6.1.4.1.31103.1.108 NAME 'fedfsNfsClassSimul' 1277 /// DESC 'The simultaneous-use class of the filesystem' 1278 /// EQUALITY integerMatch 1279 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1280 /// SINGLE-VALUE 1281 /// ) 1282 /// 1284 1286 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1288 4.2.1.23. fedfsNfsClassHandle 1290 A fedfsNfsClassHandle contains the FSL's NFSv4.1 FSLI4BX_CLHANDLE 1291 [RFC5661] value. A fedfsNfsClassHandle MUST be encoded as an Integer 1292 syntax value [RFC4517] in the range [0, 255]. 1294 1296 /// 1297 /// attributetype ( 1298 /// 1.3.6.1.4.1.31103.1.109 NAME 'fedfsNfsClassHandle' 1299 /// DESC 'The handle class of the filesystem' 1300 /// EQUALITY integerMatch 1301 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1302 /// SINGLE-VALUE 1303 /// ) 1304 /// 1306 1308 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1310 4.2.1.24. fedfsNfsClassFileid 1312 A fedfsNfsClassFileid contains the FSL's NFSv4.1 FSLI4BX_CLFILEID 1313 [RFC5661] value. A fedfsNfsClassFileid MUST be encoded as an Integer 1314 syntax value [RFC4517] in the range [0, 255]. 1316 1318 /// 1319 /// attributetype ( 1320 /// 1.3.6.1.4.1.31103.1.110 NAME 'fedfsNfsClassFileid' 1321 /// DESC 'The fileid class of the filesystem' 1322 /// EQUALITY integerMatch 1323 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1324 /// SINGLE-VALUE 1325 /// ) 1326 /// 1328 1330 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1332 4.2.1.25. fedfsNfsClassWritever 1334 A fedfsNfsClassWritever contains the FSL's NFSv4.1 FSLI4BX_CLWRITEVER 1335 [RFC5661] value. A fedfsNfsClassWritever MUST be encoded as an 1336 Integer syntax value [RFC4517] in the range [0, 255]. 1338 1339 /// 1340 /// attributetype ( 1341 /// 1.3.6.1.4.1.31103.1.111 NAME 'fedfsNfsClassWritever' 1342 /// DESC 'The write-verifier class of the filesystem' 1343 /// EQUALITY integerMatch 1344 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1345 /// SINGLE-VALUE 1346 /// ) 1347 /// 1349 1351 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1353 4.2.1.26. fedfsNfsClassChange 1355 A fedfsNfsClassChange contains the FSL's NFSv4.1 FSLI4BX_CLCHANGE 1356 [RFC5661] value. A fedfsNfsClassChange MUST be encoded as an Integer 1357 syntax value [RFC4517] in the range [0, 255]. 1359 1361 /// 1362 /// attributetype ( 1363 /// 1.3.6.1.4.1.31103.1.112 NAME 'fedfsNfsClassChange' 1364 /// DESC 'The change class of the filesystem' 1365 /// EQUALITY integerMatch 1366 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1367 /// SINGLE-VALUE 1368 /// ) 1369 /// 1371 1373 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1375 4.2.1.27. fedfsNfsClassReaddir 1377 A fedfsNfsClassReaddir contains the FSL's NFSv4.1 FSLI4BX_CLREADDIR 1378 [RFC5661] value. A fedfsNfsClassReaddir MUST be encoded as an 1379 Integer syntax value [RFC4517] in the range [0, 255]. 1381 1382 /// 1383 /// attributetype ( 1384 /// 1.3.6.1.4.1.31103.1.113 NAME 'fedfsNfsClassReaddir' 1385 /// DESC 'The readdir class of the filesystem' 1386 /// EQUALITY integerMatch 1387 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1388 /// SINGLE-VALUE 1389 /// ) 1390 /// 1392 1394 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1396 4.2.1.28. fedfsNfsReadRank 1398 A fedfsNfsReadRank contains the FSL's NFSv4.1 FSLI4BX_READRANK 1399 [RFC5661] value. A fedfsNfsReadRank MUST be encoded as an Integer 1400 syntax value [RFC4517] in the range [0, 255]. 1402 1404 /// 1405 /// attributetype ( 1406 /// 1.3.6.1.4.1.31103.1.114 NAME 'fedfsNfsReadRank' 1407 /// DESC 'The read rank of the filesystem' 1408 /// EQUALITY integerMatch 1409 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1410 /// SINGLE-VALUE 1411 /// ) 1412 /// 1414 1416 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1418 4.2.1.29. fedfsNfsReadOrder 1420 A fedfsNfsReadOrder contains the FSL's NFSv4.1 FSLI4BX_READORDER 1421 [RFC5661] value. A fedfsNfsReadOrder MUST be encoded as an Integer 1422 syntax value [RFC4517] in the range [0, 255]. 1424 1425 /// 1426 /// attributetype ( 1427 /// 1.3.6.1.4.1.31103.1.115 NAME 'fedfsNfsReadOrder' 1428 /// DESC 'The read order of the filesystem' 1429 /// EQUALITY integerMatch 1430 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1431 /// SINGLE-VALUE 1432 /// ) 1433 /// 1435 1437 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1439 4.2.1.30. fedfsNfsWriteRank 1441 A fedfsNfsWriteRank contains the FSL's FSLI4BX_WRITERANK [RFC5661] 1442 value. A fedfsNfsWriteRank MUST be encoded as an Integer syntax 1443 value [RFC4517] in the range [0, 255]. 1445 1447 /// 1448 /// attributetype ( 1449 /// 1.3.6.1.4.1.31103.1.116 NAME 'fedfsNfsWriteRank' 1450 /// DESC 'The write rank of the filesystem' 1451 /// EQUALITY integerMatch 1452 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1453 /// SINGLE-VALUE 1454 /// ) 1455 /// 1457 1459 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1461 4.2.1.31. fedfsNfsWriteOrder 1463 A fedfsNfsWriteOrder contains the FSL's FSLI4BX_WRITEORDER [RFC5661] 1464 value. A fedfsNfsWriteOrder MUST be encoded as an Integer syntax 1465 value [RFC4517] in the range [0, 255]. 1467 1468 /// 1469 /// attributetype ( 1470 /// 1.3.6.1.4.1.31103.1.117 NAME 'fedfsNfsWriteOrder' 1471 /// DESC 'The write order of the filesystem' 1472 /// EQUALITY integerMatch 1473 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1474 /// SINGLE-VALUE 1475 /// ) 1476 /// 1478 1480 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1482 4.2.1.32. fedfsNfsVarSub 1484 A fedfsNfsVarSub stores the value of an FSL's NFSv4.1 FSLI4F_VAR_SUB 1485 bit [RFC5661]. A value of "TRUE" indicates the bit is true. A value 1486 of "FALSE" indicates the bit is false. 1488 1490 /// 1491 /// attributetype ( 1492 /// 1.3.6.1.4.1.31103.1.118 NAME 'fedfsNfsVarSub' 1493 /// DESC 'Indicates if variable substitution is present' 1494 /// EQUALITY booleanMatch 1495 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1496 /// SINGLE-VALUE 1497 /// ) 1498 /// 1500 1502 OID 1.3.6.1.4.1.1466.115.121.1.7 is the Boolean syntax [RFC4517]. 1504 4.2.1.33. fedfsNfsValidFor 1506 A fedfsNfsValidFor stores an FSL's NFSv4.1 fs_locations_info 1507 fli_valid_for value [RFC5661]. A fedfsNfsValidFor MUST be encoded as 1508 an Integer syntax value [RFC4517] in the range [-2147483648, 1509 2147483647]. 1511 An FSL's fedfsFslTTL value and fedfsNfsValidFor value MAY be 1512 different. 1514 This attribute is single-valued. 1516 1518 /// 1519 /// attributetype ( 1520 /// 1.3.6.1.4.1.31103.1.19 NAME 'fedfsNfsValidFor' 1521 /// DESC 'Valid for time' 1522 /// EQUALITY integerMatch 1523 /// SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1524 /// SINGLE-VALUE 1525 /// ) 1526 /// 1528 OID 1.3.6.1.4.1.1466.115.121.1.27 is the Integer syntax [RFC4517]. 1530 1532 4.2.2. LDAP Objects 1534 4.2.2.1. fedfsNsdbContainerInfo 1536 A fedfsNsdbContainerInfo describes the location of the NCE. 1538 A fedfsFsn's fedfsNcePrefix attribute is REQUIRED. 1540 A fedfsFsn's fedfsAnnotation and fedfsDescr attributes are OPTIONAL. 1542 1544 /// 1545 /// objectclass ( 1546 /// 1.3.6.1.4.1.31103.1.1001 NAME 'fedfsNsdbContainerInfo' 1547 /// DESC 'Describes NCE location' 1548 /// SUP top AUXILIARY 1549 /// MUST ( 1550 /// fedfsNcePrefix 1551 /// ) 1552 /// MAY ( 1553 /// fedfsAnnotation 1554 /// $ fedfsDescr 1555 /// )) 1556 /// 1558 1560 4.2.2.2. fedfsFsn 1562 A fedfsFsn represents an FSN. 1564 A fedfsFsn's fedfsNsdbName and fedfsFsnUuid attributes are REQUIRED. 1566 A fedfsFsn's fedfsNsdbPort, fedfsAnnotation, and fedfsDescr 1567 attributes are OPTIONAL. 1569 If the fedfsNsdbPort is omitted, the standard LDAP port number, 389, 1570 SHOULD be assumed. 1572 The DN of an FSN is REQUIRED to take the following form: 1573 "fedfsFsnUuid=$FSNUUID,$NCE", where $FSNUUID is the UUID of the FSN 1574 and $NCE is the DN of the NCE ("o=fedfs" by default). Since LDAP 1575 requires a DN to be unique, this ensures that each FSN entry has a 1576 unique UUID value within the LDAP directory. 1578 A fedfsFsn MAY also have additional attributes, but these attributes 1579 MUST NOT be referenced by any part of this document. 1581 1583 /// 1584 /// objectclass ( 1585 /// 1.3.6.1.4.1.31103.1.1002 NAME 'fedfsFsn' 1586 /// DESC 'Represents a fileset' 1587 /// SUP top STRUCTURAL 1588 /// MUST ( 1589 /// fedfsFsnUuid 1590 /// $ fedfsNsdbName 1591 /// ) 1592 /// MAY ( 1593 /// fedfsNsdbPort 1594 /// $ fedfsAnnotation 1595 /// $ fedfsDescr 1596 /// )) 1597 /// 1599 1601 4.2.2.3. fedfsFsl 1603 The fedfsFsl object class represents an FSL. 1605 The fedfsFsl is an abstract object class. Protocol specific subtypes 1606 of this object class are used to store FSL information. The 1607 fedfsNfsFsl object class defined below is used to record an NFS FSL's 1608 location. Other subtypes MAY be defined for other protocols (e.g. 1609 CIFS). 1611 A fedfsFsl's fedfsFslUuid, fedfsFsnUuid, fedfsNsdbName, fedfsFslHost, 1612 and fedfsFslTTL attributes are REQUIRED. 1614 A fedfsFsl's fedfsNsdbPort, fedfsFslPort, fedfsAnnotation, and 1615 fedfsDescr attributes are OPTIONAL. 1617 If the fedfsNsdbPort is omitted, the standard LDAP port number, 389, 1618 SHOULD be assumed. 1620 If the fedfsFslPort is omitted, a standard port number based on the 1621 type of FSL should be assumed. For an NFS FSL, the standard NFS port 1622 number, 2049, SHOULD be assumed. 1624 The DN of an FSL is REQUIRED to take the following form: 1625 "fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE" where $FSLUUID is 1626 the FSL's UUID, $FSNUUID is the FSN's UUID, and $NCE is the DN of the 1627 NCE ("o=fedfs" by default). Since LDAP requires a DN to be unique, 1628 this ensures that each FSL entry has a unique UUID value within the 1629 LDAP directory. 1631 1633 /// 1634 /// objectclass ( 1635 /// 1.3.6.1.4.1.31103.1.1003 NAME 'fedfsFsl' 1636 /// DESC 'A physical location of a fileset' 1637 /// SUP top ABSTRACT 1638 /// MUST ( 1639 /// fedfsFslUuid 1640 /// $ fedfsFsnUuid 1641 /// $ fedfsNsdbName 1642 /// $ fedfsFslHost 1643 /// $ fedfsFslTTL 1644 /// ) 1645 /// MAY ( 1646 /// fedfsNsdbPort 1647 /// $ fedfsFslPort 1648 /// $ fedfsAnnotation 1649 /// $ fedfsDescr 1650 /// )) 1651 /// 1653 1655 4.2.2.4. fedfsNfsFsl 1657 A fedfsNfsFsl is used to represent an NFS FSL. The fedfsNfsFsl 1658 inherits all of the attributes of the fedfsFsl and extends the 1659 fedfsFsl with information specific to the NFS protocol. 1661 The DN of an NFS FSL is REQUIRED to take the following form: 1662 "fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE" where $FSLUUID is 1663 the FSL's UUID, $FSNUUID is the FSN's UUID, and $NCE is the DN of the 1664 NCE ("o=fedfs" by default). Since LDAP requires a DN to be unique, 1665 this ensures that each NFS FSL entry has a unique UUID value within 1666 the LDAP directory. 1668 1670 /// 1671 /// objectclass ( 1672 /// 1.3.6.1.4.1.31103.1.1004 NAME 'fedfsNfsFsl' 1673 /// DESC 'An NFS location of a fileset' 1674 /// SUP fedfsFsl STRUCTURAL 1675 /// MUST ( 1676 /// fedfsNfsPath 1677 /// $ fedfsNfsMajorVer 1678 /// $ fedfsNfsMinorVer 1679 /// $ fedfsNfsCurrency 1680 /// $ fedfsNfsGenFlagWritable 1681 /// $ fedfsNfsGenFlagGoing 1682 /// $ fedfsNfsGenFlagSplit 1683 /// $ fedfsNfsTransFlagRdma 1684 /// $ fedfsNfsClassSimul 1685 /// $ fedfsNfsClassHandle 1686 /// $ fedfsNfsClassFileid 1687 /// $ fedfsNfsClassWritever 1688 /// $ fedfsNfsClassChange 1689 /// $ fedfsNfsClassReaddir 1690 /// $ fedfsNfsReadRank 1691 /// $ fedfsNfsReadOrder 1692 /// $ fedfsNfsWriteRank 1693 /// $ fedfsNfsWriteOrder 1694 /// $ fedfsNfsVarSub 1695 /// $ fedfsNfsValidFor 1696 /// )) 1697 /// 1699 1701 5. NSDB Operations 1703 The operations defined by the protocol can be described as several 1704 sub-protocols that are used by entities within the federation to 1705 perform different roles. 1707 The first of these sub-protocols defines how the state of an NSDB 1708 node can be initialized and updated. The primary use of this sub- 1709 protocol is by an administrator to add, edit, or delete filesets, 1710 their properties, and their fileset locations. 1712 The second of these sub-protocols defines the queries that are sent 1713 to an NSDB node in order to perform resolution (or to find other 1714 information about the data stored within that NSDB node) and the 1715 responses returned by the NSDB node. The primary use of this sub- 1716 protocol is by a fileserver in order to perform resolution, but it 1717 may also be used by an administrator to query the state of the 1718 system. 1720 The first and second sub-protocols are defined as LDAP operations, 1721 using the schema defined in the previous section. If each NSDB node 1722 is a standard LDAP server, then, in theory, it is unnecessary to 1723 describe the LDAP operations in detail, because the operations are 1724 ordinary LDAP operations to query and update records. However, we do 1725 not require that an NSDB node implement a complete LDAP service, and 1726 therefore we define in these sections the minimum level of LDAP 1727 functionality required to implement an NSDB node. 1729 The NSDB sub-protocols are defined in the next two sub-sections. The 1730 descriptions of LDAP messages in these sections use the LDAP Data 1731 Interchange Format (LDIF) [RFC2849]. In order to differentiate 1732 constant and variable strings in the LDIF specifications, variables 1733 are prefixed by a $ character and use all upper case characters. For 1734 example, a variable named FOO would be specified as $FOO. 1736 The third sub-protocol defines the queries and other requests that 1737 are sent to a fileserver in order to get information from it or to 1738 modify the state of the fileserver in a manner related to the 1739 federation protocols. The primary purpose of this protocol is for an 1740 administrator to create or delete a junction or discover related 1741 information about a particular fileserver. 1743 The third sub-protocol is defined as an ONC RPC protocols. The 1744 reason for using ONC RPC instead of LDAP is that all fileservers 1745 support ONC RPC but some do not support an LDAP Directory server. 1747 The ONC RPC administration protocol is defined in [FEDFS-ADMIN]. 1749 5.1. NSDB Operations for Administrators 1751 The admin entity initiates and controls the commands to manage 1752 fileset and namespace information. The admin entity, however, is 1753 stateless. All state is maintained at the NSDB nodes or at the 1754 fileserver. 1756 We require that each NSDB node be able to act as an LDAP server and 1757 that the protocol used for communicating between the admin entity and 1758 each NSDB node is LDAP. 1760 The names we assign to these operations are entirely for the purpose 1761 of exposition in this document, and are not part of the LDAP dialogs. 1763 5.1.1. Create an FSN 1765 This operation creates a new FSN in the NSDB by adding a new fedfsFsn 1766 entry in the NSDB's LDAP directory. 1768 A fedfsFsn entry contains a fedfsFsnUuid and fedfsNsdbName. The 1769 administrator chooses the fedfsFsnUuid and fedfsNsdbName. The 1770 process for choosing the fedfsFsnUuid is described in 1771 Section 4.2.1.1). The fedfsNsdbName is the name of the NSDB node 1772 that will serve as the source of definitive information about the FSN 1773 for the life of the FSN. 1775 The NSDB node that receives the request SHOULD check that 1776 fedfsNsdbName value matches its own value and return an error if it 1777 does not. This is to ensure that an FSN is always created by the 1778 NSDB node encoded within the FSN as its owner. 1780 The NSDB node that receives the request SHOULD check all of the 1781 attributes for validity and consistency, but this is not generally 1782 possible for LDAP servers because the consistency requirements cannot 1783 be expressed in the LDAP schema (although many LDAP servers can be 1784 extended, via plug-ins or other mechanisms, to add functionality 1785 beyond the strict definition of LDAP). 1787 5.1.1.1. LDAP Request 1789 This operation is implemented using the LDAP ADD request described by 1790 the LDIF below. 1792 dn: fedfsFsnUuid=$FSNUUID,$NCE 1793 changeType: add 1794 objectClass: fedfsFsn 1795 fedfsFsnUuid: $FSNUUID 1796 fedfsNsdbName: $NSDBNAME 1798 For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- 1799 00a0c91e6bf6", the $NSDBNAME is "nsdb.example.com", and the $NCE is 1800 "o=fedfs" the operation would be: 1802 dn: fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 1803 changeType: add 1804 objectClass: fedfsFsn 1805 fedfsFsnUuid: f81d4fae-7dec-11d0-a765-00a0c91e6bf6 1806 fedfsNsdbName: nsdb.example.com 1808 5.1.2. Delete an FSN 1810 This operation deletes an FSN by removing a fedfsFsn entry in the 1811 NSDB's LDAP directory. 1813 If the FSN entry being deleted has child FSL entries, this function 1814 MUST return an error. This ensures that the NSDB will not contain 1815 any orphaned FSL entries. A compliant LDAP implementation will meet 1816 this requirement since Section 4.8 of [RFC4511] defines the LDAP 1817 delete operation to only be capable of removing leaf entries. 1819 Note that the FSN delete function only removes the fileset from the 1820 namespace (by removing the records for that FSN from the NSDB node 1821 that receives this request). The fileset and its data are not 1822 deleted. Any junction that has this FSN as its target may continue 1823 to point to this non-existent FSN. A dangling reference may be 1824 detected when a client tries to resolve the target of a junction that 1825 refers to the deleted FSN and the NSDB returns an error. 1827 5.1.2.1. LDAP Request 1829 This operation is implemented using the LDAP DELETE request described 1830 by the LDIF below. 1832 dn: fedfsFsnUuid=$FSNUUID,$NCE 1833 changeType: delete 1835 For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- 1836 00a0c91e6bf6" and $NCE is "o=fedfs", the operation would be: 1838 dn: fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 1839 changeType: delete 1841 5.1.3. Create an FSL 1843 This operation creates a new FSL for the given FSN by adding a new 1844 fedfsFsl entry in the NSDB's LDAP directory. 1846 A fedfsFsl entry contains a fedfsFslUuid, fedfsFsnUuid, 1847 fedfsNsdbName, fedfsFslHost, and fedfsFslTTL. The administrator 1848 chooses the fedfsFslUuid. The process for choosing the fedfsFslUuid 1849 is described in Section 4.2.1.1. The fedfsFsnUuid is the UUID of the 1850 FSL's FSN. The fedfsNsdbName is the name of the NSDB node that 1851 stores definitive information about the FSL's FSN. The fedfsFslHost 1852 value is the network location of the fileserver that stores the FSL. 1853 The fedfsFslTTL is chosen by the administrator as described in 1854 Section 2.4.2. 1856 The administrator will also set additional attributes depending on 1857 the FSL type. 1859 5.1.3.1. LDAP Request 1861 This operation is implemented using the LDAP ADD request described by 1862 the LDIF below (NOTE: the LDIF shows the creation of an NFS FSL) 1864 dn:fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE 1865 changeType: add 1866 objectClass: fedfsNfsFsl 1867 fedfsFslUuid: $FSLUUID 1868 fedfsFsnUuid: $FSNUUID 1869 fedfsNsdbName: $NSDBNAME 1870 fedfsFslHost: $HOST 1871 fedfsFslPort: $PORT 1872 fedfsFslTTL: $TTL 1873 fedfsNfsPath: $PATH 1874 fedfsNfsMajorVer: $MAJOR 1875 fedfsNfsMinorVer: $MINOR 1876 fedfsNfsCurrency: $CURRENCY 1877 fedfsNfsGenFlagWritable: $WRITABLE 1878 fedfsNfsGenFlagGoing: $GOING 1879 fedfsNfsGenFlagSplit: $SPLIT 1880 fedfsNfsTransFlagRdma: $RDMA 1881 fedfsNfsClassSimul: $CLASS_SIMUL 1882 fedfsNfsClassHandle:$CLASS_HANDLE 1883 fedfsNfsClassFileid:$CLASS_FILEID 1884 fedfsNfsClassWritever:$CLASS_WRITEVER 1885 fedfsNfsClassChange: $CLASS_CHANGE 1886 fedfsNfsClassReaddir: $CLASS_READDIR 1887 fedfsNfsReadRank: $READ_RANK 1888 fedfsNfsReadOrder: $READ_ORDER 1889 fedfsNfsWriteRank: $WRITE_RANK 1890 fedfsNfsWriteOrder: $WRITE_ORDER 1891 fedfsNfsVarSub: $VAR_SUB 1892 fedfsNfsValidFor: $TIME 1893 fedfsAnnotation: $ANNOTATION 1894 fedfsDescr: $DESCR 1896 For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- 1897 00a0c91e6bf6", the $FSLUUID is "84f775a7-8e31-14ae-b39d- 1898 10eeee060d2c", the $NSDBNAME is "nsdb.example.com", the $HOST is 1899 "server.example.com", $PORT is "2049", the $TTL is "300" seconds, the 1900 $PATH is stored in the file "/tmp/fsl_path", fileset is exported via 1901 NFSv4.1 ($MAJOR is "4" and $MINOR is "1"), $CURRENCY is "0" (an up to 1902 date copy), the FSL is writable, but not going, split, or accessible 1903 via RDMA, the simultaneous-use class is "1", the handle class is "0", 1904 the fileid class is "1", the write-verifier class is "1", the change 1905 class is "1", the readdir class is "9", the read rank is "7", the 1906 read order is "8", the write rank is "5", the write order is "6", 1907 variable substitution is false, $TIME is "300" seconds, $ANNOTATION 1908 is ""foo" = "bar"", $DESC is "This is a description.", and the $NCE 1909 is "o=fedfs", the operation would be (for readability the DN is split 1910 into two lines): 1912 dn:fedfsFslUuid=84f775a7-8e31-14ae-b39d-10eeee060d2c, 1913 fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 1914 changeType: add 1915 objectClass: fedfsNfsFsl 1916 fedfsFslUuid: 84f775a7-8e31-14ae-b39d-10eeee060d2c 1917 fedfsFsnUuid: f81d4fae-7dec-11d0-a765-00a0c91e6bf6 1918 fedfsNsdbName: nsdb.example.com 1919 fedfsFslHost: server.example.com 1920 fedfsFslPort: 2049 1921 fedfsFslTTL: 300 1922 fedfsNfsPath:< file:///tmp/fsl_path 1923 fedfsNfsMajorVer: 4 1924 fedfsNfsMinorVer: 1 1925 fedfsNfsCurrency: 0 1926 fedfsNfsGenFlagWritable: TRUE 1927 fedfsNfsGenFlagGoing: FALSE 1928 fedfsNfsGenFlagSplit: FALSE 1929 fedfsNfsTransFlagRdma: FALSE 1930 fedfsNfsClassSimul: 1 1931 fedfsNfsClassHandle: 0 1932 fedfsNfsClassFileid: 1 1933 fedfsNfsClassWritever: 1 1934 fedfsNfsClassChange: 1 1935 fedfsNfsClassReaddir: 9 1936 fedfsNfsReadRank: 7 1937 fedfsNfsReadOrder: 8 1938 fedfsNfsWriteRank: 5 1939 fedfsNfsWriteOrder: 6 1940 fedfsNfsVarSub: FALSE 1941 fedfsNfsValidFor: 300 1942 fedfsAnnotation: "foo" = "bar" 1943 fedfsDescr: This is a description. 1945 5.1.3.2. Selecting fedfsNfsFsl Values 1947 The fedfsNfsFSl object class is used to describe NFSv4 and NFSv4.1 1948 accessible filesets. For the reasons described in Section 2.4.3, 1949 administrators SHOULD choose reasonable values for all LDAP 1950 attributes of an NFSv4 accessible fedfsNfsFsl even though some of 1951 these LDAP attributes are not explicitly contained in the NFSv4 1952 fs_locations attribute returned to an NFSv4 client. 1954 When the administrator is unable to choose reasonable values for the 1955 LDAP attributes not explicitly contained in a NFSv4 fs_locations 1956 attribute, the values in the following table are RECOMMENDED. 1958 +-------------------------+----------+------------------------------+ 1959 | LDAP attribute | LDAP | Notes | 1960 | | value | | 1961 +-------------------------+----------+------------------------------+ 1962 | fedfsNfsCurrency | negative | Indicates that the server | 1963 | | value | does not know the currency | 1964 | | | (see 11.10.1 of [RFC5661]). | 1965 | fedfsNfsGenFlagWritable | FALSE | Leaving unset is not harmful | 1966 | | | (see 11.10.1 of [RFC5661]). | 1967 | fedfsNfsGenFlagGoing | FALSE | NFS client will detect a | 1968 | | | migration event if the FSL | 1969 | | | becomes unavailable. | 1970 | fedfsNfsGenFlagSplit | TRUE | Safe to assume that the FSL | 1971 | | | is split. | 1972 | fedfsNfsTransFlagRdma | TRUE | NFS client will detect if | 1973 | | | RDMA access is available. | 1974 | fedfsNfsClassSimul | 0 | 0 (zero) is treated as | 1975 | | | non-matching (see 11.10.1 of | 1976 | | | [RFC5661]). | 1977 | fedfsNfsClassHandle | 0 | See fedfsNfsClassSimul note. | 1978 | fedfsNfsClassFileid | 0 | See fedfsNfsClassSimul note. | 1979 | fedfsNfsClassWritever | 0 | See fedfsNfsClassSimul note. | 1980 | fedfsNfsClassChange | 0 | See fedfsNfsClassSimul note. | 1981 | fedfsNfsClassReaddir | 0 | See fedfsNfsClassSimul note. | 1982 | fedfsNfsReadRank | 0 | Highest value ensures FSL | 1983 | | | will be tried. | 1984 | fedfsNfsReadOrder | 0 | See fedfsNfsReadRank note. | 1985 | fedfsNfsWriteRank | 0 | See fedfsNfsReadRank note. | 1986 | fedfsNfsWriteOrder | 0 | See fedfsNfsReadRank note. | 1987 | fedfsNfsVarSub | FALSE | NFSv4 does not define | 1988 | | | variable substituion in | 1989 | | | paths. | 1990 | fedfsNfsValidFor | 0 | Indicates no appropriate | 1991 | | | refetch interval (see | 1992 | | | 11.10.2 of [RFC5661]). | 1993 +-------------------------+----------+------------------------------+ 1995 5.1.4. Delete an FSL 1997 This operation deletes the given Fileset location. The admin 1998 requests the NSDB node storing the fedfsFsl to delete it from its 1999 database. This operation does not result in the fileset location's 2000 data being deleted at the fileserver. 2002 5.1.4.1. LDAP Request 2004 The admin sends an LDAP DELETE request to the NSDB node to remove the 2005 FSL. 2007 dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE 2008 changeType: delete 2010 For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- 2011 00a0c91e6bf6", the $FSLUUID is "84f775a7-8e31-14ae-b39d- 2012 10eeee060d2c", and the $NCE is "o=fedfs", the operation would be (for 2013 readability the DN is split into two lines): 2015 dn: fedfsFslUuid=84f775a7-8e31-14ae-b39d-10eeee060d2c, 2016 fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 2017 changeType: delete 2019 5.1.5. Update an FSL 2021 This operation updates the attributes of a given FSL. This command 2022 results in a change in the attributes of the fedfsFsl at the NSDB 2023 node maintaining this FSL. The attributes that must not change are 2024 the fedfsFslUuid and the fedfsFsnUuid of the fileset this FSL 2025 implements. 2027 5.1.5.1. LDAP Request 2029 The admin sends an LDAP MODIFY request to the NSDB node to update the 2030 FSL. 2032 dn: fedfsFslUuid=$FSLUUID,fedfsFsnUuid=$FSNUUID,$NCE 2033 changeType: modify 2034 replace: $ATTRIBUTE-TYPE 2036 For example, if the $FSNUUID is "f81d4fae-7dec-11d0-a765- 2037 00a0c91e6bf6", the $FSLUUID is "84f775a7-8e31-14ae-b39d- 2038 10eeee060d2c", the $NCE is "o=fedfs", and the administrator wished to 2039 change the TTL to 10 minutes, the operation would be (for readability 2040 the DN is split into two lines): 2042 dn: fedfsFslUuid=84f775a7-8e31-14ae-b39d-10eeee060d2c, 2043 fedfsFsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 2044 changeType: modify 2045 replace: fedfsFslTTL 2046 fedfsFslTTL: 600 2048 5.2. NSDB Operations for Fileservers 2050 5.2.1. NSDB Container Entry (NCE) Enumeration 2052 To find the NCEs for the NSDB foo.example.com, a fileserver would do 2053 the following: 2055 nce_list = empty 2056 connect to the LDAP directory at foo.example.com 2057 for each namingContext value $BAR in the root DSE 2058 /* $BAR is a DN */ 2059 query for a fedfsNcePrefix value at $BAR 2060 /* 2061 * The LDAP URL for this search would be 2062 * 2063 * ldap://foo.example.com:389/$BAR?fedfsNcePrefix?? 2064 * (objectClass=fedfsNsdbContainerInfo) 2065 * 2066 */ 2067 if a fedfsNcePrefix value is found 2068 nce = prepend the fedfsNcePrefix value to $BAR 2069 add nce to the nce_list 2071 5.2.2. Lookup FSLs for an FSN 2073 Using an LDAP search, the fileserver can obtain all of the FSLs for a 2074 given FSN. The FSN's fedfsFsnUuid is used as the search key. The 2075 following examples use the LDAP URI format defined in [RFC4516]. 2077 To obtain a list of all FSLs for $FSNUUID on the NSDB named 2078 $NSDBNAME, the following search can be used (for readability the URI 2079 is split into two lines): 2081 for each $NCE in nce_list 2082 ldap://$NSDBNAME/fsnUuid=$FSNUUID,$NCE??one? 2083 (objectClass=fedfsFsl) 2085 This search is for the children of the object with DN 2086 "fedfsFsnUuid=$FSNUUID,$NCE" with a filter for 2087 "objectClass=fedfsFsl". The scope value of "one" restricts the 2088 search to the entry's children (rather than the entire subtree below 2089 the entry) and the filter ensures that only FSL entries are returned. 2091 For example if $NSDBNAME is "nsdb.example.com", $FSNUUID is 2092 "f81d4fae-7dec-11d0-a765-00a0c91e6bf6", and $NCE is "o=fedfs", the 2093 search would be (for readability the URI is split into three lines): 2095 ldap://nsdb.example.com/ 2096 fsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 2097 ??one?(objectClass=fedfsFsl) 2099 The following search can be used to obtain only the NFS FSLs for 2100 $FSNUUID on the NSDB named $NSDBNAME (for readability the URI is 2101 split into two lines): 2103 for each $NCE in nce_list 2104 ldap://$NSDBNAME/fsnUuid=$FSNUUID,$NCE??one? 2105 (objectClass=fedfsNfsFsl) 2107 This also searches for the children of the object with DN 2108 "fedfsFsnUuid=$FSNUUID,$NCE", but the filter for "objectClass = 2109 fedfsNfsFsl" restricts the results to only NFS FSLs. 2111 For example if $NSDBNAME is nsdb.example.com, $FSNUUID is f81d4fae- 2112 7dec-11d0-a765-00a0c91e6bf6, and $NCE is "o=fedfs",the search would 2113 be (for readability the URI is split into three lines): 2115 ldap://nsdb.example.com/ 2116 fsnUuid=f81d4fae-7dec-11d0-a765-00a0c91e6bf6,o=fedfs 2117 ??one?(objectClass=fedfsNfsFsl) 2119 The fileserver will generate a referral based on the set of FSLs 2120 returned by these queries using the process described in 2121 Section 2.4.3. 2123 6. Security Considerations 2125 Both NFSv4/NFSv4.1 and LDAP provide security mechanisms. When used 2126 in conjunction with the federated filesystem protocols described in 2127 this document, the use of these mechanisms is RECOMMENDED. 2128 Specifically, the use of RPCSEC_GSS [RFC2203], which is built on the 2129 GSS-API [RFC2743], is RECOMMENDED on all NFS connections between a 2130 client and fileserver. The "Security Considerations" sections of the 2131 the NFSv4 [3530bis] and NFSv4.1 [RFC5661] specifications contain 2132 special considerations for the handling of GETATTR operations for the 2133 fs_locations and fs_locations_info attributes. For all LDAP 2134 connections established by the federated filesystem protocols, the 2135 use of TLS [RFC5246], as described in [RFC4513], is RECOMMENDED. 2137 Within a federation, there are two types of components an attacker 2138 may compromise: a fileserver and an NSDB. 2140 If an attacker compromises a fileserver, the attacker can interfere 2141 with the client's filesystem I/O operations (e.g. by returning 2142 fictitious data in the response to a read request) or fabricating a 2143 referral. The attacker's abilities are the same regardless of 2144 whether or not the federation protocols are in use. While the 2145 federation protocols do not give the attacker additional 2146 capabilities, they are additional targets for attack. The LDAP 2147 protocol described in Section 5.2 SHOULD be secured using the methods 2148 described above to defeat attacks on a fileserver via this channel. 2150 If an attacker compromises an NSDB, the attacker will be able to 2151 forge FSL information and thus poison the fileserver's referral 2152 information. Therefore an NSDB should be as secure as the 2153 fileservers which query it. The LDAP operations described in 2154 Section 5 SHOULD be secured using the methods described above to 2155 defeat attacks on an NSDB via this channel. 2157 It should be noted that the federation protocols do not directly 2158 provide access to filesystem data. The federation protocols only 2159 provide a mechanism for building a namespace. All data transfers 2160 occur between a client and server just as they would if the 2161 federation protocols were not in use. As a result, the federation 2162 protocols do not require new user authentication and authorization 2163 mechanisms or require a fileserver to act as a proxy for a client. 2165 7. IANA Considerations 2167 The LDAP attributes and object classes defined in this document are 2168 assigned object identifier (OID) values from the 1.3.6.1.4.1.31103.x 2169 range. This is an Internet Private Enterprise Numbers range and was 2170 assigned to the authors using the process described in [RFC2578]. 2172 In accordance with Section 3.4 and Section 4 of [RFC4520], the object 2173 identifier descriptors defined in this document (listed below) will 2174 be registered via the Expert Review process. 2176 7.1. LDAP Descriptor Registration 2178 Subject: Request for LDAP Descriptor Registration 2179 Person & email address to contact for further information: See 2180 "Author/Change Controller" 2181 Specification: draft-ietf-nfsv4-federated-fs-protocol 2182 Author/Change Controller: [document authors] 2184 Object Identifier: 1.3.6.1.4.1.31103.1.1 2185 Descriptor (short name): fedfsUuid 2186 Usage: attribute type 2188 Object Identifier: 1.3.6.1.4.1.31103.1.2 2189 Descriptor (short name): fedfsNetAddr 2190 Usage: attribute type 2192 Object Identifier: 1.3.6.1.4.1.31103.1.3 2193 Descriptor (short name): fedfsNetPort 2194 Usage: attribute type 2196 Object Identifier: 1.3.6.1.4.1.31103.1.4 2197 Descriptor (short name): fedfsFsnUuid 2198 Usage: attribute type 2200 Object Identifier: 1.3.6.1.4.1.31103.1.5 2201 Descriptor (short name): fedfsNsdbName 2202 Usage: attribute type 2204 Object Identifier: 1.3.6.1.4.1.31103.1.6 2205 Descriptor (short name): fedfsNsdbPort 2206 Usage: attribute type 2208 Object Identifier: 1.3.6.1.4.1.31103.1.7 2209 Descriptor (short name): fedfsNcePrefix 2210 Usage: attribute type 2212 Object Identifier: 1.3.6.1.4.1.31103.1.8 2213 Descriptor (short name): fedfsFslUuid 2214 Usage: attribute type 2216 Object Identifier: 1.3.6.1.4.1.31103.1.9 2217 Descriptor (short name): fedfsFslHost 2218 Usage: attribute type 2220 Object Identifier: 1.3.6.1.4.1.31103.1.10 2221 Descriptor (short name): fedfsFslPort 2222 Usage: attribute type 2224 Object Identifier: 1.3.6.1.4.1.31103.1.11 2225 Descriptor (short name): fedfsFslTTL 2226 Usage: attribute type 2228 Object Identifier: 1.3.6.1.4.1.31103.1.12 2229 Descriptor (short name): fedfsAnnotation 2230 Usage: attribute type 2232 Object Identifier: 1.3.6.1.4.1.31103.1.13 2233 Descriptor (short name): fedfsDescr 2234 Usage: attribute type 2236 Object Identifier: 1.3.6.1.4.1.31103.1.100 2237 Descriptor (short name): fedfsNfsPath 2238 Usage: attribute type 2240 Object Identifier: 1.3.6.1.4.1.31103.1.101 2241 Descriptor (short name): fedfsNfsMajorVer 2242 Usage: attribute type 2244 Object Identifier: 1.3.6.1.4.1.31103.1.102 2245 Descriptor (short name): fedfsNfsMinorVer 2246 Usage: attribute type 2248 Object Identifier: 1.3.6.1.4.1.31103.1.103 2249 Descriptor (short name): fedfsNfsCurrency 2250 Usage: attribute type 2252 Object Identifier: 1.3.6.1.4.1.31103.1.104 2253 Descriptor (short name): fedfsNfsGenFlagWritable 2254 Usage: attribute type 2256 Object Identifier: 1.3.6.1.4.1.31103.1.105 2257 Descriptor (short name): fedfsNfsGenFlagGoing 2258 Usage: attribute type 2260 Object Identifier: 1.3.6.1.4.1.31103.1.106 2261 Descriptor (short name): fedfsNfsGenFlagSplit 2262 Usage: attribute type 2264 Object Identifier: 1.3.6.1.4.1.31103.1.107 2265 Descriptor (short name): fedfsNfsTransFlagRdma 2266 Usage: attribute type 2268 Object Identifier: 1.3.6.1.4.1.31103.1.108 2269 Descriptor (short name): fedfsNfsClassSimul 2270 Usage: attribute type 2272 Object Identifier: 1.3.6.1.4.1.31103.1.109 2273 Descriptor (short name): fedfsNfsClassHandle 2274 Usage: attribute type 2276 Object Identifier: 1.3.6.1.4.1.31103.1.110 2277 Descriptor (short name): fedfsNfsClassFileid 2278 Usage: attribute type 2280 Object Identifier: 1.3.6.1.4.1.31103.1.111 2281 Descriptor (short name): fedfsNfsClassWritever 2282 Usage: attribute type 2284 Object Identifier: 1.3.6.1.4.1.31103.1.112 2285 Descriptor (short name): fedfsNfsClassChange 2286 Usage: attribute type 2288 Object Identifier: 1.3.6.1.4.1.31103.1.113 2289 Descriptor (short name): fedfsNfsClassReaddir 2290 Usage: attribute type 2292 Object Identifier: 1.3.6.1.4.1.31103.1.114 2293 Descriptor (short name): fedfsNfsReadRank 2294 Usage: attribute type 2296 Object Identifier: 1.3.6.1.4.1.31103.1.115 2297 Descriptor (short name): fedfsNfsReadOrder 2298 Usage: attribute type 2300 Object Identifier: 1.3.6.1.4.1.31103.1.116 2301 Descriptor (short name): fedfsNfsWriteRank 2302 Usage: attribute type 2304 Object Identifier: 1.3.6.1.4.1.31103.1.117 2305 Descriptor (short name): fedfsNfsWriteOrder 2306 Usage: attribute type 2308 Object Identifier: 1.3.6.1.4.1.31103.1.118 2309 Descriptor (short name): fedfsNfsVarSub 2310 Usage: attribute type 2312 Object Identifier: 1.3.6.1.4.1.31103.1.119 2313 Descriptor (short name): fedfsNfsValidFor 2314 Usage: attribute type 2316 Object Identifier: 1.3.6.1.4.1.31103.1.1001 2317 Descriptor (short name): fedfsNsdbContainerInfo 2318 Usage: object class 2320 Object Identifier: 1.3.6.1.4.1.31103.1.1002 2321 Descriptor (short name): fedfsFsn 2322 Usage: object class 2324 Object Identifier: 1.3.6.1.4.1.31103.1.1003 2325 Descriptor (short name): fedfsFsl 2326 Usage: object class 2328 Object Identifier: 1.3.6.1.4.1.31103.1.1004 2329 Descriptor (short name): fedfsNfsFsl 2330 Usage: object class 2332 8. Glossary 2334 Administrator: user with the necessary authority to initiate 2335 administrative tasks on one or more servers. 2337 Admin Entity: A server or agent that administers a collection of 2338 fileservers and persistently stores the namespace information. 2340 Client: Any client that accesses the fileserver data using a 2341 supported filesystem access protocol. 2343 Federation: A set of server collections and singleton servers that 2344 use a common set of interfaces and protocols in order to provide 2345 to their clients a federated namespace accessible through a 2346 filesystem access protocol. 2348 Fileserver: A server exporting a filesystem via a network filesystem 2349 access protocol. 2351 Fileset: The abstraction of a set of files and the directory tree 2352 that contains them. A fileset is the fundamental unit of data 2353 management in the federation. 2355 Note that all files within a fileset are descendants of one 2356 directory, and that filesets do not span filesystems. 2358 Filesystem: A self-contained unit of export for a fileserver, and 2359 the mechanism used to implement filesets. The fileset does not 2360 need to be rooted at the root of the filesystem, nor at the export 2361 point for the filesystem. 2363 A single filesystem MAY implement more than one fileset, if the 2364 client protocol and the fileserver permit this. 2366 Filesystem Access Protocol: A network filesystem access protocol 2367 such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [3530bis], or CIFS 2368 (Common Internet File System) [MS-SMB] [MS-SMB2] [MS-CIFS]. 2370 FSL (Fileset Location): The location of the implementation of a 2371 fileset at a particular moment in time. An FSL MUST be something 2372 that can be translated into a protocol-specific description of a 2373 resource that a client can access directly, such as an fs_location 2374 (for NFSv4), or share name (for CIFS). Note that not all FSLs 2375 need to be explicitly exported as long as they are contained 2376 within an exported path on the fileserver. 2378 FSN (Fileset Name): A platform-independent and globally unique name 2379 for a fileset. Two FSLs that implement replicas of the same 2380 fileset MUST have the same FSN, and if a fileset is migrated from 2381 one location to another, the FSN of that fileset MUST remain the 2382 same. 2384 Junction: A filesystem object used to link a directory name in the 2385 current fileset with an object within another fileset. The 2386 server-side "link" from a leaf node in one fileset to the root of 2387 another fileset. 2389 Namespace: A filename/directory tree that a sufficiently authorized 2390 client can observe. 2392 NSDB (Namespace Database) Service: A service that maps FSNs to FSLs. 2393 The NSDB may also be used to store other information, such as 2394 annotations for these mappings and their components. 2396 NSDB Node: The name or location of a server that implements part of 2397 the NSDB service and is responsible for keeping track of the FSLs 2398 (and related info) that implement a given partition of the FSNs. 2400 Referral: A server response to a client access that directs the 2401 client to evaluate the current object as a reference to an object 2402 at a different location (specified by an FSL) in another fileset, 2403 and possibly hosted on another fileserver. The client re-attempts 2404 the access to the object at the new location. 2406 Replica: A replica is a redundant implementation of a fileset. Each 2407 replica shares the same FSN, but has a different FSL. 2409 Replicas may be used to increase availability or performance. 2410 Updates to replicas of the same fileset MUST appear to occur in 2411 the same order, and therefore each replica is self-consistent at 2412 any moment. 2414 We do not assume that updates to each replica occur 2415 simultaneously. If a replica is offline or unreachable, the other 2416 replicas may be updated. 2418 Server Collection: A set of fileservers administered as a unit. A 2419 server collection may be administered with vendor-specific 2420 software. 2422 The namespace provided by a server collection could be part of the 2423 federated namespace. 2425 Singleton Server: A server collection containing only one server; a 2426 stand-alone fileserver. 2428 9. References 2430 9.1. Normative References 2432 [3530bis] Haynes, T. and D. Noveck, "NFS Version 4 Protocol", 2433 draft-ietf-nfsv4-rfc3530bis (Work In Progress), 2010. 2435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2436 Requirement Levels", BCP 14, RFC 2119, March 1997. 2438 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 2439 Specification", RFC 2203, September 1997. 2441 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 2442 Schoenwaelder, Ed., "Structure of Management Information 2443 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 2445 [RFC2743] Linn, J., "Generic Security Service Application Program 2446 Interface Version 2, Update 1", RFC 2743, January 2000. 2448 [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - 2449 Technical Specification", RFC 2849, June 2000. 2451 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2452 Resource Identifier (URI): Generic Syntax", STD 66, 2453 RFC 3986, January 2005. 2455 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2456 Unique IDentifier (UUID) URN Namespace", RFC 4122, 2457 July 2005. 2459 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2460 Architecture", RFC 4291, February 2006. 2462 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 2463 (LDAP): Technical Specification Road Map", RFC 4510, 2464 June 2006. 2466 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 2467 (LDAP): The Protocol", RFC 4511, June 2006. 2469 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 2470 (LDAP): Directory Information Models", RFC 4512, 2471 June 2006. 2473 [RFC4513] Harrison, R., "Lightweight Directory Access Protocol 2474 (LDAP): Authentication Methods and Security Mechanisms", 2475 RFC 4513, June 2006. 2477 [RFC4516] Smith, M. and T. Howes, "Lightweight Directory Access 2478 Protocol (LDAP): Uniform Resource Locator", RFC 4516, 2479 June 2006. 2481 [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): 2482 Syntaxes and Matching Rules", RFC 4517, June 2006. 2484 [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol 2485 (LDAP): Schema for User Applications", RFC 4519, 2486 June 2006. 2488 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 2489 Considerations for the Lightweight Directory Access 2490 Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 2492 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2493 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2495 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 2496 System (NFS) Version 4 Minor Version 1 Protocol", 2497 RFC 5661, January 2010. 2499 9.2. Informative References 2501 [AFS] Howard, J., "An Overview of the Andrew File System", 2502 Proceeding of the USENIX Winter Technical Conference , 2503 1988. 2505 [FEDFS-ADMIN] 2506 Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. 2507 Naik, "Administration Protocol for Federated Filesystems", 2508 draft-ietf-nfsv4-federated-fs-admin (Work In Progress), 2509 2010. 2511 [FEDFS-DNS-SRV] 2512 Everhart, C., Adamson, W., and J. Zhang, "Using DNS SRV to 2513 Specify a Global File Name Space with NFS version 4", 2514 draft-ietf-nfsv4-federated-fs-dns-srv-namespace (Work In 2515 Progress), 2010. 2517 [MS-CIFS] Microsoft Corporation, "Common Internet File System (CIFS) 2518 Protocol Specification", MS-CIFS 2.0, November 2009. 2520 [MS-SMB] Microsoft Corporation, "Server Message Block (SMB) 2521 Protocol Specification", MS-SMB 17.0, November 2009. 2523 [MS-SMB2] Microsoft Corporation, "Server Message Block (SMB) Version 2524 2 Protocol Specification", MS-SMB2 19.0, November 2009. 2526 [RFC1094] Nowicki, B., "NFS: Network File System Protocol 2527 specification", RFC 1094, March 1989. 2529 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 2530 Version 3 Protocol Specification", RFC 1813, June 1995. 2532 [RFC3254] Alvestrand, H., "Definitions for talking about 2533 directories", RFC 3254, April 2002. 2535 [RFC5662] Shepler, S., Eisler, M., and D. Noveck, "Network File 2536 System (NFS) Version 4 Minor Version 1 External Data 2537 Representation Standard (XDR) Description", RFC 5662, 2538 January 2010. 2540 [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. 2541 Naik, "Requirements for Federated File Systems", RFC 5716, 2542 January 2010. 2544 Appendix A. Acknowledgments 2546 We would like to thank Andy Adamson of NetApp, Paul Lemahieu of EMC, 2547 Robert Thurlow of Sun Microsystems, and Mario Wurzl of EMC for 2548 helping to author this document. 2550 We would also like to thank George Amvrosiadis, Chuck Lever, Trond 2551 Myklebust, and Nicolas Williams for their comments. 2553 The extract.sh shell script and formatting conventions were first 2554 described by the authors of the NFSv4.1 XDR specification [RFC5662]. 2556 Authors' Addresses 2558 James Lentini 2559 NetApp 2560 1601 Trapelo Rd, Suite 16 2561 Waltham, MA 02451 2562 US 2564 Phone: +1 781-768-5359 2565 Email: jlentini@netapp.com 2567 Craig Everhart 2568 NetApp 2569 7301 Kit Creek Rd 2570 Research Triangle Park, NC 27709 2571 US 2573 Phone: +1 919-476-5320 2574 Email: everhart@netapp.com 2575 Daniel Ellard 2576 Raytheon BBN Technologies 2577 10 Moulton Street 2578 Cambridge, MA 02138 2579 US 2581 Phone: +1 617-873-8004 2582 Email: dellard@bbn.com 2584 Renu Tewari 2585 IBM Almaden 2586 650 Harry Rd 2587 San Jose, CA 95120 2588 US 2590 Email: tewarir@us.ibm.com 2592 Manoj Naik 2593 IBM Almaden 2594 650 Harry Rd 2595 San Jose, CA 95120 2596 US 2598 Email: manoj@almaden.ibm.com