idnits 2.17.1 draft-ellard-nfsv4-federated-fs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1093. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1104. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1111. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1117. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 4, 2008) is 5741 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Ellard 3 Internet-Draft NetApp, Inc. 4 Intended status: Standards Track C. Everhart 5 Expires: February 5, 2009 Netapp, Inc. 6 R. Tewari 7 M. Naik 8 IBM Almaden 9 August 4, 2008 11 Requirements for Federated File Systems 12 draft-ellard-nfsv4-federated-fs-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on February 5, 2009. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This draft describes and lists the functional requirements of a 46 federated file system and defines related terms. Our intent is to 47 use this draft as a starting point and refine it, with input and 48 feedback from the file system community and other interested parties, 49 until we reach general agreement. We will then begin, again with the 50 help of any interested parties, to define standard, open federated 51 file system protocols that satisfy these requirements and are 52 suitable for implementation and deployment. 54 Table of Contents 56 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 57 2. Draft Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 8 61 5.1. Create a Fileset and its FSL(s) . . . . . . . . . . . . . 8 62 5.1.1. Creating a Fileset and a FSN . . . . . . . . . . . . . 8 63 5.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 9 64 5.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 9 65 5.3. Junction Creation . . . . . . . . . . . . . . . . . . . . 11 66 6. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 7. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 16 68 7.1. Basic Assumptions . . . . . . . . . . . . . . . . . . . . 16 69 7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 19 70 8. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 25 71 9. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 26 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 74 11.1. Normative References . . . . . . . . . . . . . . . . . . . 28 75 11.2. Informational References . . . . . . . . . . . . . . . . . 28 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 77 Intellectual Property and Copyright Statements . . . . . . . . . . 30 79 1. Requirements notation 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 Note, that this is a requirements document, and in many instances 86 where these words are used in this document they refer to qualities 87 of a specification for a system that satisfies the document, or 88 requirements of a system that matches that specification. These 89 cases are distinguished when there is potential for ambiguity. 91 2. Draft Goals 93 This draft describes and lists the functional requirements of a 94 federated file system and defines related terms. Our intent is to 95 use this draft as a starting point and refine it, with input and 96 feedback from the file system community and other interested parties, 97 until we reach general agreement. We will then begin, again with the 98 help of any interested parties, to define standard, open federated 99 file system protocols that satisfy these requirements and are 100 suitable for implementation and deployment. 102 We do not describe the mechanisms that might be used to implement 103 this functionality except in cases where specific mechanisms, in our 104 opinion, follow inevitably from the requirements. Our focus is on 105 the interfaces between the entities of the system, not on the 106 protocols or their implementations. 108 For the first version of this document, we are focused on the 109 following questions: 111 o Are any "MUST" requirements missing? 113 o Are there any "MUST" requirements that should be "SHOULD" or 114 "MAY"? 116 o Are there any "SHOULD" requirements that should be "MAY"? 118 o Are there better ways to articulate the requirements? 120 3. Overview 122 Today, there are collections of fileservers that inter-operate to 123 provide a single namespace comprised of filesystem resources provided 124 by different members of the collection, joined together with inter- 125 filesystem junctions. The namespace can either be assembled at the 126 fileservers, the clients, or by an external namespace service -- the 127 mechanisms used to assemble the namespace may vary depending on the 128 filesystem access protocol used by the client. 130 These fileserver collections are, in general, administered by a 131 single administrative entity. This administrator builds the 132 namespace out of the filesystem resources and junctions. There are 133 also singleton servers that export some or all of their filesystem 134 resources, but which do not contain junctions to other filesystems. 136 Current server collections that provide a shared namespace usually do 137 so by means of a service that maps filesystem names to filesystem 138 locations. We refer to this as a namespace database service (NSDB). 139 In some distributed file systems, this service is embodied as a 140 volume location database (VLDB), and may be implemented by LDAP, NIS, 141 or any number of other mechanisms. 143 We use the term "fileset" to represent the abstraction of a 144 filesystem. The fileset abstraction implies very little about how 145 the fileset is implemented, although in the simplest case a fileset 146 can be implemented by an exported filesystem. A fileset is a 147 directory tree that may contain files and references, called 148 "junction", to other filesets. Each fileset has a fileset globally 149 unique name (FSN) that is used as an identifier for the fileset. 150 Each implementation of a given fileset is specified by its fileset 151 location (FSL). 153 The primary purpose of the NSDB service is to provide a level of 154 indirection between the FSN the FSLs. If the NSDB service permits 155 updates to the set of mappings, then the FSLs may be changed (e.g., 156 moved or replicated) in a manner that is transparent to the referring 157 fileset and its server(s). 159 Current approaches are unsuitable to build common namespaces across 160 systems with multiple administrative domains and multiple NSDB nodes. 161 An approach which requires changing existing NSDB nodes to 162 collaborate or replacing them with a single NSDB node, while 163 possible, is not desirable. 165 Figure Figure 1 shows an example of a federation. This federation 166 has two members, named ALPHA and BETA. Federation members may 167 contain an arbitrary number of file servers and NSDB nodes; in this 168 illustration ALPHA and BETA each have three servers and one NSDB 169 node. 171 +----------------------+ +----------------------+ 172 | Federation Member | | Federation Member | 173 | ALPHA | | BETA | 174 | | | | 175 | | | | 176 | +------------+ | | +------------+ | 177 | | NSDB | | | | NSDB | | 178 | | | | | | | | 179 | +------------+ | | +------------+ | 180 | | | | 181 | | | | 182 | | | | 183 | +----------+ | | +----------+ | 184 | | | | | | | | 185 | +-- | Servers | | | +-- | Servers | | 186 | | | | | | | | | | 187 | +-- | | | | | +-- | | | | 188 | | | +----------+ | | | | +----------+ | 189 | | | | | | | | | | 190 | | +----------+ | | | +----------+ | 191 | | | | | | | | 192 | +----------+ | | +----------+ | 193 +----------------------+ +----------------------+ 195 A federation with two members, ALPHA and BETA. ALPHA and BETA each 196 have their own NSDB node and several file servers, but are 197 administered separately. 199 Figure 1 201 4. Purpose 203 Our objective is to specify a set of interfaces (and corresponding 204 protocols) by which such fileservers and collections of fileservers, 205 with different administrators, can form a federation of fileservers 206 and NSDB nodes that provides a namespace composed of the filesets 207 hosted on the different fileservers and fileserver collections. 209 It should be possible, using a system that implements the interfaces, 210 to share a common namespace across all the fileservers in the 211 federation. It should also be possible for different fileservers in 212 the federation to project different namespaces and enable clients to 213 traverse them. 215 Such a federation may contain an arbitrary number of NSDB nodes, each 216 belonging to a different administrative entity, and each providing 217 the mappings that define a part of a namespace. Such a federation 218 may also have an arbitrary number of administrative entities, each 219 responsible for administering a subset of the servers and NSDB nodes. 220 Acting in concert, the administrators should be able to build and 221 administer this multi-fileserver, multi-collection namespace. 223 Each singleton server can be presumed to provide its own NSDB node, 224 for example with a trivial mapping to local FSLs. 226 It is not the intent of the federation to guarantee namespace 227 consistency across all client views. Since different parts of the 228 namespace may be administered by different entities, it is possible 229 that a client could be accessing a stale area of the namespace 230 managed by one entity because a part of the namespace above it, 231 managed by another entity, has changed. 233 5. Examples and Discussion 235 In this section we provide examples and discussion of the basic 236 operations facilitated by the federated file system protocol: 237 creating a fileset, adding a replica of a fileset, resolving a 238 junction, and creating a junction. 240 5.1. Create a Fileset and its FSL(s) 242 A fileset is the abstraction of a set of files and their containing 243 directory tree. The fileset abstraction is the fundamental unit of 244 data management in the federation. This abstraction is implemented 245 by an actual directory tree whose root location is specified by a 246 fileset location (FSL). 248 In this section, we describe the basic requirements for starting with 249 a directory tree and creating a fileset that can be used in the 250 federation protocols. Note that we do not assume that the process of 251 creating a fileset requires any transformation of the files or the 252 directory hierarchy. The only thing that is required by this process 253 is assigning the fileset a fileset name (FSN) and expressing the 254 location(s) of the implementation of the fileset as FSL(s). 256 There are many possible variations to this procedure, depending on 257 how the FSN that binds the FSL is created, and whether other replicas 258 of the fileset exist, are known to the federation, and need to be 259 bound to the same FSN. 261 It is easiest to describe this in terms of how to create the initial 262 implementation of the fileset, and then describe how to add replicas. 264 5.1.1. Creating a Fileset and a FSN 266 1. Choose the NSDB node that will keep track of the FSL(s) and 267 related information for the fileset. 269 2. Request that the NSDB node register a new FSN for the fileset. 271 The FSN may either be chosen by the NSDB node or by the server. 272 The latter case is used if the fileset is being restored, perhaps 273 as part of disaster recovery, and the server wishes to specify 274 the FSN in order to permit existing junctions that reference that 275 FSN to work again. 277 At this point, the FSN exists, but its location is unspecified. 279 3. Send the FSN, the local volume path, the export path, and the 280 export options for the local implementation of the fileset to the 281 NSDB node. Annotations about the FSN or the location may also be 282 sent. 284 The NSDB node records this info and creates the initial FSL for 285 the fileset. 287 5.1.2. Adding a Replica of a Fileset 289 Adding a replica is straightforward: the NSDB node and the FSN are 290 already known. The only remaining step is to add another FSL. 292 Note that the federation interfaces do not include methods for 293 creating or managing replicas: this is assumed to be a platform- 294 dependent operation (at least at this time). The only interface 295 required is the ability to register or remove the registration of 296 replicas for a fileset. 298 5.2. Junction Resolution 300 A fileset may contain references to other filesets. These references 301 are represented by junctions. If a client requests access to a 302 fileset object that is a junction, the server resolves the junction 303 to discover the FSL(s) that implements the referenced fileset. 305 There are many possible variations to this procedure, depending on 306 how the junctions are represented and how the information necessary 307 to perform resolution is represented by the server. In this example, 308 we assume that the only thing directly expressed by the junction is 309 the junction key; its mapping to FSN can be kept local to the server 310 hosting the junction. 312 Step 5 is the only step that interacts directly with the federation 313 interfaces. The rest of the steps may use platform-specific 314 interfaces. 316 1. The server determines that the object being accessed is a 317 junction. 319 2. The server determines the junction key for the junction. 321 3. Using the junction key, the server does a local lookup to find 322 the FSN of the target fileset. 324 4. Using the FSN, the server finds the NSDB node responsible for the 325 target object. 327 5. The server contacts that NSDB node and asks for the set of FSLs 328 that implement the target FSN. The NSDB node responds with a set 329 of FSLs. 331 6. The server converts the FSL to the location type used by the 332 client (e.g., fs_location for NFSv4, as described in [RFC3530]). 334 7. The server redirects (in whatever manner is appropriate for the 335 client) the client to the location(s). 337 These steps are illustrated in Figure 2. The client sends request 1 338 to server X, in federation member ALPHA, in an attempt to reference 339 an object (which appears to the client as a directory). Server X 340 recognizes that the referenced object is actually a junction that 341 refers to a directory in a different fileset. Server X finds, from 342 the FSN in the junction, that the NSDB responsible for knowing the 343 location of the target of the junction is the NSDB of federation 344 member BETA. Server X sends request 2 to the NSDB of BETA, asking 345 for the current location of the directory. The NSDB sends response 3 346 to server X, telling the server that the directory is located on 347 server Y. Server X sends response 4 to the client, indicating that 348 the directory is in a "new" location on server Y. The client then 349 sends request 5 to server Y, repeating the initial request. 351 Given the current requirements and definitions, this resolution 352 method MUST work. However, there is no requirement that this is the 353 only resolution method that can be used. This method may be used as 354 the fallback when all else fails (or, for a simple implementation, it 355 could be the only method). This is a degenerate implementation of 356 the NSDB service as a simple composition of NSDB nodes; we expect 357 that large federations will use more sophisticated methods to share 358 the FSN and FSL information among multiple NSDB nodes. 360 +---------------+ 361 | | 362 | Client | >--------------------------+ 363 | | | 364 +---------------+ | 365 v ^ | 366 +-----+---+-------------+ +-----------------+-----+ 367 | | | Federation| |Federation | | 368 | | | member | |member | | 369 | | | ALPHA | |BETA | | 370 | | | | | | | 371 | | | | | | | 372 | | | | | | | 373 | | | | | | | 374 | | | | | +---------+ | | 375 | | | +---------+------+-> | | | | 376 | | | | | | | NSDB Y | | | 377 | | | | +-----+------+-< | | | | 378 | | | | | | | +---------+ | | 379 | | | | | | | | | 380 | | | | | | | | | 381 | | | | | | | | | 382 | 1| 4| 2| 3| | | 5| | 383 | v ^ ^ v | | v | 384 | +---------------+ | | +---------------+ | 385 | | | | | | | | 386 | | Server X | | | | Server Y | | 387 | | | | | | | | 388 | +---------------+ | | +---------------+ | 389 | | | | 390 +-----------------------+ +-----------------------+ 392 Figure 2 394 5.3. Junction Creation 396 Given a local path, a remote export and a path relative to that 397 export, create a junction from the local path to the path within the 398 remote export. 400 There are many possible variations to this procedure, depending on 401 how the junctions are represented and how the information necessary 402 to perform resolution is represented by the server. In this example, 403 we assume that the only thing directly expressed by the junction is 404 the junction key; its mapping to FSN can be kept local to the server 405 hosting the junction. 407 Step 1 is the only step that uses the federation interfaces. The 408 rest of the steps may use platform-specific interfaces. 410 1. Contact the server named by the export and ask for the FSN for 411 the fileset, given its path relative to that export. 413 2. Create a new local junction key. 415 3. Insert, in the local junction info table, a mapping from the 416 local junction key to the FSN. 418 4. Insert the junction, at the given path, into the local 419 filesystem. 421 6. Glossary 423 The phrase "USING THE FEDERATION INTERFACES" implies that the 424 subsequent requirement must be satisfied, in its entirety, via the 425 federation interfaces. 427 Administrator: user with the necessary authority to initiate 428 administrative tasks on one or more servers. 430 Admin entity: A server or agent that administers a collection of 431 fileservers and persistently stores the namespace information. 433 Client: Any client that accesses the fileserver data using a 434 supported filesystem access protocol. 436 Federation: A set of server collections and singleton servers that 437 use a common set of interfaces and protocols in order to provide 438 to their clients a federated namespace accessible through a 439 filesystem access protocol. 441 Fileserver: A server exporting a filesystem via a network filesystem 442 access protocol. 444 Fileset: The abstraction of a set of files and their containing 445 directory tree. A fileset is the fundamental unit of data 446 management in the federation. 448 Note that all files within a fileset are descendants of one 449 directory, and that filesets do not span filesystems. 451 Filesystem: A self-contained unit of export for a fileserver, and 452 the mechanism used to implement filesets. The fileset does not 453 need to be rooted at the root of the filesystem, nor at the export 454 point for the filesystem. 456 A single filesystem MAY implement more than one fileset, if the 457 client protocol and the fileserver permit this. 459 Filesystem access protocol: A network filesystem access protocol 460 such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [RFC3530], or 461 CIFS. 463 FSL (Fileset location): The location of the implementation of a 464 fileset at a particular moment in time. A FSL MUST be something 465 that can be translated into a protocol-specific description of a 466 resource that a client can access directly, such as a fs_location 467 (for NFSv4), or share name (for CIFS). Note that not all FSLs 468 need to be explicitly exported as long as they are contained 469 within an exported path on the fileserver. 471 FSN (Fileset name): A platform-independent and globally unique name 472 for a fileset. Two FSLs that implement replicas of the same 473 fileset MUST have the same FSN, and if a fileset is migrated from 474 one location to another, the FSN of that fileset MUST remain the 475 same. 477 Junction: A filesystem object used to link a directory name in the 478 current fileset with an object within another fileset. The 479 server-side "link" from a leaf node in one fileset to the root of 480 another fileset. 482 Junction key: The UUID of a fileset, used as a key to lookup an FSN 483 within an NSDB node or a local table of information about 484 junctions. 486 Namespace: A filename/directory tree that a sufficiently-authorized 487 client can observe. 489 NSDB (Namespace Database Service): A service that maps FSNs to FSLs. 490 The NSDB may also be used to store other information, such as 491 annotations for these mappings and their components. 493 NSDB Node: The name or location of a server that implements part of 494 the NSDB service and is responsible for keeping track of the FSLs 495 (and related info) that implement a given partition of the FSNs. 497 Referral: A server response to a client access that directs the 498 client to evaluate the current object as a reference to an object 499 at a different location (specified by an FSL) in another fileset, 500 and possibly hosted on another fileserver. The client re-attempts 501 the access to the object at the new location. 503 Replica: A replica is a redundant implementation of a fileset. Each 504 replica shares the same FSN, but has a different FSL. 506 Replicas may be used to increase availability or performance. 507 Updates to replicas of the same fileset MUST appear to occur in 508 the same order, and therefore each replica is self-consistent at 509 any moment. 511 We do not assume that updates to each replica occur simultaneously 512 If a replica is offline or unreachable, the other replicas may be 513 updated. 515 Server Collection: A set of fileservers administered as a unit. A 516 server collection may be administered with vendor-specific 517 software. 519 The namespace provided by a server collection could be part of the 520 federated namespace. 522 Singleton Server: A server collection containing only one server; a 523 stand-alone fileserver. 525 7. Proposed Requirements 527 Note that the requirements are described in terms of correct behavior 528 by all entities. We do not address the requirements of the system in 529 the presence of faults. 531 7.1. Basic Assumptions 533 Several of the requirements are so fundamental that we treat them as 534 basic assumptions; if any of these assumptions are violated, the rest 535 of the requirements must be reviewed in their entirety. 537 A1: The federation protocols do not require any changes to existing 538 client-facing protocols, and MAY be extended to incorporate new 539 client-facing protocols. 541 A2: A client SHOULD NOT require any a priori knowledge of the 542 general structure or composition of the federation. 544 The client may require some specific knowledge in order to find 545 and access an instance of the fileset that defines the root of 546 its view of the namespace. As the client traverses the 547 namespace, the client discovers the information it needs in 548 order to locate the filesets it accesses. 550 A3: All requirements MUST be satisfiable via the federation 551 protocols and the standard protocols used by the fileservers 552 (i.e., NFS, CIFS, DNS, etc). 554 USING THE FEDERATION INTERFACES, a federation operation that 555 requires an interaction between two (or more) entities that are 556 members of the federation MUST be possible without requiring any 557 proprietary protocols. 559 A4: All the entities participating in a federation operation MUST be 560 able to authenticate each other. 562 All principals (clients, users, administrator of a singleton or 563 server collection, hosts, NSDB nodes, etc) that can assume a 564 role defined by the federation protocol can identify themselves 565 to each other via an authentication mechanism. This mechanism 566 is not defined or further described in this document. 568 The authority of a principal to request that a second principal 569 perform a specific operation is ultimately determined by the 570 second. Authorization may be partitioned by server collection 571 or set of servers as well as by operation. For example, if a 572 user has administrative privileges on one server in the 573 federation, this does not imply that they have administrative 574 privileges (or, for that matter, any privileges whatsoever) on 575 any other server in the federation. 577 In order to access the functionality provided by the federation 578 interfaces, it may be necessary to have elevated privileges or 579 authorization. The authority required by different operations 580 may be different. For example, the authority required to query 581 the NSDB about the FSLs bound to an FSN may be different than 582 the authority required to change the bindings of that FSN. 584 An operation attempted by an unauthorized entity MUST fail in a 585 manner that indicates that the failure was due to insufficient 586 authorization. 588 This document does not enumerate the authorization necessary for 589 any operation. 591 A5: The federation protocols MUST NOT require changes to existing 592 authentication/authorization mechanisms in use at the 593 fileservers for client-facing protocols. 595 A user's view of the namespace may be limited by the 596 authentication and authorization privileges it has on the 597 different fileservers in the federation. As such, users may 598 only be able to traverse the parts of the namespace that they 599 have access to. 601 The federation protocols do not impose any restrictions on how 602 users are represented within the federation. For example, a 603 single enterprise could employ a common identity for users 604 across the federation. A grid environment could utilize user 605 mapping or translations across different administrative domains. 607 A6: In a federated system, we assume that a FSN MUST express, or can 608 be used to discover, the following two pieces of information: 610 1. The location of the NSDB node that is responsible for 611 knowing the filesystem location(s) (FSLs) of the named 612 fileset. 614 The NSDB node must be specified because there may be many 615 NSDB nodes in a federation. We do not assume that any 616 single entity knows the location of all of the NSDB nodes, 617 and therefore exhaustive search is not an option. 619 There are several ways in which a fileserver can locate the 620 NSDB node responsible for a given fileset. One approach, 621 given a DNS infrastructure, is to specify the location of 622 the NSDB node by the FQDN of the server hosting the NSDB 623 node. Another approach is to use a separate DNS-style 624 hierarchy to resolve the location of the NSDB node. 626 2. The junction key. 628 The junction key is the index used by the NSDB node to 629 identify the FSN of the target fileset. 631 There are several ways to represent junction keys. One 632 approach could use 128-bit UUIDs as described described in 633 [RFC4122]. 635 As an example, an FSN could be represented by a URL of the form 636 nsdb.example.com/UUID where nsdb.example.com is the FQDN of the 637 server hosting the NSDB node and UUID is the string 638 representation of the junction key. 640 Note that it is not assumed that it is always required for a 641 server to contact the NSDB node specified by the FSN in order to 642 find the FSLs. The relevant information stored in that NSDB 643 node may also be cached local to the server or on a proxy NSDB 644 node "near" the server. 646 A7: All federation servers and NSDB nodes are assumed to execute the 647 federation protocols correctly. The behavior of the federation 648 is undefined in the case of Byzantine behavior by any federation 649 server or NSDB node. 651 A8: The locations of federation services (such as NSDBs and FSLs) 652 can be specified in a manner such that they can be correctly 653 interpreted by all members of the federation that will access 654 them. 656 For example, if an NSDB node is specified by a FQDN, then this 657 implies that every member of the federation that needs to access 658 this NSDB node can resolve this FQDN to an IP address for that 659 NSDB node. (It is not necessary that the FQDN always resolve to 660 the same address; the same service may appear at different 661 addresses on different networks.) 663 It is the responsibility of each federation member to ensure 664 that the resources it wishes to expose have accessible network 665 locations and that the necessary resolution mechanisms (i.e., 666 DNS) are given the necessary data to perform the resolution 667 correctly. 669 7.2. Requirements 671 R1: Requirements of each FSN: 673 a. Each FSN MUST be globally unique. 675 b. The FSN MUST be sufficiently descriptive to locate an 676 instance of the fileset it names within the federation at 677 any time. 679 c. An FSN is a name of a fileset. (An FSL is not the name of 680 a fileset, but only a locator of an instance of a fileset 681 at some point in time. For example, the same FSL may 682 implement different filesets at different times.) 684 + If a fileset instance is moved to a new location, it 685 will have a new FSL, but its FSN is unchanged. 687 + An instance of a different fileset may be placed at a 688 FSL previously occupied by an instance of a different 689 fileset. 691 d. If a fileset instance is migrated to another location, the 692 FSN remains the same in the new location. 694 e. If the fileset is replicated using the federation 695 interfaces, then all of the replicas have the same FSN. 697 Not all filesets in the federation are required to have a FSN 698 or be reachable by a FSL. Only those filesets that are the 699 target of a junction (as described in R3) are required to have 700 an FSN. 702 NOTE: this requirement has been called into question. 704 R2: USING THE FEDERATION INTERFACES, it MUST be possible to create 705 an FSN for a fileset, and it must be possible to bind an FSL to 706 that FSN. These operations are NSDB operations and do not 707 require any action on the part of an NFS server. 709 It is possible to create an FSN for a fileset that has not 710 actually been created. It is also possible to bind a 711 nonexistant FSL to an FSN. It is also possible to create a 712 fileset without assigning it an FSN. The binding between an 713 FSN and an FSL is defined entirely within the context of the 714 NSDB; the servers do not "know" whether the filesets they host 715 have been assigned FSNs (or, if so, what those FSNs are). 717 The requirement that filesets can exist prior to being assigned 718 an FSN, and the requirement that FSNs can exist independent of 719 filesets are intended to simplify the construction of the 720 namespace in a convenient manner. For example, they permit an 721 admin to assign FSNs to existing filesets and thereby 722 incorporate existing filesets into the namespace. They also 723 permit the structure of the namespace to be defined prior to 724 creation of the component filesets. In either case, it is the 725 responsibility of the entity updating the NSDB with FSNs and 726 FSN-to-FSL mappings to ensure that the namespace is constructed 727 in a consistent manner. (The simplest way to accomplish this 728 is to ensure that the FSN and FSN-to-FSL mappings are always 729 recorded in the NSDB prior to the creation of any junctions 730 that refer to that FSN.) 732 a. An administrator MAY specify the entire FSN (including both 733 the NSDB node location and the junction key) of the newly- 734 created FSL, or the administrator MAY specify only the NSDB 735 node and have the system choose the junction key. 737 The admin can choose to specify the FSN explicitly in order 738 to recreate a lost fileset with a given FSN (for example, 739 as part of disaster recovery). It is an error to assign an 740 FSN that is already in use by an active fileset. 742 Note that creating a replica of an existing filesystem is 743 NOT accomplished by assigning the FSN of the filesystem you 744 wish to replicate to a new filesystem. 746 b. USING THE FEDERATION INTERFACES, it MUST be possible to 747 create a federation FSL by specifying a specific local 748 volume, path, export path, and export options. 750 R3: USING THE FEDERATION INTERFACES, and given the FSN of a target 751 fileset, it MUST be possible to create a junction to that 752 fileset at a named place in another fileset. 754 After a junction has been created, clients that access the 755 junction transparently interpret it as a reference to the 756 FSL(s) that implement the FSN associated with the junction. 758 a. It SHOULD be possible to have more than one junction whose 759 target is a given fileset. In other words, it SHOULD be 760 possible to mount a fileset at multiple named places. 762 b. If the fileset in which the junction is created is 763 replicated, then the junction MUST eventually appear in all 764 of its replicas. 766 The operation of creating a junction within a fileset is 767 treated as an update to the fileset, and therefore obey the 768 general rules about updates to replicated filesets. 770 R4: USING THE FEDERATION INTERFACES, it MUST be possible to delete 771 a specific junction from a fileset. 773 If a junction is deleted, clients who are already viewing the 774 fileset referred to by the junction after traversing the 775 junction MAY continue to view the old namespace. They might 776 not discover that the junction no longer exists (or has been 777 deleted and replaced with a new junction, possibly referring to 778 a different FSN). 780 After a junction is deleted, another object with the same name 781 (another junction, or an ordinary filesystem object) may be 782 created. 784 The operation of deleting a junction within a fileset is 785 treated as an update to the fileset, and therefore obey the 786 general rules about updates to replicated filesets. 788 R5: USING THE FEDERATION INTERFACES, it MUST be possible to 789 invalidate an FSN. 791 a. If a junction refers to an FSN that is invalid, attempting 792 to traverse the junction MUST fail. 794 An FSN that has been invalidated MAY become valid again if the 795 FSN is recreated (i.e., as part of a disaster recovery 796 process). 798 If an FSN is invalidated, clients who are already viewing the 799 fileset named by the FSN MAY continue to view the old 800 namespace. They might not discover that the FSN is no longer 801 valid until they try to traverse a junction that refers to it. 803 R6: USING THE FEDERATION INTERFACES, it MUST be possible to 804 invalidate a FSL. 806 a. An invalid FSL MUST NOT be returned as the result of 807 resolving a junction. 809 An FSL that has been invalidated MAY become valid again if the 810 FSL is recreated (i.e., as part of a disaster recovery 811 process). 813 If an FSL is invalidated, clients who are already viewing the 814 fileset implemented by the FSL MAY continue to use that FSL. 815 They might not discover that the FSL is no longer valid until 816 they try to traverse a junction that refers to the fileset 817 implemented by the FSL. 819 Note that invalidating an FSL does not imply that the 820 underlying export or share (depending on the file access 821 protocol in use) is changed in any way -- it only changes the 822 mappings from FSNs to FSLs on the NSDB. 824 R7: It MUST be possible for the federation of servers to provide 825 multiple namespaces. 827 R8: USING THE FEDERATION INTERFACES, it MUST be possible to perform 828 queries about the state of objects relevant to the 829 implementation of the federation namespace. 831 It MUST be possible to query the fileserver named in an FSL to 832 discover whether a junction exists at a given path within that 833 FSL. 835 R9: The projected namespace (and the objects named by the 836 namespace) MUST be accessible to clients via at least one 837 standard filesystem access protocol. 839 a. The namespace SHOULD be accessible to clients via the CIFS 840 protocol. 842 b. The namespace SHOULD be accessible to clients via the NFSv4 843 protocol as described in [RFC3530]. 845 c. The namespace SHOULD be accessible to clients via the NFSv3 846 protocol as described in [RFC1813]. 848 d. The namespace SHOULD be accessible to clients via the NFSv2 849 protocol as described in [RFC1094]. 851 It must be understood that some of these protocols, such as 852 NFSv3 and NFSv2, have no innate ability to access a namespace 853 of this kind. Where such protocols have been augmented with 854 other protocols and mechanisms (such as autofs or amd for 855 NFSv3) to provide an extended namespace, we propose that these 856 protocols and mechanisms may be used, or extended, in order to 857 satisfy the requirements given in this draft, and different 858 clients may use different mechanisms. 860 R10: USING THE FEDERATION INTERFACES, it MUST be possible to modify 861 the NSDB mapping from an FSN to a set of FSLs to reflect the 862 migration from one FSL to another. 864 R11: FSL migration SHOULD have little or no impact on the clients, 865 but this is not guaranteed across all federation members. 867 Whether FSL migration is performed transparently depends on 868 whether the source and destination servers are able to do so. 869 It is the responsibility of the administrator to recognize 870 whether or not the migration will be transparent, and advise 871 the system accordingly. The federation, in turn, MUST advise 872 the servers to notify their clients, if necessary. 874 For example, on some systems, it may be possible to migrate a 875 fileset from one system to another with minimal client impact 876 because all client-visible metadata (inode numbers, etc) are 877 preserved during migration. On other systems, migration might 878 be quite disruptive. 880 R12: USING THE FEDERATION INTERFACES, it MUST be possible to modify 881 the NSDB mapping from an FSN to a set of FSLs to reflect the 882 addition/removal of a replica at a given FSL. 884 R13: Replication SHOULD have little or no negative impact on the 885 clients. 887 Whether FSL replication is performed transparently depends on 888 whether the source and destination servers are able to do so. 889 It is the responsibility of the administrator initiating the 890 replication to recognize whether or not the replication will be 891 transparent, and advise the federation accordingly. The 892 federation MUST advise the servers to notify their clients, if 893 necessary. 895 For example, on some systems, it may be possible to mount any 896 FSL of an FSN read/write, while on other systems, there may be 897 any number of read-only replicas but only one FSL that can be 898 mounted read-write. 900 R14: USING THE FEDERATION INTERFACES, it SHOULD be possible to 901 annotate the objects and relations managed by the federation 902 protocol with arbitrary name/value pairs. 904 These annotations are not used by the federation protocols -- 905 they are intended for use by higher-level protocols. For 906 example, an annotation that might be useful for a system 907 administrator browsing the federation would be the "owner" of 908 each FSN (i.e., "this FSN is for the home directory of Joe 909 Smith."). As another example, the annotations may express 910 hints used by the clients (such as priority information for 911 NFSv4.1). 913 Both FSNs and FSLs may be annotated. For example, an FSN 914 property might be "This is Joe Smith's home directory", and an 915 FSL property might be "This instance of the FSN is at the 916 remote backup site." 918 a. USING THE FEDERATION INTERFACES, it MUST be possible to 919 query the system to find the annotations for a junction. 921 b. USING THE FEDERATION INTERFACES, it MUST be possible to 922 query the system to find the annotations for a FSN. 924 c. USING THE FEDERATION INTERFACES, it MUST be possible to 925 query the system to find the annotations for a FSL. 927 8. Non-Requirements 929 N1: It is not necessary for the namespace to be known by any 930 specific fileserver. 932 In the same manner that clients do not need to have a priori 933 knowledge of the structure of the namespace or its mapping onto 934 federation members, the projected namespace can exist without 935 individual fileservers knowing the entire organizational 936 structure, or, indeed, without knowing exactly where in the 937 projected namespace the filesets they host exist. 939 Fileservers do need to be able to handle referrals from other 940 fileservers, but they do not need to know what path the client 941 was accessing when the referral was generated. 943 N2: It is not necessary for updates and accesses to the federation 944 data to occur in transaction or transaction-like contexts. 946 One possible requirement that is omitted from our current list 947 is that updates and accesses to the data stored in the NSDB (or 948 individual NSDB nodes) occur within a transaction context. We 949 were not able to agree whether the benefits of transactions are 950 worth the complexity they add (both to the specification and its 951 eventual implementation) but this topic is open for discussion. 953 Below is the the draft of a proposed requirement that provides 954 transactional semantics: 956 "There MUST be a way to ensure that sequences of operations, 957 including observations of the namespace (including finding 958 the locations corresponding to a set of FSNs) and changes to 959 the namespace or related data stored in the system (including 960 the creation, renaming, or deletion of junctions, and the 961 creation, altering, or deletion of mappings between FSN and 962 filesystem locations), can be performed in a manner that 963 provides predictable semantics for the relationship between 964 the observed values and the effect of the changes." 966 "It MUST be possible to protect sequences of operations by 967 transactions with NSDB-wide or server-wide ACID semantics." 969 9. IANA Requirements 971 This document has no actions for IANA. 973 10. Security Considerations 975 Assuming the Internet threat model, the federated resolution 976 mechanism described in this document MUST be implemented in such a 977 way to prevent loss of CONFIDENTIALITY, DATA INTEGRITY and PEER 978 ENTITY AUTHENTICATION, as described in [RFC3552]. 980 CONFIDENTIALITY may be violated if an unauthorized party is able to 981 eavesdrop on the communication between authorized servers and NSDB 982 nodes and thereby learn the locations or other information about FSNs 983 that they would not be authorized to discover via direct queries. 984 DATA INTEGRITY may be compromised if a third party is able to 985 undetectably alter the contents of the communication between servers 986 and NSDB nodes. PEER ENTITY AUTHENTICATION is defeated if one server 987 can masquerade as another server without proper authority, or if an 988 arbitrary host can masquerade as a NSDB node. 990 Well-established techniques for providing authenticated channels may 991 be used to defeat these attacks, and the protocol MUST support at 992 least one of them. 994 For example, if LDAP is used to implement the query mechanism 995 [RFC4511], then TLS may be used to provide both authentication and 996 integrity [RFC4346] [RFC4513]. If the query protocol is implemented 997 on top of ONC/RPC, then RPCSEC_GSS may be used to fill the same role 998 [RFC2203] [RFC2743]. 1000 11. References 1002 11.1. Normative References 1004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1005 Requirement Levels", BCP 14, RFC 2119, March 1997. 1007 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 1008 Specification", RFC 2203, September 1997. 1010 [RFC2743] Linn, J., "Generic Security Service Application Program 1011 Interface Version 2, Update 1", RFC 2743, January 2000. 1013 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 1014 Beame, C., Eisler, M., and D. Noveck, "Network File System 1015 (NFS) version 4 Protocol", RFC 3530, April 2003. 1017 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1018 Text on Security Considerations", BCP 72, RFC 3552, 1019 July 2003. 1021 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1022 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1023 July 2005. 1025 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1026 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1028 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 1029 (LDAP): The Protocol", RFC 4511, June 2006. 1031 [RFC4513] Harrison, R., "Lightweight Directory Access Protocol 1032 (LDAP): Authentication Methods and Security Mechanisms", 1033 RFC 4513, June 2006. 1035 11.2. Informational References 1037 [RFC1094] Nowicki, B., "NFS: Network File System Protocol 1038 specification", RFC 1094, March 1989. 1040 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 1041 Version 3 Protocol Specification", RFC 1813, June 1995. 1043 Authors' Addresses 1045 Daniel Ellard 1046 NetApp, Inc. 1047 1601 Trapelo Rd, Suite 16 1048 Waltham, MA 02451 1049 US 1051 Phone: +1 781-768-5421 1052 Email: ellard@netapp.com 1054 Craig Everhart 1055 Netapp, Inc. 1056 7301 Kit Creek Rd 1057 Research Triangle Park, NC 27709 1058 US 1060 Phone: +1 919-476-5320 1061 Email: everhart@netapp.com 1063 Renu Tewari 1064 IBM Almaden 1065 650 Harry Rd 1066 San Jose, CA 95120 1067 US 1069 Email: tewarir@us.ibm.com 1071 Manoj Naik 1072 IBM Almaden 1073 650 Harry Rd 1074 San Jose, CA 95120 1075 US 1077 Email: manoj@almaden.ibm.com 1079 Full Copyright Statement 1081 Copyright (C) The IETF Trust (2008). 1083 This document is subject to the rights, licenses and restrictions 1084 contained in BCP 78, and except as set forth therein, the authors 1085 retain all their rights. 1087 This document and the information contained herein are provided on an 1088 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1089 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1090 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1091 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1092 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1093 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1095 Intellectual Property 1097 The IETF takes no position regarding the validity or scope of any 1098 Intellectual Property Rights or other rights that might be claimed to 1099 pertain to the implementation or use of the technology described in 1100 this document or the extent to which any license under such rights 1101 might or might not be available; nor does it represent that it has 1102 made any independent effort to identify any such rights. Information 1103 on the procedures with respect to rights in RFC documents can be 1104 found in BCP 78 and BCP 79. 1106 Copies of IPR disclosures made to the IETF Secretariat and any 1107 assurances of licenses to be made available, or the result of an 1108 attempt made to obtain a general license or permission for the use of 1109 such proprietary rights by implementers or users of this 1110 specification can be obtained from the IETF on-line IPR repository at 1111 http://www.ietf.org/ipr. 1113 The IETF invites any interested party to bring to its attention any 1114 copyrights, patents or patent applications, or other proprietary 1115 rights that may cover technology that may be required to implement 1116 this standard. Please address the information to the IETF at 1117 ietf-ipr@ietf.org. 1119 Acknowledgment 1121 Funding for the RFC Editor function is provided by the IETF 1122 Administrative Support Activity (IASA).