idnits 2.17.1 draft-ietf-nfsv4-federated-fs-reqts-03.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 (May 18, 2009) is 5450 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: November 19, 2009 D. Ellard 6 BBN Technologies 7 R. Tewari 8 M. Naik 9 IBM Almaden 10 May 18, 2009 12 Requirements for Federated File Systems 13 draft-ietf-nfsv4-federated-fs-reqts-03 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 November 19, 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 applications. 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 and the FSN of a remote fileset, an administrator 356 can create a junction from the local path to the remote fileset. 358 There are many possible variations to this procedure, depending on 359 how the junctions are represented and how the information necessary 360 to perform resolution is represented by the server. 362 Step 1 is the only step that uses the federation interfaces. The 363 remaining step may use platform-specific interfaces. 365 1. The administrator requests the server create a junction to the 366 FSN of the remote fileset at the given path. 368 2. The server inserts the junction to the FSN, at the given path, 369 into the local filesystem. 371 5. Glossary 373 Administrator: user with the necessary authority to initiate 374 administrative tasks on one or more servers. 376 Admin entity: A server or agent that administers a collection of 377 fileservers and persistently stores the namespace information. 379 Client: Any client that accesses the fileserver data using a 380 supported filesystem access protocol. 382 Federation: A set of server collections and singleton servers that 383 use a common set of interfaces and protocols in order to provide 384 to their clients a federated namespace accessible through a 385 filesystem access protocol. 387 Fileserver: A server exporting a filesystem via a network filesystem 388 access protocol. 390 Fileset: The abstraction of a set of files and their containing 391 directory tree. A fileset is the fundamental unit of data 392 management in the federation. 394 Note that all files within a fileset are descendants of one 395 directory, and that filesets do not span filesystems. 397 Filesystem: A self-contained unit of export for a fileserver, and 398 the mechanism used to implement filesets. The fileset does not 399 need to be rooted at the root of the filesystem, nor at the export 400 point for the filesystem. 402 A single filesystem MAY implement more than one fileset, if the 403 client protocol and the fileserver permit this. 405 Filesystem access protocol: A network filesystem access protocol 406 such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [RFC3530], or 407 CIFS. 409 FSL (Fileset location): The location of the implementation of a 410 fileset at a particular moment in time. A FSL MUST be something 411 that can be translated into a protocol-specific description of a 412 resource that a client can access directly, such as a fs_location 413 (for NFSv4), or share name (for CIFS). Note that not all FSLs 414 need to be explicitly exported as long as they are contained 415 within an exported path on the fileserver. 417 FSN (Fileset name): A platform-independent and globally unique name 418 for a fileset. Two FSLs that implement replicas of the same 419 fileset MUST have the same FSN, and if a fileset is migrated from 420 one location to another, the FSN of that fileset MUST remain the 421 same. 423 Junction: A filesystem object used to link a directory name in the 424 current fileset with an object within another fileset. The 425 server-side "link" from a leaf node in one fileset to the root of 426 another fileset. 428 Namespace: A filename/directory tree that a sufficiently-authorized 429 client can observe. 431 NSDB (Namespace Database Service): A service that maps FSNs to FSLs. 432 The NSDB may also be used to store other information, such as 433 annotations for these mappings and their components. 435 NSDB Node: The name or location of a server that implements part of 436 the NSDB service and is responsible for keeping track of the FSLs 437 (and related info) that implement a given partition of the FSNs. 439 Referral: A server response to a client access that directs the 440 client to evaluate the current object as a reference to an object 441 at a different location (specified by an FSL) in another fileset, 442 and possibly hosted on another fileserver. The client re-attempts 443 the access to the object at the new location. 445 Replica: A replica is a redundant implementation of a fileset. Each 446 replica shares the same FSN, but has a different FSL. 448 Replicas may be used to increase availability or performance. 449 Updates to replicas of the same fileset MUST appear to occur in 450 the same order, and therefore each replica is self-consistent at 451 any moment. 453 We do not assume that updates to each replica occur simultaneously 454 If a replica is offline or unreachable, the other replicas may be 455 updated. 457 Server Collection: A set of fileservers administered as a unit. A 458 server collection may be administered with vendor-specific 459 software. 461 The namespace provided by a server collection could be part of the 462 federated namespace. 464 Singleton Server: A server collection containing only one server; a 465 stand-alone fileserver. 467 6. Proposed Requirements 469 The phrase "USING THE FEDERATION INTERFACES" implies that the 470 subsequent requirement must be satisfied, in its entirety, via the 471 federation interfaces. 473 Note that the requirements are described in terms of correct behavior 474 by all entities. We do not address the requirements of the system in 475 the presence of faults. 477 6.1. Basic Assumptions 479 Several of the requirements are so fundamental that we treat them as 480 basic assumptions; if any of these assumptions are violated, the rest 481 of the requirements must be reviewed in their entirety. 483 A1: The federation protocols do not require any changes to existing 484 client-facing protocols, and MAY be extended to incorporate new 485 client-facing protocols. 487 A2: A client SHOULD NOT require any a priori knowledge of the 488 general structure or composition of the federation. 490 The client may require some specific knowledge in order to find 491 and access an instance of the fileset that defines the root of 492 its view of the namespace. As the client traverses the 493 namespace, the client discovers the information it needs in 494 order to locate the filesets it accesses. 496 A3: All requirements MUST be satisfiable via the federation 497 protocols and the standard protocols used by the fileservers 498 (i.e., NFS, CIFS, DNS, etc). 500 USING THE FEDERATION INTERFACES, a federation operation that 501 requires an interaction between two (or more) entities that are 502 members of the federation MUST be possible without requiring any 503 proprietary protocols. 505 A4: All the entities participating in a federation operation MUST be 506 able to authenticate each other. 508 All principals (clients, users, administrator of a singleton or 509 server collection, hosts, NSDB nodes, etc) that can assume a 510 role defined by the federation protocol can identify themselves 511 to each other via an authentication mechanism. This mechanism 512 is not defined or further described in this document. 514 The authority of a principal to request that a second principal 515 perform a specific operation is ultimately determined by the 516 second. Authorization may be partitioned by server collection 517 or set of servers as well as by operation. For example, if a 518 user has administrative privileges on one server in the 519 federation, this does not imply that they have administrative 520 privileges (or, for that matter, any privileges whatsoever) on 521 any other server in the federation. 523 In order to access the functionality provided by the federation 524 interfaces, it may be necessary to have elevated privileges or 525 authorization. The authority required by different operations 526 may be different. For example, the authority required to query 527 the NSDB about the FSLs bound to an FSN may be different than 528 the authority required to change the bindings of that FSN. 530 An operation attempted by an unauthorized entity MUST fail in a 531 manner that indicates that the failure was due to insufficient 532 authorization. 534 This document does not enumerate the authorization necessary for 535 any operation. 537 A5: The federation protocols MUST NOT require changes to existing 538 authentication/authorization mechanisms in use at the 539 fileservers for client-facing protocols. 541 A user's view of the namespace may be limited by the 542 authentication and authorization privileges it has on the 543 different fileservers in the federation. As such, users may 544 only be able to traverse the parts of the namespace that they 545 have access to. 547 The federation protocols do not impose any restrictions on how 548 users are represented within the federation. For example, a 549 single enterprise could employ a common identity for users 550 across the federation. A grid environment could utilize user 551 mapping or translations across different administrative domains. 553 A6: In a federated system, we assume that an FSN MUST express, or 554 can be used to discover, the following two pieces of 555 information: 557 1. The location of the NSDB node that is responsible for 558 knowing the filesystem location(s) (FSLs) of the named 559 fileset. 561 The NSDB node must be specified because there may be many 562 NSDB nodes in a federation. We do not assume that any 563 single entity knows the location of all of the NSDB nodes, 564 and therefore exhaustive search is not an option. 566 There are several ways in which a fileserver can locate the 567 NSDB node responsible for a given fileset. One approach, 568 given a DNS infrastructure, is to specify the location of 569 the NSDB node by the FQDN of the server hosting the NSDB 570 node. Another approach is to use a separate DNS-style 571 hierarchy to resolve the location of the NSDB node. 573 2. The FSN identifier. 575 The FSN identifier is the index used by the NSDB node to 576 identify the target fileset. 578 There are several ways to represent FSN identifiers. One 579 approach could use 128-bit UUIDs as described described in 580 [RFC4122]. 582 As an example, an FSN could be represented by a URL of the form 583 nsdb.example.com/UUID where nsdb.example.com is the FQDN of the 584 server hosting the NSDB node and UUID is the string 585 representation of the identifier. 587 Note that it is not assumed that it is always required for a 588 server to contact the NSDB node specified by the FSN in order to 589 find the FSLs. The relevant information stored in that NSDB 590 node may also be cached local to the server or on a proxy NSDB 591 node "near" the server. 593 A7: All federation servers and NSDB nodes are assumed to execute the 594 federation protocols correctly. The behavior of the federation 595 is undefined in the case of Byzantine behavior by any federation 596 server or NSDB node. 598 A8: The locations of federation services (such as NSDBs and FSLs) 599 can be specified in a manner such that they can be correctly 600 interpreted by all members of the federation that will access 601 them. 603 For example, if an NSDB node is specified by a FQDN, then this 604 implies that every member of the federation that needs to access 605 this NSDB node can resolve this FQDN to an IP address for that 606 NSDB node. (It is not necessary that the FQDN always resolve to 607 the same address; the same service may appear at different 608 addresses on different networks.) 610 It is the responsibility of each federation member to ensure 611 that the resources it wishes to expose have accessible network 612 locations and that the necessary resolution mechanisms (i.e., 613 DNS) are given the necessary data to perform the resolution 614 correctly. 616 6.2. Requirements 618 R1: Requirements of each FSN: 620 a. Each FSN MUST be unique within the scope of its NSDB (so 621 that the FSN is globally unique). 623 b. The FSN MUST be sufficiently descriptive to locate an 624 instance of the fileset it names within the federation at 625 any time. 627 c. All FSNs MUST be invariant when their underlying 628 filesystems move or are replicated; only mappings from FSN 629 to FSL(s) change under these transformations. 631 d. All files accessible from the global namespace MUST be part 632 of a fileset that has an assigned FSN. 634 Not all filesets in the federation are required to have an FSN 635 or be reachable by an FSL. Only those filesets that are the 636 target of a junction (as described in R3) are required to have 637 an FSN. 639 R2: USING THE FEDERATION INTERFACES, it MUST be possible to create 640 an FSN for a fileset, and it must be possible to bind an FSL to 641 that FSN. These operations are NSDB operations and do not 642 require any action on the part of a file server. 644 It is possible to create an FSN for a fileset that has not 645 actually been created. It is also possible to bind a 646 nonexistent FSL to an FSN. It is also possible to create a 647 fileset without assigning it an FSN. The binding between an 648 FSN and an FSL is defined entirely within the context of the 649 NSDB; the servers do not "know" whether the filesets they host 650 have been assigned FSNs (or, if so, what those FSNs are). 652 The requirement that filesets can exist prior to being assigned 653 an FSN, and the requirement that FSNs can exist independent of 654 filesets are intended to simplify the construction of the 655 namespace in a convenient manner. For example, they permit an 656 admin to assign FSNs to existing filesets and thereby 657 incorporate existing filesets into the namespace. They also 658 permit the structure of the namespace to be defined prior to 659 creation of the component filesets. In either case, it is the 660 responsibility of the entity updating the NSDB with FSNs and 661 FSN-to-FSL mappings to ensure that the namespace is constructed 662 in a consistent manner. (The simplest way to accomplish this 663 is to ensure that the FSN and FSN-to-FSL mappings are always 664 recorded in the NSDB prior to the creation of any junctions 665 that refer to that FSN.) 667 a. An administrator MAY specify the entire FSN (including both 668 the NSDB node location and the identifier) of the newly- 669 created FSL, or the administrator MAY specify only the NSDB 670 node and have the system choose the identifier. 672 The admin can choose to specify the FSN explicitly in order 673 to recreate a lost fileset with a given FSN (for example, 674 as part of disaster recovery). It is an error to assign an 675 FSN that is already in use by an active fileset. 677 Note that creating a replica of an existing filesystem is 678 NOT accomplished by assigning the FSN of the filesystem you 679 wish to replicate to a new filesystem. 681 b. USING THE FEDERATION INTERFACES, it MUST be possible to 682 create a federation FSL by specifying a specific local 683 volume, path, export path, and export options. 685 R3: USING THE FEDERATION INTERFACES, and given the FSN of a target 686 fileset, it MUST be possible to create a junction to that 687 fileset at a named place in another fileset. 689 After a junction has been created, clients that access the 690 junction transparently interpret it as a reference to the 691 FSL(s) that implement the FSN associated with the junction. 693 a. It SHOULD be possible to have more than one junction whose 694 target is a given fileset. In other words, it SHOULD be 695 possible to mount a fileset at multiple named places. 697 b. If the fileset in which the junction is created is 698 replicated, then the junction MUST eventually appear in all 699 of its replicas. 701 The operation of creating a junction within a fileset is 702 treated as an update to the fileset, and therefore obey the 703 general rules about updates to replicated filesets. 705 R4: USING THE FEDERATION INTERFACES, it MUST be possible to delete 706 a specific junction from a fileset. 708 If a junction is deleted, clients who are already viewing the 709 fileset referred to by the junction after traversing the 710 junction MAY continue to view the old namespace. They might 711 not discover that the junction no longer exists (or has been 712 deleted and replaced with a new junction, possibly referring to 713 a different FSN). 715 After a junction is deleted, another object with the same name 716 (another junction, or an ordinary filesystem object) may be 717 created. 719 The operation of deleting a junction within a fileset is 720 treated as an update to the fileset, and therefore obey the 721 general rules about updates to replicated filesets. 723 R5: USING THE FEDERATION INTERFACES, it MUST be possible to 724 invalidate an FSN. 726 a. If a junction refers to an FSN that is invalid, attempting 727 to traverse the junction MUST fail. 729 An FSN that has been invalidated MAY become valid again if the 730 FSN is recreated (i.e., as part of a disaster recovery 731 process). 733 If an FSN is invalidated, clients who are already viewing the 734 fileset named by the FSN MAY continue to view the old 735 namespace. They might not discover that the FSN is no longer 736 valid until they try to traverse a junction that refers to it. 738 R6: USING THE FEDERATION INTERFACES, it MUST be possible to 739 invalidate an FSL. 741 a. An invalid FSL MUST NOT be returned as the result of 742 resolving a junction. 744 An FSL that has been invalidated MAY become valid again if the 745 FSL is recreated (i.e., as part of a disaster recovery 746 process). 748 If an FSL is invalidated, clients who are already viewing the 749 fileset implemented by the FSL MAY continue to use that FSL. 750 They might not discover that the FSL is no longer valid until 751 they try to traverse a junction that refers to the fileset 752 implemented by the FSL. 754 Note that invalidating an FSL does not imply that the 755 underlying export or share (depending on the file access 756 protocol in use) is changed in any way -- it only changes the 757 mappings from FSNs to FSLs on the NSDB. 759 R7: It MUST be possible for the federation of servers to provide 760 multiple namespaces. 762 R8: USING THE FEDERATION INTERFACES: 764 a. It MUST be possible to query the fileserver named in an FSL 765 to discover whether a junction exists at a given path 766 within that FSL. 768 b. It MAY be possible to query the fileserver named in an FSL 769 to discover the junctions, if any, in that FSL. If this 770 feature is implemented, the fileserver SHOULD report each 771 junction's path within the FSL and the targeted FSN. 773 R9: The projected namespace (and the objects named by the 774 namespace) MUST be accessible to clients via at least one 775 standard filesystem access protocol. 777 a. The namespace SHOULD be accessible to clients via versions 778 of the CIFS (SMB) protocol. 780 b. The namespace SHOULD be accessible to clients via the NFSv4 781 protocol as described in [RFC3530]. 783 c. The namespace SHOULD be accessible to clients via the NFSv3 784 protocol as described in [RFC1813]. 786 d. The namespace SHOULD be accessible to clients via the NFSv2 787 protocol as described in [RFC1094]. 789 It must be understood that some of these protocols, such as 790 NFSv3 and NFSv2, have no innate ability to access a namespace 791 of this kind. Where such protocols have been augmented with 792 other protocols and mechanisms (such as autofs or amd for 793 NFSv3) to provide an extended namespace, we propose that these 794 protocols and mechanisms may be used, or extended, in order to 795 satisfy the requirements given in this draft, and different 796 clients may use different mechanisms. 798 R10: USING THE FEDERATION INTERFACES, it MUST be possible to modify 799 the NSDB mapping from an FSN to a set of FSLs to reflect the 800 migration from one FSL to another. 802 R11: FSL migration SHOULD have little or no impact on the clients, 803 but this is not guaranteed across all federation members. 805 Whether FSL migration is performed transparently depends on 806 whether the source and destination servers are able to do so. 807 It is the responsibility of the administrator to recognize 808 whether or not the migration will be transparent, and advise 809 the system accordingly. The federation, in turn, MUST advise 810 the servers to notify their clients, if necessary. 812 For example, on some systems, it may be possible to migrate a 813 fileset from one system to another with minimal client impact 814 because all client-visible metadata (inode numbers, etc) are 815 preserved during migration. On other systems, migration might 816 be quite disruptive. 818 R12: USING THE FEDERATION INTERFACES, it MUST be possible to modify 819 the NSDB mapping from an FSN to a set of FSLs to reflect the 820 addition/removal of a replica at a given FSL. 822 R13: Replication SHOULD have little or no negative impact on the 823 clients. 825 Whether FSL replication is performed transparently depends on 826 whether the source and destination servers are able to do so. 827 It is the responsibility of the administrator initiating the 828 replication to recognize whether or not the replication will be 829 transparent, and advise the federation accordingly. The 830 federation MUST advise the servers to notify their clients, if 831 necessary. 833 For example, on some systems, it may be possible to mount any 834 FSL of an FSN read/write, while on other systems, there may be 835 any number of read-only replicas but only one FSL that can be 836 mounted read-write. 838 R14: USING THE FEDERATION INTERFACES, it SHOULD be possible to 839 annotate the objects and relations managed by the federation 840 protocol with arbitrary name/value pairs. 842 These annotations are not used by the federation protocols -- 843 they are intended for use by higher-level protocols. For 844 example, an annotation that might be useful for a system 845 administrator browsing the federation would be the "owner" of 846 each FSN (i.e., "this FSN is for the home directory of Joe 847 Smith."). As another example, the annotations may express 848 hints used by the clients (such as priority information for 849 NFSv4.1). 851 Both FSNs and FSLs may be annotated. For example, an FSN 852 property might be "This is Joe Smith's home directory", and an 853 FSL property might be "This instance of the FSN is at the 854 remote backup site." 856 a. USING THE FEDERATION INTERFACES, it MUST be possible to 857 query the system to find the annotations for a junction. 859 b. USING THE FEDERATION INTERFACES, it MUST be possible to 860 query the system to find the annotations for an FSN. 862 c. USING THE FEDERATION INTERFACES, it MUST be possible to 863 query the system to find the annotations for an FSL. 865 R15: It MUST be possible for the federation to project a namespace 866 with a common root. 868 a. It SHOULD be possible to define a root fileset that is 869 exported by one or more fileservers in the federation as 870 the top level of a namespace. [Corollary: There is one 871 root fileset per namespace and it is possible to support 872 multiple namespaces per federation.] 874 b. It SHOULD be possible for a fileserver to locate an NSDB 875 that stores the layout of a root fileset. 877 c. It SHOULD be possible to access, store and update 878 information related to a root fileset using the federation 879 protocols. 881 d. It SHOULD be possible to replicate root fileset information 882 across multiple repositories. 884 e. If a root fileset is defined it SHOULD be possible to 885 enable a file server to export that root fileset for client 886 access. 888 f. If a root fileset is defined it SHOULD be possible for 889 multiple file servers to project a common root with defined 890 consistency semantics. 892 g. If a root fileset is defined it SHOULD be stored using a 893 compact representation that is compatible with 894 heterogeneous fileserver implementations. The root 895 fileset's internal format SHOULD contain enough information 896 to generate any attributes, including referrals, required 897 by the standard filesystem access protocols in R9. 899 7. Non-Requirements 901 N1: It is not necessary for the namespace to be known by any 902 specific fileserver. 904 In the same manner that clients do not need to have a priori 905 knowledge of the structure of the namespace or its mapping onto 906 federation members, the projected namespace can exist without 907 individual fileservers knowing the entire organizational 908 structure, or, indeed, without knowing exactly where in the 909 projected namespace the filesets they host exist. 911 Fileservers do need to be able to handle referrals from other 912 fileservers, but they do not need to know what path the client 913 was accessing when the referral was generated. 915 N2: It is not necessary for updates and accesses to the federation 916 data to occur in transaction or transaction-like contexts. 918 One possible requirement that is omitted from our current list 919 is that updates and accesses to the data stored in the NSDB (or 920 individual NSDB nodes) occur within a transaction context. We 921 were not able to agree whether the benefits of transactions are 922 worth the complexity they add (both to the specification and its 923 eventual implementation) but this topic is open for discussion. 925 Below is the the draft of a proposed requirement that provides 926 transactional semantics: 928 "There MUST be a way to ensure that sequences of operations, 929 including observations of the namespace (including finding 930 the locations corresponding to a set of FSNs) and changes to 931 the namespace or related data stored in the system (including 932 the creation, renaming, or deletion of junctions, and the 933 creation, altering, or deletion of mappings between FSN and 934 filesystem locations), can be performed in a manner that 935 provides predictable semantics for the relationship between 936 the observed values and the effect of the changes." 938 "It MUST be possible to protect sequences of operations by 939 transactions with NSDB-wide or server-wide ACID semantics." 941 8. Security Considerations 943 Assuming the Internet threat model, the federated resolution 944 mechanism described in this document MUST be implemented in such a 945 way to prevent loss of CONFIDENTIALITY, DATA INTEGRITY and PEER 946 ENTITY AUTHENTICATION, as described in [RFC3552]. 948 CONFIDENTIALITY may be violated if an unauthorized party is able to 949 eavesdrop on the communication between authorized servers and NSDB 950 nodes and thereby learn the locations or other information about FSNs 951 that they would not be authorized to discover via direct queries. 952 DATA INTEGRITY may be compromised if a third party is able to 953 undetectably alter the contents of the communication between servers 954 and NSDB nodes. PEER ENTITY AUTHENTICATION is defeated if one server 955 can masquerade as another server without proper authority, or if an 956 arbitrary host can masquerade as a NSDB node. 958 Well-established techniques for providing authenticated channels may 959 be used to defeat these attacks, and the protocol MUST support at 960 least one of them. 962 For example, if LDAP is used to implement the query mechanism 963 [RFC4510], then TLS may be used to provide both authentication and 964 integrity [RFC5246] [RFC4513]. If the query protocol is implemented 965 on top of ONC/RPC, then RPCSEC_GSS may be used to fill the same role 966 [RFC2203] [RFC2743]. 968 9. IANA Considerations 970 This document has no actions for IANA. 972 10. References 974 10.1. Normative References 976 [NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4 977 Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (work 978 in progress), December 2008. 980 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 981 Requirement Levels", BCP 14, RFC 2119, March 1997. 983 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 984 Specification", RFC 2203, September 1997. 986 [RFC2743] Linn, J., "Generic Security Service Application Program 987 Interface Version 2, Update 1", RFC 2743, January 2000. 989 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 990 Beame, C., Eisler, M., and D. Noveck, "Network File System 991 (NFS) version 4 Protocol", RFC 3530, April 2003. 993 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 994 Text on Security Considerations", BCP 72, RFC 3552, 995 July 2003. 997 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 998 Unique IDentifier (UUID) URN Namespace", RFC 4122, 999 July 2005. 1001 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 1002 (LDAP): Technical Specification Road Map", RFC 4510, 1003 June 2006. 1005 [RFC4513] Harrison, R., "Lightweight Directory Access Protocol 1006 (LDAP): Authentication Methods and Security Mechanisms", 1007 RFC 4513, June 2006. 1009 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1010 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1012 10.2. Informational References 1014 [RFC1094] Nowicki, B., "NFS: Network File System Protocol 1015 specification", RFC 1094, March 1989. 1017 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 1018 Version 3 Protocol Specification", RFC 1813, June 1995. 1020 Appendix A. Acknowledgments 1022 We would like to thank Robert Thurlow of Sun Microsystems for helping 1023 to author this document. 1025 Authors' Addresses 1027 James Lentini 1028 NetApp 1029 1601 Trapelo Rd, Suite 16 1030 Waltham, MA 02451 1031 US 1033 Phone: +1 781-768-5359 1034 Email: jlentini@netapp.com 1036 Craig Everhart 1037 NetApp 1038 7301 Kit Creek Rd 1039 Research Triangle Park, NC 27709 1040 US 1042 Phone: +1 919-476-5320 1043 Email: everhart@netapp.com 1045 Daniel Ellard 1046 BBN Technologies 1047 10 Moulton Street 1048 Cambridge, MA 02138 1049 US 1051 Phone: +1 617-873-8000 1052 Email: dellard@bbn.com 1054 Renu Tewari 1055 IBM Almaden 1056 650 Harry Rd 1057 San Jose, CA 95120 1058 US 1060 Email: tewarir@us.ibm.com 1061 Manoj Naik 1062 IBM Almaden 1063 650 Harry Rd 1064 San Jose, CA 95120 1065 US 1067 Email: manoj@almaden.ibm.com