idnits 2.17.1 draft-ietf-nfsv4-federated-fs-reqts-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 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 (April 20, 2009) is 5485 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 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: Informational NetApp 5 Expires: October 22, 2009 D. Ellard 6 BBN Technologies 7 R. Tewari 8 M. Naik 9 IBM Almaden 10 April 20, 2009 12 Requirements for Federated File Systems 13 draft-ietf-nfsv4-federated-fs-reqts-02 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on October 22, 2009. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document describes and lists the functional requirements of a 52 federated file system and defines related terms. 54 Table of Contents 56 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 57 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Examples and Discussion . . . . . . . . . . . . . . . . . . . 7 60 4.1. Create a Fileset and its FSL(s) . . . . . . . . . . . . . 7 61 4.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 7 62 4.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 8 63 4.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 8 64 4.3. Junction Creation . . . . . . . . . . . . . . . . . . . . 10 65 5. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 6. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 15 67 6.1. Basic Assumptions . . . . . . . . . . . . . . . . . . . . 15 68 6.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18 69 7. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 25 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 74 10.2. Informational References . . . . . . . . . . . . . . . . . 28 75 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 29 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 78 1. Requirements notation 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 Note, that this is a requirements document, and in many instances 85 where these words are used in this document they refer to qualities 86 of a specification for a system that satisfies the document, or 87 requirements of a system that matches that specification. These 88 cases are distinguished when there is potential for ambiguity. 90 2. Overview 92 This document describes and lists the functional requirements of a 93 federated file system and defines related terms. 95 We do not describe the mechanisms that might be used to implement 96 this functionality except in cases where specific mechanisms, in our 97 opinion, follow inevitably from the requirements. Our focus is on 98 the interfaces between the entities of the system, not on the 99 protocols or their implementations. 101 Today, there are collections of fileservers that inter-operate to 102 provide a single namespace comprised of filesystem resources provided 103 by different members of the collection, joined together with inter- 104 filesystem references. The namespace can either be assembled at the 105 fileservers, the clients, or by an external namespace service, and is 106 often not easy or uniform to manage. The requirements in this draft 107 are meant to lead to a uniform server-based namespace that is capable 108 of spanning a whole enterprise and which is easy to manage. 110 We define some terms to better describe the solution space. A 111 "fileset" is the abstract view of a filesystem in a uniform 112 namespace, and may be implemented behind that abstraction by one or 113 more physical filesystems at any given time. Each fileset has a name 114 called an "FSN" (fileset name), and each physical filesystem has a 115 fileset location ("FSL"). A fileset is a directory tree containing 116 files and directories, and it may also contain references to other 117 filesets. These references are called "junctions". To provide 118 location independence, a junction does not contain information about 119 the location of the real resource(s), but instead contains an FSN 120 that can be used to look up the location information. The service 121 that can be used to map from FSN to FSL(s) is called a namespace 122 database (NSDB) service. The NSDB provides a level of indirection 123 from the virtual paths in the uniform namespace to the actual 124 locations of files. 126 The servers direct clients to the proper locations by existing 127 mechanisms (e.g. the referrals mechanism within [RFC3530] and 128 [NFSv4.1]). Updates to the locations make it possible to support 129 migration and replication of physical filesystems that comprise the 130 namespace, in a way that is transparent to filesystem clients. 132 Figure 1 shows an example of a federation. This federation has two 133 members, named ALPHA and BETA. Federation members may contain an 134 arbitrary number of file servers and NSDB nodes; in this illustration 135 ALPHA and BETA each have three servers and one NSDB node. 137 +----------------------+ +----------------------+ 138 | Federation Member | | Federation Member | 139 | ALPHA | | BETA | 140 | | | | 141 | | | | 142 | +------------+ | | +------------+ | 143 | | NSDB | | | | NSDB | | 144 | | | | | | | | 145 | +------------+ | | +------------+ | 146 | | | | 147 | | | | 148 | | | | 149 | +----------+ | | +----------+ | 150 | | | | | | | | 151 | +-- | Servers | | | +-- | Servers | | 152 | | | | | | | | | | 153 | +-- | | | | | +-- | | | | 154 | | | +----------+ | | | | +----------+ | 155 | | | | | | | | | | 156 | | +----------+ | | | +----------+ | 157 | | | | | | | | 158 | +----------+ | | +----------+ | 159 +----------------------+ +----------------------+ 161 A federation with two members, ALPHA and BETA. ALPHA and BETA each 162 have their own NSDB node and several file servers, and they are 163 administered separately. 165 Figure 1 167 3. Purpose 169 Our objective is to specify a set of protocols by which fileservers 170 or collections of fileservers, with different administrators, can 171 form a federation of fileservers and NSDB nodes that provides a 172 namespace composed of the filesets hosted on the different 173 fileservers and fileserver collections. 175 It should be possible, using a system that implements the protocols, 176 to share a common namespace across all the fileservers in the 177 federation. It should also be possible for different fileservers in 178 the federation to project different namespaces and enable clients to 179 traverse them. 181 Such a federation may contain an arbitrary number of NSDB nodes, each 182 belonging to a different administrative entity, and each providing 183 the mappings that define a part of a namespace. Such a federation 184 may also have an arbitrary number of administrative entities, each 185 responsible for administering a subset of the fileservers and NSDB 186 nodes. Acting in concert, the administrators should be able to build 187 and administer this multi-fileserver, multi-collection namespace. 189 It is not the intent of the federation to guarantee namespace 190 consistency across all client views. Since different parts of the 191 namespace may be administered by different entities, it is possible 192 that a client could be accessing a stale area of the namespace 193 managed by one entity because a part of the namespace above it, 194 managed by another entity, has changed. 196 4. Examples and Discussion 198 In this section we provide examples and discussion of the basic 199 operations facilitated by the federated file system protocol: 200 creating a fileset, adding a replica of a fileset, resolving a 201 junction, and creating a junction. 203 4.1. Create a Fileset and its FSL(s) 205 A fileset is the abstraction of a set of files and their containing 206 directory tree. The fileset abstraction is the fundamental unit of 207 data management in the federation. This abstraction is implemented 208 by an actual directory tree whose root location is specified by a 209 fileset location (FSL). 211 In this section, we describe the basic requirements for starting with 212 a directory tree and creating a fileset that can be used in the 213 federation protocols. Note that we do not assume that the process of 214 creating a fileset requires any transformation of the files or the 215 directory hierarchy. The only thing that is required by this process 216 is assigning the fileset a fileset name (FSN) and expressing the 217 location(s) of the implementation of the fileset as FSL(s). 219 There are many possible variations to this procedure, depending on 220 how the FSN that binds the FSL is created, and whether other replicas 221 of the fileset exist, are known to the federation, and need to be 222 bound to the same FSN. 224 It is easiest to describe this in terms of how to create the initial 225 implementation of the fileset, and then describe how to add replicas. 227 4.1.1. Creating a Fileset and an FSN 229 1. Choose the NSDB node that will keep track of the FSL(s) and 230 related information for the fileset. 232 2. Request that the NSDB node register a new FSN for the fileset. 234 The FSN may either be chosen by the NSDB node or by the server. 235 The latter case is used if the fileset is being restored, perhaps 236 as part of disaster recovery, and the server wishes to specify 237 the FSN in order to permit existing junctions that reference that 238 FSN to work again. 240 At this point, the FSN exists, but its location is unspecified. 242 3. Send the FSN, the local volume path, the export path, and the 243 export options for the local implementation of the fileset to the 244 NSDB node. Annotations about the FSN or the location may also be 245 sent. 247 The NSDB node records this info and creates the initial FSL for 248 the fileset. 250 4.1.2. Adding a Replica of a Fileset 252 Adding a replica is straightforward: the NSDB node and the FSN are 253 already known. The only remaining step is to add another FSL. 255 Note that the federation protocols do not include methods for 256 creating or managing replicas: this is assumed to be a platform- 257 dependent operation (at least at this time). The only requirement is 258 that these fileset replicas be registered and unregistered with the 259 NSDB. 261 4.2. Junction Resolution 263 A fileset may contain references to other filesets. These references 264 are represented by junctions. If a client requests access to a 265 fileset object that is a junction, the server resolves the junction 266 to discover the FSL(s) that implements the referenced fileset. 268 There are many possible variations to this procedure, depending on 269 how the junctions are represented and how the information necessary 270 to perform resolution is represented by the server. 272 Step 4 is the only step that interacts directly with the federation 273 protocols. The rest of the steps may use platform-specific 274 interfaces. 276 1. The server determines that the object being accessed is a 277 junction. 279 2. Using the junction, the server does a local lookup to find the 280 FSN of the target fileset. 282 3. Using the FSN, the server finds the NSDB node responsible for the 283 target object. 285 4. The server contacts that NSDB node and asks for the set of FSLs 286 that implement the target FSN. The NSDB node responds with a set 287 of FSLs. 289 5. The server converts one of the FSLs to the location type used by 290 the client (e.g., fs_location for NFSv4, as described in 291 [RFC3530]). 293 6. The server redirects (in whatever manner is appropriate for the 294 client) the client to the location(s). 296 These steps are illustrated in Figure 2. The client sends request 1 297 to server X, in federation member ALPHA, in an attempt to reference 298 an object (which appears to the client as a directory). Server X 299 recognizes that the referenced object is actually a junction that 300 refers to a directory in a different fileset. Server X finds, from 301 the FSN in the junction, that the NSDB responsible for knowing the 302 location of the target of the junction is the NSDB of federation 303 member BETA. Server X sends request 2 to the NSDB of BETA, asking 304 for the current location of the directory. The NSDB sends response 3 305 to server X, telling the server that the directory is located on 306 server Y. Server X sends response 4 to the client, indicating that 307 the directory is in a "new" location on server Y. The client then 308 sends request 5 to server Y, repeating the initial request. 310 Given the current requirements and definitions, this resolution 311 method MUST work. However, there is no requirement that this is the 312 only resolution method that can be used. This method may be used as 313 the fallback when all else fails (or, for a simple implementation, it 314 could be the only method). This is a degenerate implementation of 315 the NSDB service as a simple composition of NSDB nodes; we expect 316 that large federations will use more sophisticated methods to share 317 the FSN and FSL information among multiple NSDB nodes. 319 +---------------+ 320 | | 321 | Client | >--------------------------+ 322 | | | 323 +---------------+ | 324 v ^ | 325 +-----+---+-------------+ +-----------------+-----+ 326 | | | Federation| |Federation | | 327 | | | member | |member | | 328 | | | ALPHA | |BETA | | 329 | | | | | | | 330 | | | | | | | 331 | | | | | | | 332 | | | | | | | 333 | | | | | +---------+ | | 334 | | | +---------+------+-> | | | | 335 | | | | | | | NSDB Y | | | 336 | | | | +-----+------+-< | | | | 337 | | | | | | | +---------+ | | 338 | | | | | | | | | 339 | | | | | | | | | 340 | | | | | | | | | 341 | 1| 4| 2| 3| | | 5| | 342 | v ^ ^ v | | v | 343 | +---------------+ | | +---------------+ | 344 | | | | | | | | 345 | | Server X | | | | Server Y | | 346 | | | | | | | | 347 | +---------------+ | | +---------------+ | 348 | | | | 349 +-----------------------+ +-----------------------+ 351 Figure 2 353 4.3. Junction Creation 355 Given a local path, a remote export and a path relative to that 356 export, create a junction from the local path to the path within the 357 remote export. 359 There are many possible variations to this procedure, depending on 360 how the junctions are represented and how the information necessary 361 to perform resolution is represented by the server. 363 Step 1 is the only step that uses the federation interfaces. The 364 rest of the steps may use platform-specific interfaces. 366 1. Contact the server named by the export and ask for the FSN for 367 the fileset, given its path relative to that export. 369 2. Insert the junction to the FSN, at the given path, into the local 370 filesystem. 372 5. Glossary 374 Administrator: user with the necessary authority to initiate 375 administrative tasks on one or more servers. 377 Admin entity: A server or agent that administers a collection of 378 fileservers and persistently stores the namespace information. 380 Client: Any client that accesses the fileserver data using a 381 supported filesystem access protocol. 383 Federation: A set of server collections and singleton servers that 384 use a common set of interfaces and protocols in order to provide 385 to their clients a federated namespace accessible through a 386 filesystem access protocol. 388 Fileserver: A server exporting a filesystem via a network filesystem 389 access protocol. 391 Fileset: The abstraction of a set of files and their containing 392 directory tree. A fileset is the fundamental unit of data 393 management in the federation. 395 Note that all files within a fileset are descendants of one 396 directory, and that filesets do not span filesystems. 398 Filesystem: A self-contained unit of export for a fileserver, and 399 the mechanism used to implement filesets. The fileset does not 400 need to be rooted at the root of the filesystem, nor at the export 401 point for the filesystem. 403 A single filesystem MAY implement more than one fileset, if the 404 client protocol and the fileserver permit this. 406 Filesystem access protocol: A network filesystem access protocol 407 such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [RFC3530], or 408 CIFS. 410 FSL (Fileset location): The location of the implementation of a 411 fileset at a particular moment in time. A FSL MUST be something 412 that can be translated into a protocol-specific description of a 413 resource that a client can access directly, such as a fs_location 414 (for NFSv4), or share name (for CIFS). Note that not all FSLs 415 need to be explicitly exported as long as they are contained 416 within an exported path on the fileserver. 418 FSN (Fileset name): A platform-independent and globally unique name 419 for a fileset. Two FSLs that implement replicas of the same 420 fileset MUST have the same FSN, and if a fileset is migrated from 421 one location to another, the FSN of that fileset MUST remain the 422 same. 424 Junction: A filesystem object used to link a directory name in the 425 current fileset with an object within another fileset. The 426 server-side "link" from a leaf node in one fileset to the root of 427 another fileset. 429 Namespace: A filename/directory tree that a sufficiently-authorized 430 client can observe. 432 NSDB (Namespace Database Service): A service that maps FSNs to FSLs. 433 The NSDB may also be used to store other information, such as 434 annotations for these mappings and their components. 436 NSDB Node: The name or location of a server that implements part of 437 the NSDB service and is responsible for keeping track of the FSLs 438 (and related info) that implement a given partition of the FSNs. 440 Referral: A server response to a client access that directs the 441 client to evaluate the current object as a reference to an object 442 at a different location (specified by an FSL) in another fileset, 443 and possibly hosted on another fileserver. The client re-attempts 444 the access to the object at the new location. 446 Replica: A replica is a redundant implementation of a fileset. Each 447 replica shares the same FSN, but has a different FSL. 449 Replicas may be used to increase availability or performance. 450 Updates to replicas of the same fileset MUST appear to occur in 451 the same order, and therefore each replica is self-consistent at 452 any moment. 454 We do not assume that updates to each replica occur simultaneously 455 If a replica is offline or unreachable, the other replicas may be 456 updated. 458 Server Collection: A set of fileservers administered as a unit. A 459 server collection may be administered with vendor-specific 460 software. 462 The namespace provided by a server collection could be part of the 463 federated namespace. 465 Singleton Server: A server collection containing only one server; a 466 stand-alone fileserver. 468 6. Proposed Requirements 470 The phrase "USING THE FEDERATION INTERFACES" implies that the 471 subsequent requirement must be satisfied, in its entirety, via the 472 federation interfaces. 474 Note that the requirements are described in terms of correct behavior 475 by all entities. We do not address the requirements of the system in 476 the presence of faults. 478 6.1. Basic Assumptions 480 Several of the requirements are so fundamental that we treat them as 481 basic assumptions; if any of these assumptions are violated, the rest 482 of the requirements must be reviewed in their entirety. 484 A1: The federation protocols do not require any changes to existing 485 client-facing protocols, and MAY be extended to incorporate new 486 client-facing protocols. 488 A2: A client SHOULD NOT require any a priori knowledge of the 489 general structure or composition of the federation. 491 The client may require some specific knowledge in order to find 492 and access an instance of the fileset that defines the root of 493 its view of the namespace. As the client traverses the 494 namespace, the client discovers the information it needs in 495 order to locate the filesets it accesses. 497 A3: All requirements MUST be satisfiable via the federation 498 protocols and the standard protocols used by the fileservers 499 (i.e., NFS, CIFS, DNS, etc). 501 USING THE FEDERATION INTERFACES, a federation operation that 502 requires an interaction between two (or more) entities that are 503 members of the federation MUST be possible without requiring any 504 proprietary protocols. 506 A4: All the entities participating in a federation operation MUST be 507 able to authenticate each other. 509 All principals (clients, users, administrator of a singleton or 510 server collection, hosts, NSDB nodes, etc) that can assume a 511 role defined by the federation protocol can identify themselves 512 to each other via an authentication mechanism. This mechanism 513 is not defined or further described in this document. 515 The authority of a principal to request that a second principal 516 perform a specific operation is ultimately determined by the 517 second. Authorization may be partitioned by server collection 518 or set of servers as well as by operation. For example, if a 519 user has administrative privileges on one server in the 520 federation, this does not imply that they have administrative 521 privileges (or, for that matter, any privileges whatsoever) on 522 any other server in the federation. 524 In order to access the functionality provided by the federation 525 interfaces, it may be necessary to have elevated privileges or 526 authorization. The authority required by different operations 527 may be different. For example, the authority required to query 528 the NSDB about the FSLs bound to an FSN may be different than 529 the authority required to change the bindings of that FSN. 531 An operation attempted by an unauthorized entity MUST fail in a 532 manner that indicates that the failure was due to insufficient 533 authorization. 535 This document does not enumerate the authorization necessary for 536 any operation. 538 A5: The federation protocols MUST NOT require changes to existing 539 authentication/authorization mechanisms in use at the 540 fileservers for client-facing protocols. 542 A user's view of the namespace may be limited by the 543 authentication and authorization privileges it has on the 544 different fileservers in the federation. As such, users may 545 only be able to traverse the parts of the namespace that they 546 have access to. 548 The federation protocols do not impose any restrictions on how 549 users are represented within the federation. For example, a 550 single enterprise could employ a common identity for users 551 across the federation. A grid environment could utilize user 552 mapping or translations across different administrative domains. 554 A6: In a federated system, we assume that an FSN MUST express, or 555 can be used to discover, the following two pieces of 556 information: 558 1. The location of the NSDB node that is responsible for 559 knowing the filesystem location(s) (FSLs) of the named 560 fileset. 562 The NSDB node must be specified because there may be many 563 NSDB nodes in a federation. We do not assume that any 564 single entity knows the location of all of the NSDB nodes, 565 and therefore exhaustive search is not an option. 567 There are several ways in which a fileserver can locate the 568 NSDB node responsible for a given fileset. One approach, 569 given a DNS infrastructure, is to specify the location of 570 the NSDB node by the FQDN of the server hosting the NSDB 571 node. Another approach is to use a separate DNS-style 572 hierarchy to resolve the location of the NSDB node. 574 2. The FSN identifier. 576 The FSN identifier is the index used by the NSDB node to 577 identify the target fileset. 579 There are several ways to represent FSN identifiers. One 580 approach could use 128-bit UUIDs as described described in 581 [RFC4122]. 583 As an example, an FSN could be represented by a URL of the form 584 nsdb.example.com/UUID where nsdb.example.com is the FQDN of the 585 server hosting the NSDB node and UUID is the string 586 representation of the identifier. 588 Note that it is not assumed that it is always required for a 589 server to contact the NSDB node specified by the FSN in order to 590 find the FSLs. The relevant information stored in that NSDB 591 node may also be cached local to the server or on a proxy NSDB 592 node "near" the server. 594 A7: All federation servers and NSDB nodes are assumed to execute the 595 federation protocols correctly. The behavior of the federation 596 is undefined in the case of Byzantine behavior by any federation 597 server or NSDB node. 599 A8: The locations of federation services (such as NSDBs and FSLs) 600 can be specified in a manner such that they can be correctly 601 interpreted by all members of the federation that will access 602 them. 604 For example, if an NSDB node is specified by a FQDN, then this 605 implies that every member of the federation that needs to access 606 this NSDB node can resolve this FQDN to an IP address for that 607 NSDB node. (It is not necessary that the FQDN always resolve to 608 the same address; the same service may appear at different 609 addresses on different networks.) 611 It is the responsibility of each federation member to ensure 612 that the resources it wishes to expose have accessible network 613 locations and that the necessary resolution mechanisms (i.e., 614 DNS) are given the necessary data to perform the resolution 615 correctly. 617 6.2. Requirements 619 R1: Requirements of each FSN: 621 a. Each FSN MUST be unique within the scope of its NSDB (so 622 that the FSN is globally unique). 624 b. The FSN MUST be sufficiently descriptive to locate an 625 instance of the fileset it names within the federation at 626 any time. 628 c. All FSNs MUST be invariant when their underlying 629 filesystems move or are replicated; only mappings from FSN 630 to FSL(s) change under these transformations. 632 d. All files accessible from the global namespace MUST be part 633 of a fileset that has an assigned FSN. 635 Not all filesets in the federation are required to have an FSN 636 or be reachable by an FSL. Only those filesets that are the 637 target of a junction (as described in R3) are required to have 638 an FSN. 640 R2: USING THE FEDERATION INTERFACES, it MUST be possible to create 641 an FSN for a fileset, and it must be possible to bind an FSL to 642 that FSN. These operations are NSDB operations and do not 643 require any action on the part of a file server. 645 It is possible to create an FSN for a fileset that has not 646 actually been created. It is also possible to bind a 647 nonexistent FSL to an FSN. It is also possible to create a 648 fileset without assigning it an FSN. The binding between an 649 FSN and an FSL is defined entirely within the context of the 650 NSDB; the servers do not "know" whether the filesets they host 651 have been assigned FSNs (or, if so, what those FSNs are). 653 The requirement that filesets can exist prior to being assigned 654 an FSN, and the requirement that FSNs can exist independent of 655 filesets are intended to simplify the construction of the 656 namespace in a convenient manner. For example, they permit an 657 admin to assign FSNs to existing filesets and thereby 658 incorporate existing filesets into the namespace. They also 659 permit the structure of the namespace to be defined prior to 660 creation of the component filesets. In either case, it is the 661 responsibility of the entity updating the NSDB with FSNs and 662 FSN-to-FSL mappings to ensure that the namespace is constructed 663 in a consistent manner. (The simplest way to accomplish this 664 is to ensure that the FSN and FSN-to-FSL mappings are always 665 recorded in the NSDB prior to the creation of any junctions 666 that refer to that FSN.) 668 a. An administrator MAY specify the entire FSN (including both 669 the NSDB node location and the identifier) of the newly- 670 created FSL, or the administrator MAY specify only the NSDB 671 node and have the system choose the identifier. 673 The admin can choose to specify the FSN explicitly in order 674 to recreate a lost fileset with a given FSN (for example, 675 as part of disaster recovery). It is an error to assign an 676 FSN that is already in use by an active fileset. 678 Note that creating a replica of an existing filesystem is 679 NOT accomplished by assigning the FSN of the filesystem you 680 wish to replicate to a new filesystem. 682 b. USING THE FEDERATION INTERFACES, it MUST be possible to 683 create a federation FSL by specifying a specific local 684 volume, path, export path, and export options. 686 R3: USING THE FEDERATION INTERFACES, and given the FSN of a target 687 fileset, it MUST be possible to create a junction to that 688 fileset at a named place in another fileset. 690 After a junction has been created, clients that access the 691 junction transparently interpret it as a reference to the 692 FSL(s) that implement the FSN associated with the junction. 694 a. It SHOULD be possible to have more than one junction whose 695 target is a given fileset. In other words, it SHOULD be 696 possible to mount a fileset at multiple named places. 698 b. If the fileset in which the junction is created is 699 replicated, then the junction MUST eventually appear in all 700 of its replicas. 702 The operation of creating a junction within a fileset is 703 treated as an update to the fileset, and therefore obey the 704 general rules about updates to replicated filesets. 706 R4: USING THE FEDERATION INTERFACES, it MUST be possible to delete 707 a specific junction from a fileset. 709 If a junction is deleted, clients who are already viewing the 710 fileset referred to by the junction after traversing the 711 junction MAY continue to view the old namespace. They might 712 not discover that the junction no longer exists (or has been 713 deleted and replaced with a new junction, possibly referring to 714 a different FSN). 716 After a junction is deleted, another object with the same name 717 (another junction, or an ordinary filesystem object) may be 718 created. 720 The operation of deleting a junction within a fileset is 721 treated as an update to the fileset, and therefore obey the 722 general rules about updates to replicated filesets. 724 R5: USING THE FEDERATION INTERFACES, it MUST be possible to 725 invalidate an FSN. 727 a. If a junction refers to an FSN that is invalid, attempting 728 to traverse the junction MUST fail. 730 An FSN that has been invalidated MAY become valid again if the 731 FSN is recreated (i.e., as part of a disaster recovery 732 process). 734 If an FSN is invalidated, clients who are already viewing the 735 fileset named by the FSN MAY continue to view the old 736 namespace. They might not discover that the FSN is no longer 737 valid until they try to traverse a junction that refers to it. 739 R6: USING THE FEDERATION INTERFACES, it MUST be possible to 740 invalidate an FSL. 742 a. An invalid FSL MUST NOT be returned as the result of 743 resolving a junction. 745 An FSL that has been invalidated MAY become valid again if the 746 FSL is recreated (i.e., as part of a disaster recovery 747 process). 749 If an FSL is invalidated, clients who are already viewing the 750 fileset implemented by the FSL MAY continue to use that FSL. 751 They might not discover that the FSL is no longer valid until 752 they try to traverse a junction that refers to the fileset 753 implemented by the FSL. 755 Note that invalidating an FSL does not imply that the 756 underlying export or share (depending on the file access 757 protocol in use) is changed in any way -- it only changes the 758 mappings from FSNs to FSLs on the NSDB. 760 R7: It MUST be possible for the federation of servers to provide 761 multiple namespaces. 763 R8: USING THE FEDERATION INTERFACES: 765 a. It MUST be possible to query the fileserver named in an FSL 766 to discover whether a junction exists at a given path 767 within that FSL. 769 b. It MAY be possible to query the fileserver named in an FSL 770 to discover the junctions, if any, in that FSL. If this 771 feature is implemented, the fileserver SHOULD report each 772 junction's path within the FSL and the targeted FSN. 774 R9: The projected namespace (and the objects named by the 775 namespace) MUST be accessible to clients via at least one 776 standard filesystem access protocol. 778 a. The namespace SHOULD be accessible to clients via versions 779 of the CIFS (SMB) protocol. 781 b. The namespace SHOULD be accessible to clients via the NFSv4 782 protocol as described in [RFC3530]. 784 c. The namespace SHOULD be accessible to clients via the NFSv3 785 protocol as described in [RFC1813]. 787 d. The namespace SHOULD be accessible to clients via the NFSv2 788 protocol as described in [RFC1094]. 790 It must be understood that some of these protocols, such as 791 NFSv3 and NFSv2, have no innate ability to access a namespace 792 of this kind. Where such protocols have been augmented with 793 other protocols and mechanisms (such as autofs or amd for 794 NFSv3) to provide an extended namespace, we propose that these 795 protocols and mechanisms may be used, or extended, in order to 796 satisfy the requirements given in this draft, and different 797 clients may use different mechanisms. 799 R10: USING THE FEDERATION INTERFACES, it MUST be possible to modify 800 the NSDB mapping from an FSN to a set of FSLs to reflect the 801 migration from one FSL to another. 803 R11: FSL migration SHOULD have little or no impact on the clients, 804 but this is not guaranteed across all federation members. 806 Whether FSL migration is performed transparently depends on 807 whether the source and destination servers are able to do so. 808 It is the responsibility of the administrator to recognize 809 whether or not the migration will be transparent, and advise 810 the system accordingly. The federation, in turn, MUST advise 811 the servers to notify their clients, if necessary. 813 For example, on some systems, it may be possible to migrate a 814 fileset from one system to another with minimal client impact 815 because all client-visible metadata (inode numbers, etc) are 816 preserved during migration. On other systems, migration might 817 be quite disruptive. 819 R12: USING THE FEDERATION INTERFACES, it MUST be possible to modify 820 the NSDB mapping from an FSN to a set of FSLs to reflect the 821 addition/removal of a replica at a given FSL. 823 R13: Replication SHOULD have little or no negative impact on the 824 clients. 826 Whether FSL replication is performed transparently depends on 827 whether the source and destination servers are able to do so. 828 It is the responsibility of the administrator initiating the 829 replication to recognize whether or not the replication will be 830 transparent, and advise the federation accordingly. The 831 federation MUST advise the servers to notify their clients, if 832 necessary. 834 For example, on some systems, it may be possible to mount any 835 FSL of an FSN read/write, while on other systems, there may be 836 any number of read-only replicas but only one FSL that can be 837 mounted read-write. 839 R14: USING THE FEDERATION INTERFACES, it SHOULD be possible to 840 annotate the objects and relations managed by the federation 841 protocol with arbitrary name/value pairs. 843 These annotations are not used by the federation protocols -- 844 they are intended for use by higher-level protocols. For 845 example, an annotation that might be useful for a system 846 administrator browsing the federation would be the "owner" of 847 each FSN (i.e., "this FSN is for the home directory of Joe 848 Smith."). As another example, the annotations may express 849 hints used by the clients (such as priority information for 850 NFSv4.1). 852 Both FSNs and FSLs may be annotated. For example, an FSN 853 property might be "This is Joe Smith's home directory", and an 854 FSL property might be "This instance of the FSN is at the 855 remote backup site." 857 a. USING THE FEDERATION INTERFACES, it MUST be possible to 858 query the system to find the annotations for a junction. 860 b. USING THE FEDERATION INTERFACES, it MUST be possible to 861 query the system to find the annotations for an FSN. 863 c. USING THE FEDERATION INTERFACES, it MUST be possible to 864 query the system to find the annotations for an FSL. 866 R15: It MUST be possible for the federation to project a namespace 867 with a common root. 869 a. It SHOULD be possible to define a root fileset that is 870 exported by one or more fileservers in the federation as 871 the top level of a namespace. [Corollary: There is one 872 root fileset per namespace and it is possible to support 873 multiple namespaces per federation.] 875 b. It SHOULD be possible for a fileserver to locate an NSDB 876 that stores the layout of a root fileset. 878 c. It SHOULD be possible to access, store and update 879 information related to a root fileset using the federation 880 protocols. 882 d. It SHOULD be possible to replicate root fileset information 883 across multiple repositories. 885 e. If a root fileset is defined it SHOULD be possible to 886 enable a file server to export that root fileset for client 887 access. 889 f. If a root fileset is defined it SHOULD be possible for 890 multiple file servers to project a common root with defined 891 consistency semantics. 893 g. If a root fileset is defined it SHOULD be stored using a 894 compact representation that is compatible with 895 heterogeneous fileserver implementations. The root 896 fileset's internal format SHOULD contain enough information 897 to generate any attributes, including referrals, required 898 by the standard filesystem access protocols in R9. 900 7. Non-Requirements 902 N1: It is not necessary for the namespace to be known by any 903 specific fileserver. 905 In the same manner that clients do not need to have a priori 906 knowledge of the structure of the namespace or its mapping onto 907 federation members, the projected namespace can exist without 908 individual fileservers knowing the entire organizational 909 structure, or, indeed, without knowing exactly where in the 910 projected namespace the filesets they host exist. 912 Fileservers do need to be able to handle referrals from other 913 fileservers, but they do not need to know what path the client 914 was accessing when the referral was generated. 916 N2: It is not necessary for updates and accesses to the federation 917 data to occur in transaction or transaction-like contexts. 919 One possible requirement that is omitted from our current list 920 is that updates and accesses to the data stored in the NSDB (or 921 individual NSDB nodes) occur within a transaction context. We 922 were not able to agree whether the benefits of transactions are 923 worth the complexity they add (both to the specification and its 924 eventual implementation) but this topic is open for discussion. 926 Below is the the draft of a proposed requirement that provides 927 transactional semantics: 929 "There MUST be a way to ensure that sequences of operations, 930 including observations of the namespace (including finding 931 the locations corresponding to a set of FSNs) and changes to 932 the namespace or related data stored in the system (including 933 the creation, renaming, or deletion of junctions, and the 934 creation, altering, or deletion of mappings between FSN and 935 filesystem locations), can be performed in a manner that 936 provides predictable semantics for the relationship between 937 the observed values and the effect of the changes." 939 "It MUST be possible to protect sequences of operations by 940 transactions with NSDB-wide or server-wide ACID semantics." 942 8. Security Considerations 944 Assuming the Internet threat model, the federated resolution 945 mechanism described in this document MUST be implemented in such a 946 way to prevent loss of CONFIDENTIALITY, DATA INTEGRITY and PEER 947 ENTITY AUTHENTICATION, as described in [RFC3552]. 949 CONFIDENTIALITY may be violated if an unauthorized party is able to 950 eavesdrop on the communication between authorized servers and NSDB 951 nodes and thereby learn the locations or other information about FSNs 952 that they would not be authorized to discover via direct queries. 953 DATA INTEGRITY may be compromised if a third party is able to 954 undetectably alter the contents of the communication between servers 955 and NSDB nodes. PEER ENTITY AUTHENTICATION is defeated if one server 956 can masquerade as another server without proper authority, or if an 957 arbitrary host can masquerade as a NSDB node. 959 Well-established techniques for providing authenticated channels may 960 be used to defeat these attacks, and the protocol MUST support at 961 least one of them. 963 For example, if LDAP is used to implement the query mechanism 964 [RFC4510], then TLS may be used to provide both authentication and 965 integrity [RFC5246] [RFC4513]. If the query protocol is implemented 966 on top of ONC/RPC, then RPCSEC_GSS may be used to fill the same role 967 [RFC2203] [RFC2743]. 969 9. IANA Considerations 971 This document has no actions for IANA. 973 10. References 975 10.1. Normative References 977 [NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4 978 Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (work 979 in progress), December 2008. 981 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 982 Requirement Levels", BCP 14, RFC 2119, March 1997. 984 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 985 Specification", RFC 2203, September 1997. 987 [RFC2743] Linn, J., "Generic Security Service Application Program 988 Interface Version 2, Update 1", RFC 2743, January 2000. 990 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 991 Beame, C., Eisler, M., and D. Noveck, "Network File System 992 (NFS) version 4 Protocol", RFC 3530, April 2003. 994 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 995 Text on Security Considerations", BCP 72, RFC 3552, 996 July 2003. 998 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 999 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1000 July 2005. 1002 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 1003 (LDAP): Technical Specification Road Map", RFC 4510, 1004 June 2006. 1006 [RFC4513] Harrison, R., "Lightweight Directory Access Protocol 1007 (LDAP): Authentication Methods and Security Mechanisms", 1008 RFC 4513, June 2006. 1010 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1011 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1013 10.2. Informational References 1015 [RFC1094] Nowicki, B., "NFS: Network File System Protocol 1016 specification", RFC 1094, March 1989. 1018 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 1019 Version 3 Protocol Specification", RFC 1813, June 1995. 1021 Appendix A. Acknowledgments 1023 We would like to thank Robert Thurlow of Sun Microsystems for helping 1024 to author this document. 1026 Authors' Addresses 1028 James Lentini 1029 NetApp 1030 1601 Trapelo Rd, Suite 16 1031 Waltham, MA 02451 1032 US 1034 Phone: +1 781-768-5359 1035 Email: jlentini@netapp.com 1037 Craig Everhart 1038 NetApp 1039 7301 Kit Creek Rd 1040 Research Triangle Park, NC 27709 1041 US 1043 Phone: +1 919-476-5320 1044 Email: everhart@netapp.com 1046 Daniel Ellard 1047 BBN Technologies 1048 10 Moulton Street 1049 Cambridge, MA 02138 1050 US 1052 Phone: +1 617-873-8000 1053 Email: dellard@bbn.com 1055 Renu Tewari 1056 IBM Almaden 1057 650 Harry Rd 1058 San Jose, CA 95120 1059 US 1061 Email: tewarir@us.ibm.com 1062 Manoj Naik 1063 IBM Almaden 1064 650 Harry Rd 1065 San Jose, CA 95120 1066 US 1068 Email: manoj@almaden.ibm.com