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