idnits 2.17.1 draft-ietf-nfsv4-federated-fs-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1359. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1372. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 26, 2008) is 5691 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCTBD' is mentioned on line 237, but not defined == Unused Reference: 'RFC3552' is defined on line 1272, but no explicit reference was found in the text == Unused Reference: 'RFC4511' is defined on line 1283, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1094 ** Downref: Normative reference to an Informational RFC: RFC 1813 ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Ellard 3 Internet-Draft BBN Technologies 4 Intended status: Standards Track C. Everhart 5 Expires: March 30, 2009 J. Lentini 6 NetApp 7 R. Tewari 8 M. Naik 9 IBM Almaden 10 September 26, 2008 12 NSDB Protocol for Federated Filesystems 13 draft-ietf-nfsv4-federated-fs-protocol-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on March 30, 2009. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document describes a file system federation protocol that 47 enables file access and namespace traversal across collections of 48 independently administered fileservers. The protocol specifies a set 49 of interfaces by which fileservers and collections of fileservers 50 with different administrators can form a fileserver federation that 51 provides a namespace composed of the filesystems physically hosted on 52 and exported by the constituent fileservers. 54 Table of Contents 56 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Protocol Goals . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Overview of Features and Concepts . . . . . . . . . . . . . . 7 60 3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.2. Fileset and Fileset Name (FSN) . . . . . . . . . . . . . . 7 62 3.3. Fileset Location (FSL) . . . . . . . . . . . . . . . . . . 8 63 3.3.1. Mutual Consistency across Fileset Locations . . . . . 8 64 3.4. Namespace Database (NSDB) . . . . . . . . . . . . . . . . 9 65 3.5. Mount Points, Junctions and Referrals . . . . . . . . . . 10 66 3.6. Federation Root FileServers . . . . . . . . . . . . . . . 10 67 3.7. Federation Root FileSet . . . . . . . . . . . . . . . . . 11 68 3.8. Fileservers . . . . . . . . . . . . . . . . . . . . . . . 11 69 3.9. File-access Clients . . . . . . . . . . . . . . . . . . . 11 70 4. Interaction with client protocols . . . . . . . . . . . . . . 12 71 4.1. Interaction with NFSv4 . . . . . . . . . . . . . . . . . . 12 72 4.2. Interaction with other distributed file system 73 protocols . . . . . . . . . . . . . . . . . . . . . . . . 12 74 5. Finding the local NSDB . . . . . . . . . . . . . . . . . . . . 13 75 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 6.1. Create a Fileset and its FSL(s) . . . . . . . . . . . . . 14 77 6.1.1. Creating a Fileset and a FSN . . . . . . . . . . . . . 14 78 6.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 15 79 6.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 15 80 6.3. Example use case for fileset annotations . . . . . . . . . 16 81 7. Error Definitions . . . . . . . . . . . . . . . . . . . . . . 17 82 8. Mapping the NSDB onto LDAP . . . . . . . . . . . . . . . . . . 19 83 8.1. Basic LDAP Configuration . . . . . . . . . . . . . . . . . 19 84 8.2. LDAP Attributes . . . . . . . . . . . . . . . . . . . . . 19 85 8.2.1. fedfsUuid . . . . . . . . . . . . . . . . . . . . . . 19 86 8.2.2. fedfsNetAddr . . . . . . . . . . . . . . . . . . . . . 20 87 8.2.3. fsnUuid . . . . . . . . . . . . . . . . . . . . . . . 20 88 8.2.4. nsdbName . . . . . . . . . . . . . . . . . . . . . . . 20 89 8.2.5. fslHost . . . . . . . . . . . . . . . . . . . . . . . 20 90 8.2.6. fslPath . . . . . . . . . . . . . . . . . . . . . . . 20 91 8.2.7. fslUuid . . . . . . . . . . . . . . . . . . . . . . . 20 92 8.2.8. type . . . . . . . . . . . . . . . . . . . . . . . . . 21 93 8.2.9. currency . . . . . . . . . . . . . . . . . . . . . . . 21 94 8.2.10. info . . . . . . . . . . . . . . . . . . . . . . . . . 21 95 8.2.11. annotation . . . . . . . . . . . . . . . . . . . . . . 21 96 8.2.12. junctionKey . . . . . . . . . . . . . . . . . . . . . 22 97 8.2.13. childFsnUuid . . . . . . . . . . . . . . . . . . . . . 22 98 8.2.14. childNsdbName . . . . . . . . . . . . . . . . . . . . 22 99 8.3. LDAP Objects . . . . . . . . . . . . . . . . . . . . . . . 22 100 8.3.1. FsnObject . . . . . . . . . . . . . . . . . . . . . . 22 101 8.3.2. FslObject . . . . . . . . . . . . . . . . . . . . . . 22 102 8.3.3. JunctionObject . . . . . . . . . . . . . . . . . . . . 23 103 9. NSDB Protocol Operations . . . . . . . . . . . . . . . . . . . 24 104 9.1. Administrative NSDB Operations . . . . . . . . . . . . . . 24 105 9.1.1. Creating an FSN . . . . . . . . . . . . . . . . . . . 25 106 9.1.2. Deleting an FSN . . . . . . . . . . . . . . . . . . . 26 107 9.1.3. Mount an FSN . . . . . . . . . . . . . . . . . . . . . 26 108 9.1.4. Unmount an FSN . . . . . . . . . . . . . . . . . . . . 27 109 9.1.5. Create an FSL . . . . . . . . . . . . . . . . . . . . 27 110 9.1.6. Delete an FSL . . . . . . . . . . . . . . . . . . . . 28 111 9.1.7. Update an FSL . . . . . . . . . . . . . . . . . . . . 28 112 9.1.8. Finding the children FSNs of a fileset . . . . . . . . 29 113 9.2. Fileserver to NSDB Operations . . . . . . . . . . . . . . 29 114 9.2.1. Looking up FSLs for an FSN . . . . . . . . . . . . . . 29 115 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 116 11. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 32 117 12. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 33 118 13. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 119 14. Normative References . . . . . . . . . . . . . . . . . . . . . 37 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 121 Intellectual Property and Copyright Statements . . . . . . . . . . 40 123 1. Requirements notation 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 2. Introduction 131 A federated filesystem enables file access and namespace traversal in 132 a uniform, secure and consistent manner across multiple independent 133 fileservers within an enterprise (and possibly across multiple 134 enterprises) with reasonably good performance. 136 The first requirement of a federated filesystem is the ability to 137 traverse the data exported by different fileservers without requiring 138 a static client configuration. The second requirement is that the 139 location of the data should be dynamically discovered and the 140 discovery process should be transparent to the clients. The third 141 requirement is that it should be possible for all clients, with 142 sufficient privilege, to view the same namespace regardless of the 143 fileserver they connect to. 145 Traditionally, fileserver collections are administered by a single 146 entity. Fileservers may provide proprietary management tools and in 147 some cases an administrator may be able to use the proprietary tools 148 to build a shared namespace out of the exported filesystems. Relying 149 on vendor-proprietary tools does not work in larger enterprises or 150 when collaborating across enterprises because it is likely that the 151 system will contain fileservers running different software, each with 152 their own interfaces, with no common protocol to manage the namespace 153 or exchange namespace information. There may also be independently- 154 administered singleton servers that export some or all of their 155 filesystem resources. A filesystem federation protocol enables the 156 interoperation across multi-vendor fileservers managed by the same 157 administrative entity, across singleton independent fileservers, and 158 across independent administrative entities that may manage a 159 collection of fileservers. The scope of the filesystem federation 160 protocol is limited to NFSv4 capable fileservers. The support for 161 NFSv3 fileservers is optional. 163 2.1. Protocol Goals 165 The objective of this draft is to specify a set of interfaces by 166 which fileservers and collections of fileservers with different 167 administrators can form a fileserver federation that provides a 168 namespace composed of the filesystems physically hosted on and 169 exported by the fileservers of the federation. It should be 170 possible, using a system that implements the interfaces, to share a 171 common namespace across all the fileservers in the federation. It 172 should also be possible for different fileservers in the federation 173 to project different namespaces and enable clients to traverse them. 174 Such a federation may contain an arbitrary number of namespace 175 repositories, each belonging to a different administrative entity, 176 and each rendering a part of the namespace. Such a federation may 177 also have an arbitrary number of administrative entities responsible 178 for administering disjoint subsets of the fileservers. In the rest 179 of the document the term fileserver implies a fileserver that is part 180 of the federation. A fileserver not part of the federation is called 181 an external fileserver. 183 3. Overview of Features and Concepts 185 3.1. Namespace 187 The goal of a unified namespace is to make all managed data available 188 to all clients via the same path in a common filesystem-like 189 namespace. This should be achieved with minimal or zero client 190 configuration. In particular, updates to the common namespace should 191 not require configuration changes at the client. Filesets, which are 192 the unit of data management, are a set of files and directories 193 accessible from a single mount. Depending on the implementation, 194 they may be anything between an individual directory of an exported 195 filesystem to an entire exported filesystem at a fileserver. From 196 the perspective of the clients, the common namespace is constructed 197 by logically mounting filesets that are physically located on 198 different fileservers. The namespace, which is defined in terms of 199 fileset definitions, fileset identifiers, the location of each 200 fileset in the namespace, and the physical location of the 201 implementation(s) of each fileset, is stored in a set of namespace 202 repositories, each managed by an administrative entity. The 203 namespace schema defines the model used for populating, modifying, 204 and querying the namespace repositories. It is not required by the 205 federation that the namespace be common across all fileservers. It 206 should be possible to have several independently rooted namespaces 207 that should permit traversal into another namespace at defined 208 junction points. 210 3.2. Fileset and Fileset Name (FSN) 212 A fileset is defined to be a container of data and is the basic unit 213 of data management. It is uniquely represented by the fileset name 214 (FSN). An FSN is considered unique across the federation. An FSN 215 contains information sufficient to locate the namespace database 216 (NSDB) that holds authoritative information about it and an 217 identifier, called fsn_uuid, that identifies it on that NSDB. After 218 an FSN is created, it is associated with a fileset location (FSL) on 219 a fileserver. A fileset can be implemented by one or more FSLs. The 220 attributes of an FSN are: 222 NsdbName: the fully qualified domain name of an NSDB location that 223 contains authoritative information for this FSN. 225 FsnUuid: a 128-bit UUID (universally unique identifier), conforming 226 to [RFC4122], that is used to uniquely identify an FSN. An NSDB 227 SHOULD ensure that no two FSNs it stores have the same FsnUuid. 229 3.3. Fileset Location (FSL) 231 An FSL represents the location where the fileset data resides. Each 232 FSL contains a host:path pair on a file server. An FSL may also have 233 additional attributes. Each location has an associated type that 234 determines the protocol(s) that may be used to access its data. Type 235 information can be used to decide the list of locations that will be 236 returned to the client. Other attributes associated with an FSL are 237 based on the NFSv4.1 fs_locations_info attribute[RFCTBD]. 239 Each FSL consists of: 241 FslHost: the fully qualified domain name of the host fileserver 242 storing the physical data 244 FslPathname: the exported pathname at that host fileserver 246 FslUuid: the 128-bit UUID of the FSL 248 Type: the protocol that should be used to access this FSL (e.g. 249 NFSv4) 251 Currency: the time lag of this FSL represented as the number of time 252 units it lags the latest version as defined by the NFSv4.1 253 fs_locations_server's fls_currency field. A currency value of 0 254 represents the latest version. Currency values are less than or 255 equal to zero 257 Info: as defined in the NFSv4.1 fs_locations_info attribute 259 Annotations: a list of name/value pairs that can be interpreted by a 260 fileserver and used to generate a referral. The semantics of the 261 name/value pair is not defined by this protocol and is intended to 262 be used by higher-level protocols. This field MAY be used to 263 store the NFSv4.1 fl_locations_server's fls_info values 265 3.3.1. Mutual Consistency across Fileset Locations 267 All of the FSLs that have the same FSN (thereby reference the same 268 fileset) are equivalent from the point of view of client access; the 269 different locations of a fileset represent the same data, though 270 potentially at different points in time. Fileset locations are 271 equivalent but not identical. Locations may either be read- only or 272 read-write. Typically, multiple read-write locations are backed by a 273 clustered filesystem while read-only locations are replicas created 274 by a federation-initiated or external replication. Read-only 275 locations may represent consistent point-in-time copies of a read- 276 write location. The federation protocols, however, cannot prevent 277 subsequent changes to a read-only location nor guarantee point-in- 278 time consistency of a read-only location if the read-write location 279 is changing. 281 Regardless of the type, all locations exist at the same mount point 282 in the namespace and, thus, one client may be referred to one 283 location while another is directed to a different location. Since 284 updates to each fileset location are not controlled by the federation 285 protocol, it is the responsibility of administrators to guarantee the 286 functional equivalence of the data. 288 The federation protocol does not guarantee that the different 289 locations are mutually consistent in terms of the currency of the 290 data. It relies on the client file-access protocol (i.e., NFSv4) to 291 contain sufficient information to help the clients determine the 292 currency of the data at each location in order to ensure that the 293 clients do not revert back in time when switching locations. This 294 raises a concern for NFSv3 fileservers, which the federation protocol 295 may support, that may lack such control. 297 3.4. Namespace Database (NSDB) 299 The NSDB service is a federation-wide service that provides 300 interfaces to define, update, and query FSN information and FSN to 301 FSL mapping information. An individual repository of namespace 302 information is called an NSDB location. Each NSDB location is 303 managed by a single administrative entity. A single admin entity can 304 manage multiple NSDB locations. 306 The difference between the NSDB service and an NSDB location is 307 analogous to that between the DNS service and a particular DNS 308 server. 310 The term local NSDB is shorthand for an NSDB location that is known a 311 priori to a server. It is typically located within the same 312 federation member as the server, but this is not required. A local 313 NSDB is not required. 315 Each NSDB location stores the definition of the FSNs for which it is 316 authoritative. It also stores the definitions of the FSLs associated 317 with those FSNs. An NSDB location is authoritative for the filesets 318 that it defines. An NSDB location can cache information from a peer 319 NSDB location. The fileserver can always contact a local NSDB 320 location (if it has been defined) or directly contact any NSDB 321 location to resolve a junction. Each NSDB location supports an LDAP 322 interface and can be accessed by an LDAP client. 324 An NSDB may be replicated throught the federation. The mechanism by 325 which this is acheived is outside the scope of this document. Many 326 LDAP implementations support replication. These features MAY be used 327 to replicate the NSDB. 329 3.5. Mount Points, Junctions and Referrals 331 A mount point is a directory in a parent fileset where a target 332 fileset may be attached. If a client traverses the path leading from 333 the root of the namespace to the mount point of a target fileset it 334 should be able to access the data in that target fileset (assuming 335 appropriate permissions). 337 The directory where a fileset is mounted is represented by a junction 338 in the underlying filesystem. In other words, a junction can be 339 viewed as a reference from a directory in one fileset to the root of 340 the target fileset. A junction can be implemented as a special 341 marker on a directory that is interpreted by the fileserver as a 342 mount point, or by some other mechanism in the underlying file 343 system. 345 What data is used by the underlying file system to represent the 346 junction is not defined by this protocol. The essential property is 347 that the server must be able to find, given the junction, the FSN for 348 the target fileset. The mechanism by which the server maps a 349 junction to an FSN is outside the scope of this document. The FSN 350 (as described earlier) contains both the NSDB location of the 351 authoritative NSDB location and the FsnUuid (a UUID for the fileset). 353 When a client traversal reaches a junction, the client is referred to 354 a list of FSLs associated with the FSN that was the target of the 355 junction. The client can then redirect its connection to one of the 356 FSLs. This act is called a referral. For NFSv4 clients, the FSL 357 information is returned in the fs_locations or fs_locations_info 358 attributes. 360 The federation-fs interfaces do not limit where and how many times a 361 fileset is mounted in the namespace. Filesets can be nested -- a 362 fileset can be mounted under another fileset. 364 3.6. Federation Root FileServers 366 A set of designated fileservers that render the common federation- 367 wide namespace are called the federation root fileservers. The 368 federation protocol does not mandate that federation root fileservers 369 be defined. When a client mounts the root of the namespace from a 370 root fileserver it can traverse the entire federation-wide namespace. 371 It is not required for a client to mount from one of the root 372 fileservers. If a client mounts from a non-root fileserver then it 373 can traverse the part of the namespace that is visible starting from 374 that fileserver. A client can mount multiple individual filesets 375 from multiple non-root fileservers and chose to navigate the 376 namespace in any manner. How the client discovers the root 377 fileserver(s), if one is defined, is not in the scope of the 378 federation protocol. Numerous external techniques such as DNS SRV 379 records can be used for this. 381 3.7. Federation Root FileSet 383 The root fileset is the optional, top-level fileset of the 384 federation-wide namespace. The root of the namespace is the top 385 level directory of this fileset. The fileset can contain an 386 arbitrary number of virtual directories. The leaf directories of the 387 root fileset serve as the mount points for other filesets. It is 388 desirable that the leaf directories not contain data. The root 389 fileset is a simple combination of internal nodes and leaf nodes 390 where each leaf node is a junction to a target fileset. The root 391 fileset is replicated at all the root fileservers. The recommended 392 replication protocols for root fileset replication are: an external 393 protocol such as rsync or NDMP. 395 3.8. Fileservers 397 Fileservers are NFSv4 servers that store the physical fileset data or 398 fileservers that refer the client to other fileservers. 400 3.9. File-access Clients 402 File access clients are standard off-the-shelf NAS clients that 403 access file data using the NFSv4 protocol or some other protocol. 405 4. Interaction with client protocols 407 4.1. Interaction with NFSv4 409 The federation protocol is compatible with the requirements of NFSv4 410 referral mechanisms as defined in [RFC3530]. 412 4.2. Interaction with other distributed file system protocols 414 The federation protocol does not mandate a specific format for 415 pathnames. Therefore it is possible to store the pathnames used by a 416 variety of distributed file systems, including CIFS. 418 5. Finding the local NSDB 420 The fed-fs protocol does not mandate how and if a local NSDB is 421 defined or located. A fileserver's local NSDB configuration could be 422 specified using a simple text file or some other mechanism. 424 6. Examples 426 In this section we provide examples and discussion of the basic 427 operations facilitated by the federated file system protocol: 428 creating a fileset, adding a replica of a fileset, resolving a 429 junction, and creating a junction. 431 6.1. Create a Fileset and its FSL(s) 433 A fileset is the abstraction of a set of files and their containing 434 directory tree. The fileset abstraction is the fundamental unit of 435 data management in the federation. This abstraction is implemented 436 by an actual directory tree whose root location is specified by a 437 fileset location (FSL). 439 In this section, we describe the basic requirements for starting with 440 a directory tree and creating a fileset that can be used in the 441 federation protocols. Note that we do not assume that the process of 442 creating a fileset requires any transformation of the files or the 443 directory hierarchy. The only thing that is required by this process 444 is assigning the fileset a fileset name (FSN) and expressing the 445 location(s) of the implementation of the fileset as FSL(s). 447 There are many possible variations to this procedure, depending on 448 how the FSN that binds the FSL is created, and whether other replicas 449 of the fileset exist, are known to the federation, and need to be 450 bound to the same FSN. 452 It is easiest to describe this in terms of how to create the initial 453 implementation of the fileset, and then describe how to add replicas. 455 6.1.1. Creating a Fileset and a FSN 457 1. Choose the NSDB node that will keep track of the FSL(s) and 458 related information for the fileset. 460 2. Request that the NSDB node register a new FSN for the fileset. 462 The FSN UUID is choosen by the administrator or generated 463 automatically by administration software. The former case is 464 used if the fileset is being restored, perhaps as part of 465 disaster recovery, and the administrator wishes to specify the 466 FSN UUID in order to permit existing junctions that reference 467 that FSN to work again. 469 At this point, the FSN exists, but its fileset locations are 470 unspecified. 472 3. Send the FSN, the hostname, the export path, the type, the 473 currency, info, and annotations for the fileset to the NSDB node. 475 The NSDB node records this info and creates the initial FSL for 476 the fileset. 478 6.1.2. Adding a Replica of a Fileset 480 Adding a replica is straightforward: the NSDB node and the FSN are 481 already known. The only remaining step is to add another FSL. 483 Note that the federation interfaces do not include methods for 484 creating or managing replicas: this is assumed to be a platform- 485 dependent operation (at least at this time). The only interface 486 required is the ability to register or remove the registration of 487 replicas for a fileset. 489 6.2. Junction Resolution 491 A fileset may contain references to other filesets. These references 492 are represented by junctions. If a client requests access to a 493 fileset object that is a junction, the server resolves the junction 494 to discover the FSL(s) that implements the referenced fileset. 496 There are many possible variations to this procedure, depending on 497 how the junctions are represented and how the information necessary 498 to perform resolution is represented by the server. In this example, 499 we assume that the only thing directly expressed by the junction is 500 the junction key; its mapping to FSN can be kept local to the server 501 hosting the junction. 503 Step 5 is the only step that interacts directly with the federation 504 interfaces. The rest of the steps may use platform-specific 505 interfaces. 507 1. The server determines that the object being accessed is a 508 junction. 510 2. The server determines the junction key for the junction. 512 3. Using the junction key, the server does a local lookup to find 513 the FSN of the target fileset. 515 4. Using the FSN, the server finds the NSDB node responsible for the 516 target object. 518 5. The server contacts that NSDB node and asks for the set of FSLs 519 that implement the target FSN. The NSDB node responds with a set 520 of FSLs. 522 6.3. Example use case for fileset annotations 524 The fileset annotations can be used to define relationships between 525 filesets that can be used by an auxiliary replication protocol. 526 Consider the scenario where a fileset is created and mounted at some 527 point in the namespace. A snapshot of the read-write FSL of that 528 fileset is taken periodically at different frequencies say a daily 529 snapshot or a weekly snapshot. The different snapshots are mounted 530 at different locations in the namespace. The daily snapshots are 531 considered as a different fileset from the weekly ones but both are 532 related to the source fileset. For this we can define an annotation 533 labeling the filesets as source and replica. The replication 534 protocol can use this information to copy data from one or more FSLs 535 of the source fileset to all the FSLs of the replica fileset. The 536 replica filesets are read-only while the source fileset is read- 537 write. 539 This follows the traditional AFS model of mounting the read-only 540 volume at a path in the namespace different from that of the read- 541 write volume. 543 The federation protocol does not control or manage the relationship 544 among filesets. It merely enables annotating the filesets with user- 545 defined relationships. 547 7. Error Definitions 549 ERR_OK Indicates the operation completed successfully. 551 ERR_ACCESS Permission denied. The caller does not have the correct 552 permission to perform the requested operation. Contrast this with 553 ERR_PERM, which restricts itself to owner or privileged user 554 permission failures. 556 ERR_BADCHAR A UTF-8 string contains a character which is not 557 supported in the context in which it being used. 559 ERR_BADNAME A name string in a request consists of valid UTF-8 560 characters supported by the server but the name is not supported 561 by the server as a valid name for current operation. 563 ERR_BADTYPE An attempt was made to create an object of a type not 564 supported by the server. 566 ERR_DENIED An attempt to lock a file is denied. Since this may be a 567 temporary condition, the client is encouraged to retry the lock 568 request until the lock is accepted. 570 ERR_EXIST Object exists. The object specified already exists. 572 ERR_INVALID Invalid argument or unsupported argument for an 573 operation. 575 ERR_IO I/O error. A hard error (for example, a disk error) occurred 576 while processing the requested operation. 578 ERR_NAMETOOLONG The filename in an operation was too long. 580 ERR_NOENT No such object. The object being accessed does not exist. 582 ERR_NOTDIR Not a directory. The caller specified a non- directory 583 in a directory operation. 585 ERR_NOTEMPTY An attempt was made to remove an object that was not 586 empty. An FSN which has FSLs still defined for it. 588 ERR_NOTSUPP Operation is not supported. 590 ERR_PERM Not owner. The operation was not allowed because the 591 caller is either not a privileged user (root) or not the owner of 592 the target of the operation. 594 ERR_WRONGSEC The security mechanism being used by the client for the 595 operation does not match the server's security policy. The client 596 should change the security mechanism being used and retry the 597 operation. 599 ERR_WRONGNSDB The NSDB location is not the one to be used for this 600 operation. 602 8. Mapping the NSDB onto LDAP 604 This section describes the LDAP schema used to define the LDAP 605 implementation of the NSDB service. The first part of the section 606 describes the basic properties of the LDAP configuration that MUST be 607 used in order to ensure compatibility between different 608 implementations. The second section defines the new LDAP attribute 609 types and the subsequent sections describe the new object types and 610 specify how the distinguished name (DN) of each object instance MUST 611 be constructed. 613 8.1. Basic LDAP Configuration 615 The base name (or suffix) for all DNs used by the NSDB schema is 616 "dc=fed-fs,dc=com". 618 The DN of the priviledged LDAP user is, by convention, 619 "cn=admin,dc=fed-fs,dc=com". This user is able to modify the 620 contents of the LDAP database. It is permitted to use a different DN 621 (or add additional priviledged users) but if a different DN is used 622 then every admin entity that needs to modify the contents of the 623 database or view privilidged information must be made aware of the 624 new DN. 626 It MUST be possible for the anonymous (unauthenticated) user to 627 perform LDAP queries that access the NSDB data. 629 All implementations SHOULD use the same schema, or, at minimum, a 630 schema that includes all of the objects, with each of the attributes, 631 named in the following sections. 633 8.2. LDAP Attributes 635 This section describes the required attributes of the NSDB LDAP 636 schema. 638 8.2.1. fedfsUuid 640 A fedfsUuid is the base type for all of the universally unique 641 identifiers (UUIDs) used by the federated file system protocols. 643 This SHOULD be defined in terms of the text representation of the 644 standard UUID (as defined in [RFC4122]). 646 It MAY also be useful, for purposes of debugging or annotation, to 647 permit a fedfsUuid to include members of a more general class of 648 strings. 650 A fedfsUuid is a single-valued LDAP attribute. 652 8.2.2. fedfsNetAddr 654 A fedfsNetAddr is the locative name of a network service. It MUST be 655 able to express network locations as IPv4, IPv6, and DNS FQDN 656 notations. It may include a port specifier, or the port may be 657 implicit in context. 659 There MAY be a special syntax at some point for specifying a SVR 660 record (for a DNS FQDN). 662 This attribute is single-valued. 664 8.2.3. fsnUuid 666 A fsnUuid represents the fsnUuid component of an FSN. 668 The fsnUuid is a subclass of fedfsUuid. 670 This attribute is single-valued. 672 8.2.4. nsdbName 674 A nsdbName is the NSDB component of an FSN. 676 The nsdbName attribute is a subclass of fedfsNetAddr. 678 This attribute is single-valued. 680 8.2.5. fslHost 682 A fslHost is the hostname/port component of an FSL. 684 The fslHost attribute is a subclass of fedfsNetAddr. 686 This attribute is single-valued. 688 8.2.6. fslPath 690 The path component of an FSL. 692 This attribute is single-valued. 694 8.2.7. fslUuid 696 Each FSL must have a UUID associated with it, which serves as part of 697 its DN. 699 The fslUuid attribute is a subclass of fedfsUuid. 701 This attribute is single-valued. 703 8.2.8. type 705 The type of an FSL. 707 This attribute is used to specify the distribute file system protocol 708 that can be used to access an FSL. The following values are defined 709 for this field: 711 nfsv4 : the FSL is accessible via the NFSv4 protocol. 713 Values for other protocols may be defined at a later time. 715 This attribute is single-valued. 717 8.2.9. currency 719 The currency of an FSL. 721 This attribute is used to populate the NFSv4.1 fs_locations_info's 722 currency field. 724 This attribute is single-valued. 726 8.2.10. info 728 Information about the FSL. 730 This attribute is used to populate the NFSv4.1 fs_locations_info's 731 info field. 733 This attribute is single-valued. 735 8.2.11. annotation 737 An annotation of an NSDB object. 739 This attribute is multi-valued; an object type that permits 740 annotations may have any number of annotations per instance. 742 This attribute is a placeholder; it has not been well-defined at the 743 date of this draft. 745 8.2.12. junctionKey 747 Each junction has a unique junctionKey that is used to distinguish it 748 from other junctions that may refer to the same child fileset and/or 749 appear within the same parent fileset. 751 The junctionKey attribute is a subclass of fedfsUuid. 753 This attribute is single-valued. 755 8.2.13. childFsnUuid 757 The fsnUuid of the target of a junction. 759 The childFsnUuid attribute is a subclass of fsnUuid. 761 This attribute is single-valued. 763 8.2.14. childNsdbName 765 The nsdbName of the target of a junction. 767 The childNsdbName attribute is a subclass of nsdbName. 769 This attribute is single-valued. 771 8.3. LDAP Objects 773 8.3.1. FsnObject 775 An FsnObject represents an FSN. 777 The required attributes of an FsnObject are an nsdbName and fsnUuid. 779 The DN of an FSN is assumed to take the following form: 780 "fsnUuid=FSNUUID,dc=fed-fs,dc=com", where fsnUuid is the UUID of the 781 FSN. 783 An FsnObject MAY also have additional attributes, but these 784 attributes MUST NOT be referenced by any part of this draft. 786 8.3.2. FslObject 788 An FslObject represents an FSL. 790 The required attributes of an FslObject are an nsdbName, fsnUuid, 791 fslHost, fslPath, fslUuid, type, currency, info, and annotations. 793 An FslObject's currency and annotations attributes MAY be null. 795 The DN of an FSL is required to take the following form: 796 "fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com". 798 To find all the FSLs that match a given FSN, query for the children 799 of the object with DN "fsnUuid=FSNUUID,dc=fed-fs,dc=com" with a 800 filter for "objectType = fslObject". (If you want to be doubly 801 careful, you can also filter by the nsdbName.) 803 8.3.3. JunctionObject 805 An JunctionObject captures the relationship between a fileset and its 806 children (if any). The children FSNs are FSNs that appear in 807 junctions in the fileset named by the fsnUuid and nsdbName attributes 808 of the parent FSN. 810 The required attributes of a JunctionObject are a junctionKey, 811 fsnUuid, nsdbName, childFsnUuid, and childNsdbName. 813 A JunctionObject MAY also have descr and annotation attributes, but 814 neither is required. 816 The required form of a DN for an JunctionObject is: 817 "junctionKey=KEY,fsnUuid=FSNUUID,dc=fed-fs,dc=com" where KEY is a 818 unique key chosen for this relationship (the junctionKey) and FSNUUID 819 is the fsnUuid of the parent fileset's FSN. 821 Note that the reason why KEY might be something other than simply the 822 fsnUuid of the child's FSN is that a child FSN may appear as the 823 target of several junctions within the same fileset, and we must have 824 a way to distinguish each of these junctions. 826 To find all the junctions within a given fileset, query for the 827 children of the object with DN "fsnUuid=FSNUUID,dc=fed-fs,dc=com" and 828 filter for "objectType = JunctionObject". (If you want to be doubly 829 careful, you can also filter by the nsdbName.) 831 9. NSDB Protocol Operations 833 The operations defined by the protocol can be described as several 834 sub-protocols that are used by entities within the federation to 835 perform different roles. 837 The first of these sub-protocols defines how the state of an NSDB 838 location can be initialized and updated. The primary use of this 839 sub-protocol is by an administrator to add, edit, or delete filesets, 840 their properties, and their fileset locations. 842 The second of these sub-protocols defines the queries that are sent 843 to an NSDB location in order to perform resolution (or find other 844 information about the information stored within that NSDB location) 845 and the responses returned by the NSDB location. The primary use of 846 this sub-protocol is by a fileset server in order to perform 847 resolution, but it may also be used by an administrator to query the 848 state of the system. 850 The first and second sub-protocols are defined as LDAP operations, 851 using the schema defined in the previous section. If each NSDB 852 location is a standard LDAP server, then, in theory, it is 853 unnecessary to describe the LDAP operations in detail, because the 854 operations are ordinary LDAP operations to query and update records. 855 However, we do not require that an NSDB location implement a complete 856 LDAP service, and therefore we define in these sections the minimum 857 level of LDAP functionality required to implement an NSDB location. 859 The NSDB sub-protocols are defined in the next two sub-sections. 861 The third sub-protocol defines the queries or other requests that are 862 sent to a fileset server in order to get information from it or to 863 modify the state of the fileset server in a manner related to the 864 federation protocols. The primary purpose of this protocol is for an 865 administrator to create or delete a junction or fileset or discover 866 related information about a particular fileset server. 868 The third sub-protocol is defined as ONC/RPC operations. The reason 869 for using a different RPC mechanism (instead of mapping these 870 operations onto LDAP) is to minimize the changes required to the 871 fileset server. This protocol is described in a separate document. 873 9.1. Administrative NSDB Operations 875 The admin entity initiates and controls the commands to manage 876 fileset and namespace information. The admin entity, however, is 877 stateless. All state is maintained at the NSDB locations or at the 878 fileserver. 880 We require that each NSDB location be able to act as an LDAP server 881 and that the protocol used for communicating between the admin entity 882 and each NSDB is LDAP. 884 The names we assign to these operations are entirely for the purpose 885 of exposition in this document, and are not part of the LDAP dialogs. 887 In the description of the LDAP messages and LDIF, we use the 888 following notation: constant strings and literal names are specified 889 in lower or mixed case, while variables or values are specified in 890 uppercase. One important exception to this rule is that the names of 891 the error codes follow the convention (used widely in other 892 protocols, including NFS) of having names that are entirely 893 uppercase. 895 NEED TO UPDATE THE TEXT HERE TO REFER TO THE OTHER DRAFT. -DJE 897 9.1.1. Creating an FSN 899 The administrator uses this operation to create a new FSN by 900 requesting the NSDB to create a new FsnObject in its LDAP database 901 with an fsnUuid of FSNUUID and an NsdbName of NSDB. 903 The NSDB location that receives the request SHOULD check that the 904 NSDB matches its own value and return an ERR_WRONGNSDB error if it 905 does not. This is to ensure that an FSN is always created by the 906 NSDB location encoded within the FSN as its owner. 908 The NSDB location that receives the request SHOULD check all of the 909 attributes for validity and consistency, but this is not generally 910 possible for LDAP servers because the consistency requirements cannot 911 be expressed in the LDAP schema (although many LDAP servers can be 912 extended, via plug-ins or other mechanisms, to add functionality 913 beyond the strict definition of LDAP). 915 PARAGRAPH DESCRIBING ERRORS 917 9.1.1.1. LDAP Request 919 The admin chooses the fsnUuid and NsdbName of the FSN. The fsnUuid 920 is a UUID and should be chosen via a standard process for creating a 921 UUID (described in [RFC4122]). The NsdbName is the name of the NSDB 922 location that will serve as the source of definitive information 923 about an FSN for the life of that FSN. In the example below, the 924 admin server chooses a fsnUuid of FSNUUID and the NsdbName of NSDB 925 and then sends an LDAP ADD request, described by the LDIF below, to 926 the NSDB location NSDB. This will create a new FsnObject on that 927 NSDB location with the given attributes in the LDAP database. 929 dn: fsnUuid=FSNUUID,dc=fed-fs,dc=com 930 changeType: add 931 objectClass: FsnObject 932 fsnUuid: FSNUUID 933 nsdbName: NSDB 935 9.1.2. Deleting an FSN 937 Deletes the given fileset name. This assumes that all the FSLs 938 related to that FSN have already been deleted. If FSL records for 939 this FSN still exist in the database of the NSDB that receives this 940 request, then this function MUST return with an ERR_NOTEMPTY error. 942 Note that the FSN delete function only removes the fileset from the 943 namespace (by removing the records for that FSN from the NSDB 944 location that receives this request). The fileset and its data are 945 not deleted. Any junction that has this FSN as its target may 946 continue to point to this non-existent FSN. A dangling reference may 947 be detected when a client tries to resolve the target of a junction 948 that refers to the deleted FSN and the NSDB returns ERR_NOTFOUND. 950 PARAGRAPH DESCRIBING ERRORS 952 9.1.2.1. LDAP Request 954 The admin sends an LDAP DELETE request to the NSDB server to remove 955 the FsnObject from the NSDB server. An example LDIF for the delete 956 request is shown below. 958 dn: fsnUuid=FSNUUID,dc=fed-fs,dc=com 959 changeType: delete 961 9.1.3. Mount an FSN 963 NOTE: the semantics of this operation have changed significantly, and 964 "mount" might be a quite unintuitive name at this point. 966 The mount operation records that a given fileset (called the parent 967 fileset) contains a junction. The target of that fileset is called 968 the child fileset. 970 The NSDB of the parent fileset (as identified by the FSN of the 971 parent) maintains this information. 973 The parent/child relation is used to indicate how the filesets in the 974 federation are related. The names "parent" and "child" should not be 975 taken literally. A fileset can have no parent (if it is a root 976 fileset). A fileset may also have any number of parents. In theory, 977 the parent of a fileset may also be its child, although in practice 978 this is deprecated. 980 A fileset may be mounted in multiple places, and may have the same 981 parent multiple times. For example, /home/ellard and /home/ 982 daniel.ellard might both be junctions from the /home fileset to the 983 fileset that represents the home directory of user Daniel Ellard. In 984 order to be able to distinguish each mount, each mount is given a 985 unique identifier (in addition to the fsnUuids of the parent and 986 child). 988 PARAGRAPH DESCRIBING ERRORS 990 9.1.3.1. LDAP Request 992 On fileset mount operation the admin will generate an LDAP ADD 993 request to the NSDB server using the example LDIF below. This 994 creates a new FsnJunctionObject that establishes the mount 995 relationship between the parent and target FSNs. 997 dn: key=KEY,fsnUuid=FSNUUID,dc=fed-fs,dc=com 998 changeType: add 999 objectClass: JunctionObject 1000 fsnUuid: FSNUUID 1001 nsdbName: NSDBNAME 1002 childFsnUuid: CHILDFSNUUID 1003 childNsdbName: CHILDNSDB 1005 9.1.4. Unmount an FSN 1007 Removes the record of a junction between a parent and child fileset. 1009 PARAGRAPH DESCRIBING ERRORS 1011 9.1.4.1. LDAP Request 1013 In case a target_FSN is to be unmmounted, the associated 1014 JunctionObject is deleted from the NSDB maintaining the parent 1015 fileset. An example delete request is shown below. 1017 dn: key=KEY,fsnUuid=FSNUUID,dc=fed-fs,dc=com 1018 changeType: delete 1020 9.1.5. Create an FSL 1022 Creates a new Fileset location at the given location denoted by HOST 1023 and PATH for the given FSN. Normally an FSL is identified by the 1024 HOST:PATH pair. A UUID is an optional way to identify an FSL if it 1025 is recovered to a different HOST:PATH after a backup/restore. If the 1026 FSL belongs to an FSN that has another FSN mounted under it then 1027 there would be a related junction_create operation. 1029 PARAGRAPH DESCRIBING ERRORS 1031 The FSL create command will result in the admin server sending an 1032 LDAP ADD request to create a new FslObject at the NSDB maintaining 1033 the given FSN. The example LDIF is shown below. The PATH is the 1034 pathname where the fileset is located on that host. 1036 9.1.5.1. LDAP Request 1038 dn:fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com 1039 changeType: add 1040 objectClass: FslObject 1041 fsnUuid: FSNUUID 1042 nsdbName: NSDB 1043 fslUuid: UUID 1044 fslHost: HOST 1045 fslPath: PATH 1046 type: file access protocol type (e.g. nfs4) 1047 currency: CURRENCY 1048 info: INFO 1049 annotation: ANNOTATION 1051 9.1.6. Delete an FSL 1053 Deletes the given Fileset location. The admin requests the NSDB 1054 location storing the FslObject to delete it from its database. This 1055 operation does not result in the fileset location's data being 1056 deleted at the fileserver. 1058 PARAGRAPH DESCRIBING ERRORS 1060 9.1.6.1. LDAP Request 1062 dn: fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com 1063 changeType: delete 1065 9.1.7. Update an FSL 1067 Update the attributes of a given FSL. This command results in a 1068 change in the attributes of the FslObject at the NSDB server 1069 maintaining this FSL. The attributes that must not change are the 1070 fslUuid and the fsnUuid of the fileset this FSL implements. 1072 PARAGRAPH DESCRIBING ERRORS 1074 9.1.7.1. LDAP Request 1076 dn: fslUuid=UUID,fsnUuid=FSNUUID,dc=fed-fs,dc=com 1077 changeType: modify 1078 replace: ATTRIBUTE-TYPE 1080 9.1.8. Finding the children FSNs of a fileset 1082 The NSDB also tracks information about which filesets are "children" 1083 of others. A fileset X is a child of fileset Y if there is a 1084 junction in fileset Y referencing fileset X. (note that this 1085 definition permits a fileset to be its own child, although this use 1086 is deprecated) 1088 In addition to keeping track of whether one fileset has another as 1089 its child, the NSDB also records additional information to simplify 1090 management -- each parent/child relation is associated with an 1091 additional key that is used to disambiguate the relationship. For 1092 example, one fileset may have several junctions targeting the same 1093 child, but each has a seperate key that can be used to differentiate 1094 them. This permits junctions to be removed without necessarily 1095 removing the underlying relationship. 1097 NOTE: if it is decided to require that there can only be one junction 1098 from one fileset to a second, then the key should simply be the FSN 1099 of the target. This restriction would greatly simplify some aspects 1100 of the implementation (but it may also eliminate some very useful 1101 functionality). 1103 LDAP Request 1104 Search base: fsnUuid=FSNUUID, dc=fed-fs, dc=com 1105 Search scope: onelevel 1106 Search filter: (objectClass=JunctionObject) 1108 9.2. Fileserver to NSDB Operations 1110 9.2.1. Looking up FSLs for an FSN 1112 Return the list of FSLs for the FSN with an fsnUuid that matches the 1113 filter. The fileserver will convert the list of FSLs to the NFSv4 1114 fs_locations. 1116 The filter may also specify the type of protocol (v4, v3), or type of 1117 data access (ro, rw). 1119 ERRORS: ERR_OK ERR_NOTFOUND ERR_INVALID ERR_PERM 1120 LDAP Request 1121 Search base: fsnUuid=FSNUUID, dc=fed-fs, dc=com 1122 Search scope: onelevel 1123 Search filter: (objectClass=FslObject) 1125 The server can scan through the results and find results whose type 1126 corresponds to the type of the client on whose behalf the server is 1127 performing the request, extracting the fslHost and fslPath (and 1128 possibly additional attributes) and using them to create a list of 1129 fs_locations that the client can use. 1131 10. Security Considerations 1133 Both LDAP and NFSv4 provide security mechanisms. When used in 1134 conjunction with the federated file system protocols described in 1135 this document, the use of these mechanisms is RECOMMENDED. 1136 Specifically, the use of RPCSEC_GSS [RFC2203] [RFC2743] is 1137 RECOMMENDED on all connections between a client and filerserver. For 1138 all LDAP connections established by the federated file system 1139 protocols, TLS [RFC4346] [RFC4513] is RECOMMENDED. 1141 11. IANA Requirements 1143 This document has no actions for IANA. 1145 12. Conclusions 1147 The federated filesystem protocol manages multiple independently 1148 administered fileservers to share namespace and referral information 1149 to enable clients to traverse seamlessly across them. 1151 13. Glossary 1153 Administrator: user with the necessary authority to initiate 1154 administrative tasks on one or more servers. 1156 Admin entity: A server or agent that administers a collection of 1157 fileservers and persistently stores the namespace information. 1159 Client: Any client that accesses the fileserver data using a 1160 supported filesystem access protocol. 1162 Federation: A set of server collections and singleton servers that 1163 use a common set of interfaces and protocols in order to provide 1164 to their clients a federated namespace accessible through a 1165 filesystem access protocol. 1167 Fileserver: A server exporting a filesystem via a network filesystem 1168 access protocol. 1170 Fileset: The abstraction of a set of files and their containing 1171 directory tree. A fileset is the fundamental unit of data 1172 management in the federation. 1174 Note that all files within a fileset are descendants of one 1175 directory, and that filesets do not span filesystems. 1177 Filesystem: A self-contained unit of export for a fileserver, and 1178 the mechanism used to implement filesets. The fileset does not 1179 need to be rooted at the root of the filesystem, nor at the export 1180 point for the filesystem. 1182 A single filesystem MAY implement more than one fileset, if the 1183 client protocol and the fileserver permit this. 1185 Filesystem access protocol: A network filesystem access protocol 1186 such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [RFC3530], or 1187 CIFS. 1189 FSL (Fileset location): The location of the implementation of a 1190 fileset at a particular moment in time. A FSL MUST be something 1191 that can be translated into a protocol-specific description of a 1192 resource that a client can access directly, such as a fs_location 1193 (for NFSv4), or share name (for CIFS). Note that not all FSLs 1194 need to be explicitly exported as long as they are contained 1195 within an exported path on the fileserver. 1197 FSN (Fileset name): A platform-independent and globally unique name 1198 for a fileset. Two FSLs that implement replicas of the same 1199 fileset MUST have the same FSN, and if a fileset is migrated from 1200 one location to another, the FSN of that fileset MUST remain the 1201 same. 1203 Junction: A filesystem object used to link a directory name in the 1204 current fileset with an object within another fileset. The 1205 server-side "link" from a leaf node in one fileset to the root of 1206 another fileset. 1208 Junction key: The UUID of a fileset, used as a key to lookup an FSN 1209 within an NSDB node or a local table of information about 1210 junctions. 1212 Namespace: A filename/directory tree that a sufficiently-authorized 1213 client can observe. 1215 NSDB (Namespace Database Service): A service that maps FSNs to FSLs. 1216 The NSDB may also be used to store other information, such as 1217 annotations for these mappings and their components. 1219 NSDB Node: The name or location of a server that implements part of 1220 the NSDB service and is responsible for keeping track of the FSLs 1221 (and related info) that implement a given partition of the FSNs. 1223 Referral: A server response to a client access that directs the 1224 client to evaluate the current object as a reference to an object 1225 at a different location (specified by an FSL) in another fileset, 1226 and possibly hosted on another fileserver. The client re-attempts 1227 the access to the object at the new location. 1229 Replica: A replica is a redundant implementation of a fileset. Each 1230 replica shares the same FSN, but has a different FSL. 1232 Replicas may be used to increase availability or performance. 1233 Updates to replicas of the same fileset MUST appear to occur in 1234 the same order, and therefore each replica is self-consistent at 1235 any moment. 1237 We do not assume that updates to each replica occur simultaneously 1238 If a replica is offline or unreachable, the other replicas may be 1239 updated. 1241 Server Collection: A set of fileservers administered as a unit. A 1242 server collection may be administered with vendor-specific 1243 software. 1245 The namespace provided by a server collection could be part of the 1246 federated namespace. 1248 Singleton Server: A server collection containing only one server; a 1249 stand-alone fileserver. 1251 14. Normative References 1253 [RFC1094] Nowicki, B., "NFS: Network File System Protocol 1254 specification", RFC 1094, March 1989. 1256 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 1257 Version 3 Protocol Specification", RFC 1813, June 1995. 1259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1260 Requirement Levels", BCP 14, RFC 2119, March 1997. 1262 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 1263 Specification", RFC 2203, September 1997. 1265 [RFC2743] Linn, J., "Generic Security Service Application Program 1266 Interface Version 2, Update 1", RFC 2743, January 2000. 1268 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 1269 Beame, C., Eisler, M., and D. Noveck, "Network File System 1270 (NFS) version 4 Protocol", RFC 3530, April 2003. 1272 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1273 Text on Security Considerations", BCP 72, RFC 3552, 1274 July 2003. 1276 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1277 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1278 July 2005. 1280 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1281 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1283 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 1284 (LDAP): The Protocol", RFC 4511, June 2006. 1286 [RFC4513] Harrison, R., "Lightweight Directory Access Protocol 1287 (LDAP): Authentication Methods and Security Mechanisms", 1288 RFC 4513, June 2006. 1290 Authors' Addresses 1292 Daniel Ellard 1293 BBN Technologies 1294 10 Moulton Street 1295 Cambridge, MA 02138 1296 US 1298 Phone: +1 617-873-8000 1299 Email: ellard@gmail.com 1301 Craig Everhart 1302 NetApp 1303 7301 Kit Creek Rd 1304 Research Triangle Park, NC 27709 1305 US 1307 Phone: +1 919-476-5320 1308 Email: everhart@netapp.com 1310 James Lentini 1311 NetApp 1312 1601 Trapelo Rd, Suite 16 1313 Waltham, MA 02451 1314 US 1316 Phone: +1 781-768-5359 1317 Email: jlentini@netapp.com 1319 Renu Tewari 1320 IBM Almaden 1321 650 Harry Rd 1322 San Jose, CA 95120 1323 US 1325 Email: tewarir@us.ibm.com 1326 Manoj Naik 1327 IBM Almaden 1328 650 Harry Rd 1329 San Jose, CA 95120 1330 US 1332 Email: manoj@almaden.ibm.com 1334 Full Copyright Statement 1336 Copyright (C) The IETF Trust (2008). 1338 This document is subject to the rights, licenses and restrictions 1339 contained in BCP 78, and except as set forth therein, the authors 1340 retain all their rights. 1342 This document and the information contained herein are provided on an 1343 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1344 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1345 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1346 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1347 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1348 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1350 Intellectual Property 1352 The IETF takes no position regarding the validity or scope of any 1353 Intellectual Property Rights or other rights that might be claimed to 1354 pertain to the implementation or use of the technology described in 1355 this document or the extent to which any license under such rights 1356 might or might not be available; nor does it represent that it has 1357 made any independent effort to identify any such rights. Information 1358 on the procedures with respect to rights in RFC documents can be 1359 found in BCP 78 and BCP 79. 1361 Copies of IPR disclosures made to the IETF Secretariat and any 1362 assurances of licenses to be made available, or the result of an 1363 attempt made to obtain a general license or permission for the use of 1364 such proprietary rights by implementers or users of this 1365 specification can be obtained from the IETF on-line IPR repository at 1366 http://www.ietf.org/ipr. 1368 The IETF invites any interested party to bring to its attention any 1369 copyrights, patents or patent applications, or other proprietary 1370 rights that may cover technology that may be required to implement 1371 this standard. Please address the information to the IETF at 1372 ietf-ipr@ietf.org. 1374 Acknowledgment 1376 Funding for the RFC Editor function is provided by the IETF 1377 Administrative Support Activity (IASA).