idnits 2.17.1 draft-ietf-nfsv4-federated-fs-reqts-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2009) is 5292 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-06) exists of draft-ietf-pkix-ta-mgmt-reqs-04 == Outdated reference: A later version (-08) exists of draft-ietf-pkix-tamp-03 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 Working Group J. Lentini 3 Internet-Draft C. Everhart 4 Intended status: Informational NetApp 5 Expires: April 25, 2010 D. Ellard 6 BBN Technologies 7 R. Tewari 8 M. Naik 9 IBM Almaden 10 October 22, 2009 12 Requirements for Federated File Systems 13 draft-ietf-nfsv4-federated-fs-reqts-06 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may contain material 19 from IETF Documents or IETF Contributions published or made publicly 20 available before November 10, 2008. The person(s) controlling the 21 copyright in some of this material may not have granted the IETF 22 Trust the right to allow modifications of such material outside the 23 IETF Standards Process. Without obtaining an adequate license from 24 the person(s) controlling the copyright in such materials, this 25 document may not be modified outside the IETF Standards Process, and 26 derivative works of it may not be created outside the IETF Standards 27 Process, except to format it for publication as an RFC or to 28 translate it into languages other than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on April 25, 2010. 48 Copyright Notice 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents in effect on the date of 54 publication of this document (http://trustee.ietf.org/license-info). 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. 58 Abstract 60 This document describes and lists the functional requirements of a 61 federated file system and defines related terms. 63 Requirements Language 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [RFC2119]. 69 Note, that this is a requirements document, and in many instances 70 where these words are used in this document they refer to qualities 71 of a specification for a system that satisfies the document, or 72 requirements of a system that matches that specification. These 73 cases are distinguished when there is potential for ambiguity. 75 Table of Contents 77 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 3. Examples and Discussion . . . . . . . . . . . . . . . . . . . 8 80 3.1. Create a Fileset and its FSL(s) . . . . . . . . . . . . . 8 81 3.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 8 82 3.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 9 83 3.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 9 84 3.3. Junction Creation . . . . . . . . . . . . . . . . . . . . 11 85 4. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 5. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 16 87 5.1. Basic Assumptions . . . . . . . . . . . . . . . . . . . . 16 88 5.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 19 89 6. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 26 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 93 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 94 9.2. Informational References . . . . . . . . . . . . . . . . . 29 95 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 31 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 98 1. Overview 100 This document describes and lists the functional requirements of a 101 federated file system and defines related terms. 103 We do not describe the mechanisms that might be used to implement 104 this functionality except in cases where specific mechanisms, in our 105 opinion, follow inevitably from the requirements. Our focus is on 106 the interfaces between the entities of the system, not on the 107 protocols or their implementations. 109 Today, there are collections of fileservers that inter-operate to 110 provide a single namespace comprised of filesystem resources provided 111 by different members of the collection, joined together with inter- 112 filesystem references. The namespace can either be assembled at the 113 fileservers, the clients, or by an external namespace service, and is 114 often not easy or uniform to manage. The requirements in this draft 115 are meant to lead to a uniform server-based namespace that is capable 116 of spanning a whole enterprise and which is easy to manage. 118 We define some terms to better describe the solution space. A 119 "fileset" is the abstract view of a filesystem in a uniform 120 namespace, and may be implemented behind that abstraction by one or 121 more physical filesystems at any given time. Each fileset has a name 122 called an "FSN" (fileset name), and each physical filesystem has a 123 fileset location ("FSL"). A fileset is a directory tree containing 124 files and directories, and it may also contain references to other 125 filesets. These references are called "junctions". To provide 126 location independence, a junction does not contain information about 127 the location of the real resource(s), but instead contains an FSN 128 that can be used to look up the location information. The service 129 that can be used to map from FSN to FSL(s) is called a namespace 130 database (NSDB) service. The NSDB provides a level of indirection 131 from the virtual paths in the uniform namespace to the actual 132 locations of files. By design, the NSDB does not store the 133 junctions. This allows junction administration and NSDB 134 administration to be separate roles. 136 The servers direct clients to the proper locations by existing 137 mechanisms (e.g. the referrals mechanism within [RFC3530] and 138 [NFSv4.1]). Updates to the locations make it possible to support 139 migration and replication of physical filesystems that comprise the 140 namespace, in a way that is transparent to filesystem applications. 142 Figure 1 shows an example of a federation. This federation has two 143 members, named ALPHA and BETA. Federation members may contain an 144 arbitrary number of file servers and NSDB nodes; in this illustration 145 ALPHA and BETA each have three servers and one NSDB node. 147 +----------------------+ +----------------------+ 148 | Federation Member | | Federation Member | 149 | ALPHA | | BETA | 150 | | | | 151 | | | | 152 | +------------+ | | +------------+ | 153 | | NSDB | | | | NSDB | | 154 | | | | | | | | 155 | +------------+ | | +------------+ | 156 | | | | 157 | | | | 158 | | | | 159 | +----------+ | | +----------+ | 160 | | | | | | | | 161 | +-- | Servers | | | +-- | Servers | | 162 | | | | | | | | | | 163 | +-- | | | | | +-- | | | | 164 | | | +----------+ | | | | +----------+ | 165 | | | | | | | | | | 166 | | +----------+ | | | +----------+ | 167 | | | | | | | | 168 | +----------+ | | +----------+ | 169 +----------------------+ +----------------------+ 171 A federation with two members, ALPHA and BETA. ALPHA and BETA each 172 have their own NSDB node and several file servers, and they are 173 administered separately. 175 Figure 1 177 2. Purpose 179 Our objective is to specify a set of protocols by which fileservers 180 or collections of fileservers, with different administrators, can 181 form a federation of fileservers and NSDB nodes that provides a 182 namespace composed of the filesets hosted on the different 183 fileservers and fileserver collections. 185 It should be possible, using a system that implements the protocols, 186 to share a common namespace across all the fileservers in the 187 federation. It should also be possible for different fileservers in 188 the federation to project different namespaces and enable clients to 189 traverse them. 191 Such a federation may contain an arbitrary number of NSDB nodes, each 192 belonging to a different administrative entity, and each providing 193 the mappings that define a part of a namespace. Such a federation 194 may also have an arbitrary number of administrative entities, each 195 responsible for administering a subset of the fileservers and NSDB 196 nodes. Acting in concert, the administrators should be able to build 197 and administer this multi-fileserver, multi-collection namespace. 199 It is not the intent of the federation to guarantee namespace 200 consistency across all client views. Since different parts of the 201 namespace may be administered by different entities, it is possible 202 that a client could be accessing a stale area of the namespace 203 managed by one entity because a part of the namespace above it, 204 managed by another entity, has changed. 206 3. Examples and Discussion 208 In this section we provide examples and discussion of the basic 209 operations facilitated by the federated file system protocol: 210 creating a fileset, adding a replica of a fileset, resolving a 211 junction, and creating a junction. 213 3.1. Create a Fileset and its FSL(s) 215 A fileset is the abstraction of a set of files and their containing 216 directory tree. The fileset abstraction is the fundamental unit of 217 data management in the federation. This abstraction is implemented 218 by an actual directory tree whose root location is specified by a 219 fileset location (FSL). 221 In this section, we describe the basic requirements for starting with 222 a directory tree and creating a fileset that can be used in the 223 federation protocols. Note that we do not assume that the process of 224 creating a fileset requires any transformation of the files or the 225 directory hierarchy. The only thing that is required by this process 226 is assigning the fileset a fileset name (FSN) and expressing the 227 location(s) of the implementation of the fileset as FSL(s). 229 There are many possible variations to this procedure, depending on 230 how the FSN that binds the FSL is created, and whether other replicas 231 of the fileset exist, are known to the federation, and need to be 232 bound to the same FSN. 234 It is easiest to describe this in terms of how to create the initial 235 implementation of the fileset, and then describe how to add replicas. 237 3.1.1. Creating a Fileset and an FSN 239 1. Choose the NSDB node that will keep track of the FSL(s) and 240 related information for the fileset. 242 2. Request that the NSDB node register a new FSN for the fileset. 244 The FSN may either be chosen by the NSDB node or by the server. 245 The latter case is used if the fileset is being restored, perhaps 246 as part of disaster recovery, and the server wishes to specify 247 the FSN in order to permit existing junctions that reference that 248 FSN to work again. 250 At this point, the FSN exists, but its location is unspecified. 252 3. Send the FSN, the local volume path, the export path, and the 253 export options for the local implementation of the fileset to the 254 NSDB node. Annotations about the FSN or the location may also be 255 sent. 257 The NSDB node records this info and creates the initial FSL for 258 the fileset. 260 3.1.2. Adding a Replica of a Fileset 262 Adding a replica is straightforward: the NSDB node and the FSN are 263 already known. The only remaining step is to add another FSL. 265 Note that the federation protocols do not include methods for 266 creating or managing replicas: this is assumed to be a platform- 267 dependent operation (at least at this time). The only requirement is 268 that these fileset replicas be registered and unregistered with the 269 NSDB. 271 3.2. Junction Resolution 273 A fileset may contain references to other filesets. These references 274 are represented by junctions. If a client requests access to a 275 fileset object that is a junction, the server resolves the junction 276 to discover the FSL(s) that implements the referenced fileset. 278 There are many possible variations to this procedure, depending on 279 how the junctions are represented and how the information necessary 280 to perform resolution is represented by the server. 282 Step 4 is the only step that interacts directly with the federation 283 protocols. The rest of the steps may use platform-specific 284 interfaces. 286 1. The server determines that the object being accessed is a 287 junction. 289 2. Using the junction, the server does a local lookup to find the 290 FSN of the target fileset. 292 3. Using the FSN, the server finds the NSDB node responsible for the 293 target object. 295 4. The server contacts that NSDB node and asks for the set of FSLs 296 that implement the target FSN. The NSDB node responds with a set 297 of FSLs. 299 5. The server converts one of the FSLs to the location type used by 300 the client (e.g., fs_location for NFSv4, as described in 301 [RFC3530]). 303 6. The server redirects (in whatever manner is appropriate for the 304 client) the client to the location(s). 306 These steps are illustrated in Figure 2. The client sends request 1 307 to server X, in federation member ALPHA, in an attempt to reference 308 an object (which appears to the client as a directory). Server X 309 recognizes that the referenced object is actually a junction that 310 refers to a directory in a different fileset. Server X finds, from 311 the FSN in the junction, that the NSDB responsible for knowing the 312 location of the target of the junction is the NSDB of federation 313 member BETA. Server X sends request 2 to the NSDB of BETA, asking 314 for the current location of the directory. The NSDB sends response 3 315 to server X, telling the server that the directory is located on 316 server Y. Server X sends response 4 to the client, indicating that 317 the directory is in a "new" location on server Y. The client then 318 sends request 5 to server Y, repeating the initial request. 320 Given the current requirements and definitions, this resolution 321 method MUST work. However, there is no requirement that this is the 322 only resolution method that can be used. This method may be used as 323 the fallback when all else fails (or, for a simple implementation, it 324 could be the only method). This is a degenerate implementation of 325 the NSDB service as a simple composition of NSDB nodes; we expect 326 that large federations will use more sophisticated methods to share 327 the FSN and FSL information among multiple NSDB nodes. 329 +---------------+ 330 | | 331 | Client | >--------------------------+ 332 | | | 333 +---------------+ | 334 v ^ | 335 +-----+---+-------------+ +-----------------+-----+ 336 | | | Federation| |Federation | | 337 | | | member | |member | | 338 | | | ALPHA | |BETA | | 339 | | | | | | | 340 | | | | | | | 341 | | | | | | | 342 | | | | | | | 343 | | | | | +---------+ | | 344 | | | +---------+------+-> | | | | 345 | | | | | | | NSDB Y | | | 346 | | | | +-----+------+-< | | | | 347 | | | | | | | +---------+ | | 348 | | | | | | | | | 349 | | | | | | | | | 350 | | | | | | | | | 351 | 1| 4| 2| 3| | | 5| | 352 | v ^ ^ v | | v | 353 | +---------------+ | | +---------------+ | 354 | | | | | | | | 355 | | Server X | | | | Server Y | | 356 | | | | | | | | 357 | +---------------+ | | +---------------+ | 358 | | | | 359 +-----------------------+ +-----------------------+ 361 Figure 2 363 3.3. Junction Creation 365 Given a local path and the FSN of a remote fileset, an administrator 366 can create a junction from the local path to the remote fileset. 368 There are many possible variations to this procedure, depending on 369 how the junctions are represented and how the information necessary 370 to perform resolution is represented by the server. 372 Step 1 is the only step that uses the federation interfaces. The 373 remaining step may use platform-specific interfaces. 375 1. The administrator requests the server create a junction to the 376 FSN of the remote fileset at the given path. 378 2. The server inserts the junction to the FSN, at the given path, 379 into the local filesystem. 381 4. Glossary 383 Administrator: user with the necessary authority to initiate 384 administrative tasks on one or more servers. 386 Admin entity: A server or agent that administers a collection of 387 fileservers and persistently stores the namespace information. 389 Client: Any client that accesses the fileserver data using a 390 supported filesystem access protocol. 392 Federation: A set of server collections and singleton servers that 393 use a common set of interfaces and protocols in order to provide 394 to their clients a federated namespace accessible through a 395 filesystem access protocol. 397 Fileserver: A server exporting a filesystem via a network filesystem 398 access protocol. 400 Fileset: The abstraction of a set of files and their containing 401 directory tree. A fileset is the fundamental unit of data 402 management in the federation. 404 Note that all files within a fileset are descendants of one 405 directory, and that filesets do not span filesystems. 407 Filesystem: A self-contained unit of export for a fileserver, and 408 the mechanism used to implement filesets. The fileset does not 409 need to be rooted at the root of the filesystem, nor at the export 410 point for the filesystem. 412 A single filesystem MAY implement more than one fileset, if the 413 client protocol and the fileserver permit this. 415 Filesystem access protocol: A network filesystem access protocol 416 such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [RFC3530], or 417 CIFS. 419 FSL (Fileset location): The location of the implementation of a 420 fileset at a particular moment in time. A FSL MUST be something 421 that can be translated into a protocol-specific description of a 422 resource that a client can access directly, such as a fs_location 423 (for NFSv4), or share name (for CIFS). Note that not all FSLs 424 need to be explicitly exported as long as they are contained 425 within an exported path on the fileserver. 427 FSN (Fileset name): A platform-independent and globally unique name 428 for a fileset. Two FSLs that implement replicas of the same 429 fileset MUST have the same FSN, and if a fileset is migrated from 430 one location to another, the FSN of that fileset MUST remain the 431 same. 433 Junction: A filesystem object used to link a directory name in the 434 current fileset with an object within another fileset. The 435 server-side "link" from a leaf node in one fileset to the root of 436 another fileset. 438 Namespace: A filename/directory tree that a sufficiently-authorized 439 client can observe. 441 NSDB (Namespace Database) Service: A service that maps FSNs to FSLs. 442 The NSDB may also be used to store other information, such as 443 annotations for these mappings and their components. 445 NSDB Node: The name or location of a server that implements part of 446 the NSDB service and is responsible for keeping track of the FSLs 447 (and related info) that implement a given partition of the FSNs. 449 Referral: A server response to a client access that directs the 450 client to evaluate the current object as a reference to an object 451 at a different location (specified by an FSL) in another fileset, 452 and possibly hosted on another fileserver. The client re-attempts 453 the access to the object at the new location. 455 Replica: A replica is a redundant implementation of a fileset. Each 456 replica shares the same FSN, but has a different FSL. 458 Replicas may be used to increase availability or performance. 459 Updates to replicas of the same fileset MUST appear to occur in 460 the same order, and therefore each replica is self-consistent at 461 any moment. 463 We do not assume that updates to each replica occur 464 simultaneously. If a replica is offline or unreachable, the other 465 replicas may be updated. 467 Server Collection: A set of fileservers administered as a unit. A 468 server collection may be administered with vendor-specific 469 software. 471 The namespace provided by a server collection could be part of the 472 federated namespace. 474 Singleton Server: A server collection containing only one server; a 475 stand-alone fileserver. 477 5. Proposed Requirements 479 The phrase "USING THE FEDERATION INTERFACES" implies that the 480 subsequent requirement must be satisfied, in its entirety, via the 481 federation interfaces. 483 Note that the requirements are described in terms of correct behavior 484 by all entities. We do not address the requirements of the system in 485 the presence of faults. 487 5.1. Basic Assumptions 489 Several of the requirements are so fundamental that we treat them as 490 basic assumptions; if any of these assumptions are violated, the rest 491 of the requirements must be reviewed in their entirety. 493 A1: The federation protocols do not require any changes to existing 494 client-facing protocols, and MAY be extended to incorporate new 495 client-facing protocols. 497 A2: A client SHOULD NOT require any a priori knowledge of the 498 general structure or composition of the federation. 500 The client may require some specific knowledge in order to find 501 and access an instance of the fileset that defines the root of 502 its view of the namespace. As the client traverses the 503 namespace, the client discovers the information it needs in 504 order to locate the filesets it accesses. 506 A3: All requirements MUST be satisfiable via the federation 507 protocols and the standard protocols used by the fileservers 508 (i.e., NFS, CIFS, DNS, etc). 510 USING THE FEDERATION INTERFACES, a federation operation that 511 requires an interaction between two (or more) entities that are 512 members of the federation MUST be possible without requiring any 513 proprietary protocols. 515 A4: All the entities participating in a federation operation MUST be 516 able to authenticate each other. 518 All principals (clients, users, administrator of a singleton or 519 server collection, hosts, NSDB nodes, etc) that can assume a 520 role defined by the federation protocol can identify themselves 521 to each other via an authentication mechanism. This mechanism 522 is not defined or further described in this document. 524 The authority of a principal to request that a second principal 525 perform a specific operation is ultimately determined by the 526 second. Authorization may be partitioned by server collection 527 or set of servers as well as by operation. For example, if a 528 user has administrative privileges on one server in the 529 federation, this does not imply that they have administrative 530 privileges (or, for that matter, any privileges whatsoever) on 531 any other server in the federation. 533 In order to access the functionality provided by the federation 534 interfaces, it may be necessary to have elevated privileges or 535 authorization. The authority required by different operations 536 may be different. For example, the authority required to query 537 the NSDB about the FSLs bound to an FSN may be different than 538 the authority required to change the bindings of that FSN. 540 An operation attempted by an unauthorized entity MUST fail in a 541 manner that indicates that the failure was due to insufficient 542 authorization. 544 This document does not enumerate the authorization necessary for 545 any operation. 547 A5: The federation protocols MUST NOT require changes to existing 548 authentication/authorization mechanisms in use at the 549 fileservers for client-facing protocols. 551 A user's view of the namespace may be limited by the 552 authentication and authorization privileges it has on the 553 different fileservers in the federation. As such, users may 554 only be able to traverse the parts of the namespace that they 555 have access to. 557 The federation protocols do not impose any restrictions on how 558 users are represented within the federation. For example, a 559 single enterprise could employ a common identity for users 560 across the federation. A grid environment could utilize user 561 mapping or translations across different administrative domains. 563 A6: In a federated system, we assume that an FSN MUST express, or 564 can be used to discover, the following two pieces of 565 information: 567 1. The location of the NSDB node that is responsible for 568 knowing the filesystem location(s) (FSLs) of the named 569 fileset. 571 The NSDB node must be specified because there may be many 572 NSDB nodes in a federation. We do not assume that any 573 single entity knows the location of all of the NSDB nodes, 574 and therefore exhaustive search is not an option. 576 There are several ways in which a fileserver can locate the 577 NSDB node responsible for a given fileset. One approach, 578 given a DNS infrastructure, is to specify the location of 579 the NSDB node by the FQDN of the server hosting the NSDB 580 node. Another approach is to use a separate DNS-style 581 hierarchy to resolve the location of the NSDB node. 583 2. The FSN identifier. 585 The FSN identifier is the index used by the NSDB node to 586 identify the target fileset. 588 There are several ways to represent FSN identifiers. One 589 approach could use 128-bit UUIDs as described described in 590 [RFC4122]. 592 As an example, an FSN could be represented by a URL of the form 593 nsdb://nsdb.example.com/UUID where nsdb is the scheme name, 594 nsdb.example.com is the FQDN of the server hosting the NSDB 595 node, and UUID is the string representation of the identifier. 597 Note that it is not assumed that it is always required for a 598 server to contact the NSDB node specified by the FSN in order to 599 find the FSLs. The relevant information stored in that NSDB 600 node may also be cached local to the server or on a proxy NSDB 601 node "near" the server. 603 A7: All federation servers and NSDB nodes are assumed to execute the 604 federation protocols correctly. The behavior of the federation 605 is undefined in the case of Byzantine behavior by any federation 606 server or NSDB node. 608 A8: The locations of federation services (such as NSDBs and FSLs) 609 can be specified in a manner such that they can be correctly 610 interpreted by all members of the federation that will access 611 them. 613 For example, if an NSDB node is specified by a FQDN, then this 614 implies that every member of the federation that needs to access 615 this NSDB node can resolve this FQDN to an IP address for that 616 NSDB node. (It is not necessary that the FQDN always resolve to 617 the same address; the same service may appear at different 618 addresses on different networks.) 620 It is the responsibility of each federation member to ensure 621 that the resources it wishes to expose have accessible network 622 locations and that the necessary resolution mechanisms (i.e., 623 DNS) are given the necessary data to perform the resolution 624 correctly. 626 5.2. Requirements 628 R1: Requirements of each FSN: 630 a. Each FSN MUST be unique within the scope of its NSDB (so 631 that the FSN is globally unique). 633 b. The FSN MUST be sufficiently descriptive to locate an 634 instance of the fileset it names within the federation at 635 any time. 637 c. All FSNs MUST be invariant when their underlying 638 filesystems move or are replicated; only mappings from FSN 639 to FSL(s) change under these transformations. 641 d. All files accessible from the global namespace MUST be part 642 of a fileset that has an assigned FSN. 644 Not all filesets in the federation are required to have an FSN 645 or be reachable by an FSL. Only those filesets that are the 646 target of a junction (as described in R3) are required to have 647 an FSN. 649 The FSN format MAY be variable size. If the format is variable 650 size, fileserver implementations MAY have a maximum supported 651 FSN size. By bounding the FSN size, some fileserver 652 implementations might be able to efficiently organize FSNs in 653 stable storage. For interoperability, the federation protocols 654 SHOULD define an FSN size that all fileservers support. 656 R2: USING THE FEDERATION INTERFACES, it MUST be possible to create 657 an FSN for a fileset, and it must be possible to bind an FSL to 658 that FSN. These operations are NSDB operations and do not 659 require any action on the part of a file server. 661 It is possible to create an FSN for a fileset that has not 662 actually been created. It is also possible to bind a 663 nonexistent FSL to an FSN. It is also possible to create a 664 fileset without assigning it an FSN. The binding between an 665 FSN and an FSL is defined entirely within the context of the 666 NSDB; the servers do not "know" whether the filesets they host 667 have been assigned FSNs (or, if so, what those FSNs are). 669 The requirement that filesets can exist prior to being assigned 670 an FSN, and the requirement that FSNs can exist independent of 671 filesets are intended to simplify the construction of the 672 namespace in a convenient manner. For example, they permit an 673 admin to assign FSNs to existing filesets and thereby 674 incorporate existing filesets into the namespace. They also 675 permit the structure of the namespace to be defined prior to 676 creation of the component filesets. In either case, it is the 677 responsibility of the entity updating the NSDB with FSNs and 678 FSN-to-FSL mappings to ensure that the namespace is constructed 679 in a consistent manner. (The simplest way to accomplish this 680 is to ensure that the FSN and FSN-to-FSL mappings are always 681 recorded in the NSDB prior to the creation of any junctions 682 that refer to that FSN.) 684 a. An administrator MAY specify the entire FSN (including both 685 the NSDB node location and the identifier) of the newly- 686 created FSL, or the administrator MAY specify only the NSDB 687 node and have the system choose the identifier. 689 The admin can choose to specify the FSN explicitly in order 690 to recreate a lost fileset with a given FSN (for example, 691 as part of disaster recovery). It is an error to assign an 692 FSN that is already in use by an active fileset. 694 Note that creating a replica of an existing filesystem is 695 NOT accomplished by assigning the FSN of the filesystem you 696 wish to replicate to a new filesystem. 698 b. USING THE FEDERATION INTERFACES, it MUST be possible to 699 create a federation FSL by specifying a specific local 700 volume, path, export path, and export options. 702 R3: USING THE FEDERATION INTERFACES, and given the FSN of a target 703 fileset, it MUST be possible to create a junction to that 704 fileset at a named place in another fileset. 706 After a junction has been created, clients that access the 707 junction transparently interpret it as a reference to the 708 FSL(s) that implement the FSN associated with the junction. 710 a. It SHOULD be possible to have more than one junction whose 711 target is a given fileset. In other words, it SHOULD be 712 possible to mount a fileset at multiple named places. 714 b. If the fileset in which the junction is created is 715 replicated, then the junction MUST eventually appear in all 716 of its replicas. 718 The operation of creating a junction within a fileset is 719 treated as an update to the fileset, and therefore obey the 720 general rules about updates to replicated filesets. 722 R4: USING THE FEDERATION INTERFACES, it MUST be possible to delete 723 a specific junction from a fileset. 725 If a junction is deleted, clients who are already viewing the 726 fileset referred to by the junction after traversing the 727 junction MAY continue to view the old namespace. They might 728 not discover that the junction no longer exists (or has been 729 deleted and replaced with a new junction, possibly referring to 730 a different FSN). 732 After a junction is deleted, another object with the same name 733 (another junction, or an ordinary filesystem object) may be 734 created. 736 The operation of deleting a junction within a fileset is 737 treated as an update to the fileset, and therefore obey the 738 general rules about updates to replicated filesets. 740 R5: USING THE FEDERATION INTERFACES, it MUST be possible to 741 invalidate an FSN. 743 a. If a junction refers to an FSN that is invalid, attempting 744 to traverse the junction MUST fail. 746 An FSN that has been invalidated MAY become valid again if the 747 FSN is recreated (i.e., as part of a disaster recovery 748 process). 750 If an FSN is invalidated, clients who are already viewing the 751 fileset named by the FSN MAY continue to view the old 752 namespace. They might not discover that the FSN is no longer 753 valid until they try to traverse a junction that refers to it. 755 R6: USING THE FEDERATION INTERFACES, it MUST be possible to 756 invalidate an FSL. 758 a. An invalid FSL MUST NOT be returned as the result of 759 resolving a junction. 761 An FSL that has been invalidated MAY become valid again if the 762 FSL is recreated (i.e., as part of a disaster recovery 763 process). 765 If an FSL is invalidated, clients who are already viewing the 766 fileset implemented by the FSL MAY continue to use that FSL. 767 They might not discover that the FSL is no longer valid until 768 they try to traverse a junction that refers to the fileset 769 implemented by the FSL. 771 Note that invalidating an FSL does not imply that the 772 underlying export or share (depending on the file access 773 protocol in use) is changed in any way -- it only changes the 774 mappings from FSNs to FSLs on the NSDB. 776 R7: It MUST be possible for the federation of servers to provide 777 multiple namespaces. 779 R8: USING THE FEDERATION INTERFACES: 781 a. It MUST be possible to query the fileserver named in an FSL 782 to discover whether a junction exists at a given path 783 within that FSL. 785 b. It MAY be possible to query the fileserver named in an FSL 786 to discover the junctions, if any, in that FSL. If this 787 feature is implemented, the fileserver SHOULD report each 788 junction's path within the FSL and the targeted FSN. 790 R9: The projected namespace (and the objects named by the 791 namespace) MUST be accessible to clients via at least one of 792 the following standard filesystem access protocols: 794 a. The namespace SHOULD be accessible to clients via versions 795 of the CIFS (SMB) protocol. 797 b. The namespace SHOULD be accessible to clients via the NFSv4 798 protocol as described in [RFC3530]. 800 c. The namespace SHOULD be accessible to clients via the NFSv3 801 protocol as described in [RFC1813]. 803 d. The namespace SHOULD be accessible to clients via the NFSv2 804 protocol as described in [RFC1094]. 806 It must be understood that some of these protocols, such as 807 NFSv3 and NFSv2, have no innate ability to access a namespace 808 of this kind. Where such protocols have been augmented with 809 other protocols and mechanisms (such as autofs or amd for 810 NFSv3) to provide an extended namespace, we propose that these 811 protocols and mechanisms may be used, or extended, in order to 812 satisfy the requirements given in this draft, and different 813 clients may use different mechanisms. 815 R10: USING THE FEDERATION INTERFACES, it MUST be possible to modify 816 the NSDB mapping from an FSN to a set of FSLs to reflect the 817 migration from one FSL to another. 819 R11: FSL migration SHOULD have little or no impact on the clients, 820 but this is not guaranteed across all federation members. 822 Whether FSL migration is performed transparently depends on 823 whether the source and destination servers are able to do so. 824 It is the responsibility of the administrator to recognize 825 whether or not the migration will be transparent, and advise 826 the system accordingly. The federation, in turn, MUST advise 827 the servers to notify their clients, if necessary. 829 For example, on some systems, it may be possible to migrate a 830 fileset from one system to another with minimal client impact 831 because all client-visible metadata (inode numbers, etc) are 832 preserved during migration. On other systems, migration might 833 be quite disruptive. 835 R12: USING THE FEDERATION INTERFACES, it MUST be possible to modify 836 the NSDB mapping from an FSN to a set of FSLs to reflect the 837 addition/removal of a replica at a given FSL. 839 R13: Replication SHOULD have little or no negative impact on the 840 clients. 842 Whether FSL replication is performed transparently depends on 843 whether the source and destination servers are able to do so. 844 It is the responsibility of the administrator initiating the 845 replication to recognize whether or not the replication will be 846 transparent, and advise the federation accordingly. The 847 federation MUST advise the servers to notify their clients, if 848 necessary. 850 For example, on some systems, it may be possible to mount any 851 FSL of an FSN read/write, while on other systems, there may be 852 any number of read-only replicas but only one FSL that can be 853 mounted read-write. 855 R14: USING THE FEDERATION INTERFACES, it SHOULD be possible to 856 annotate the objects and relations managed by the federation 857 protocol with arbitrary name/value pairs. 859 These annotations are not used by the federation protocols -- 860 they are intended for use by higher-level protocols. For 861 example, an annotation that might be useful for a system 862 administrator browsing the federation would be the "owner" of 863 each FSN (i.e., "this FSN is for the home directory of Joe 864 Smith."). As another example, the annotations may express 865 hints used by the clients (such as priority information for 866 NFSv4.1). 868 Both FSNs and FSLs may be annotated. For example, an FSN 869 property might be "This is Joe Smith's home directory", and an 870 FSL property might be "This instance of the FSN is at the 871 remote backup site." 873 a. USING THE FEDERATION INTERFACES, it MUST be possible to 874 query the system to find the annotations for a junction. 876 b. USING THE FEDERATION INTERFACES, it MUST be possible to 877 query the system to find the annotations for an FSN. 879 c. USING THE FEDERATION INTERFACES, it MUST be possible to 880 query the system to find the annotations for an FSL. 882 R15: It MUST be possible for the federation to project a namespace 883 with a common root. 885 a. It SHOULD be possible to define a root fileset that is 886 exported by one or more fileservers in the federation as 887 the top level of a namespace. [Corollary: There is one 888 root fileset per namespace and it is possible to support 889 multiple namespaces per federation.] 891 b. It SHOULD be possible for a fileserver to locate an NSDB 892 that stores the layout of a root fileset. 894 c. It SHOULD be possible to access, store and update 895 information related to a root fileset using the federation 896 protocols. 898 d. It SHOULD be possible to replicate root fileset information 899 across multiple repositories. 901 e. If a root fileset is defined it SHOULD be possible to 902 enable a file server to export that root fileset for client 903 access. 905 f. If a root fileset is defined it SHOULD be possible for 906 multiple file servers to project a common root with defined 907 consistency semantics. 909 g. If a root fileset is defined it SHOULD be stored using a 910 compact representation that is compatible with 911 heterogeneous fileserver implementations. The root 912 fileset's internal format SHOULD contain enough information 913 to generate any attributes, including referrals, required 914 by the standard filesystem access protocols in R9. 916 6. Non-Requirements 918 N1: It is not necessary for the namespace to be known by any 919 specific fileserver. 921 In the same manner that clients do not need to have a priori 922 knowledge of the structure of the namespace or its mapping onto 923 federation members, the projected namespace can exist without 924 individual fileservers knowing the entire organizational 925 structure, or, indeed, without knowing exactly where in the 926 projected namespace the filesets they host exist. 928 Fileservers do need to be able to handle referrals from other 929 fileservers, but they do not need to know what path the client 930 was accessing when the referral was generated. 932 N2: It is not necessary for updates and accesses to the NSDB data to 933 occur in transaction or transaction-like contexts. 935 One possible requirement that is omitted from our current list 936 is that updates and accesses to the data stored in the NSDB (or 937 individual NSDB nodes) occur within a transaction context. We 938 were not able to agree whether the benefits of transactions are 939 worth the complexity they add (both to the specification and its 940 eventual implementation) but this topic is open for discussion. 942 Below is the the draft of a proposed requirement that provides 943 transactional semantics: 945 "There MUST be a way to ensure that sequences of operations, 946 including observations of the namespace (including finding 947 the locations corresponding to a set of FSNs) and changes to 948 the namespace or related data stored in the system (including 949 the creation, renaming, or deletion of junctions, and the 950 creation, altering, or deletion of mappings between FSN and 951 filesystem locations), can be performed in a manner that 952 provides predictable semantics for the relationship between 953 the observed values and the effect of the changes." 955 "It MUST be possible to protect sequences of operations by 956 transactions with NSDB-wide or server-wide ACID semantics." 958 7. Security Considerations 960 Assuming the Internet threat model, the federated resolution 961 mechanism described in this document MUST be implemented in such a 962 way to prevent loss of CONFIDENTIALITY, DATA INTEGRITY and PEER 963 ENTITY AUTHENTICATION, as described in [RFC3552]. 965 CONFIDENTIALITY may be violated if an unauthorized party is able to 966 eavesdrop on the communication between authorized servers and NSDB 967 nodes and thereby learn the locations or other information about FSNs 968 that they would not be authorized to discover via direct queries. 969 DATA INTEGRITY may be compromised if a third party is able to 970 undetectably alter the contents of the communication between servers 971 and NSDB nodes. PEER ENTITY AUTHENTICATION is defeated if one server 972 can masquerade as another server without proper authority, or if an 973 arbitrary host can masquerade as a NSDB node. 975 Well-established techniques for providing authenticated channels may 976 be used to defeat these attacks, and the protocol MUST support at 977 least one of them. 979 For example, if LDAP is used to implement the query mechanism 980 [RFC4510], then TLS may be used to provide both authentication and 981 integrity [RFC5246] [RFC4513]. If the query protocol is implemented 982 on top of ONC/RPC, then RPCSEC_GSS may be used to fill the same role 983 [RFC2203] [RFC2743]. 985 A federation could contain multiple Public Key Infrastructure (PKI) 986 trust anchors [RFC5280]. The federation protocols SHOULD define a 987 mechanism for managing a fileserver's NSDB trust anchors 988 [TA-MGMT-REQS]. A general purpose trust anchor management protocol 989 [TAMP] would be appropriate, though it might be desirable for the 990 federation protocols to facilitate trust anchor management by, for 991 example, using trust anchor interchange formats [TA-FORMAT]. 993 It is useful to note that the requirements described in this document 994 lead naturally to a system with distributed authorization, which has 995 scalability and manageability benefits. 997 FSNs are likely to be long lived resources. Therefore, the privilege 998 to create FSNs SHOULD be carefully controlled. To assist in 999 determining if an FSN is referenced by a junction somewhere in the 1000 federation, the NSDB records SHOULD include non-authoritative 1001 informational annotations recording the locations of any such 1002 junctions. These annotations are non-authoritative because a 1003 junction might be created, deleted, or modified by an individual that 1004 does not have permission to modify the NSDB records. 1006 8. IANA Considerations 1008 This document has no actions for IANA. 1010 9. References 1012 9.1. Normative References 1014 [NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4 1015 Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (work 1016 in progress), December 2008. 1018 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1019 Requirement Levels", BCP 14, RFC 2119, March 1997. 1021 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 1022 Beame, C., Eisler, M., and D. Noveck, "Network File System 1023 (NFS) version 4 Protocol", RFC 3530, April 2003. 1025 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1026 Text on Security Considerations", BCP 72, RFC 3552, 1027 July 2003. 1029 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1030 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1031 July 2005. 1033 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 1034 (LDAP): Technical Specification Road Map", RFC 4510, 1035 June 2006. 1037 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1038 Housley, R., and W. Polk, "Internet X.509 Public Key 1039 Infrastructure Certificate and Certificate Revocation List 1040 (CRL) Profile", RFC 5280, May 2008. 1042 9.2. Informational References 1044 [RFC1094] Nowicki, B., "NFS: Network File System Protocol 1045 specification", RFC 1094, March 1989. 1047 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 1048 Version 3 Protocol Specification", RFC 1813, June 1995. 1050 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 1051 Specification", RFC 2203, September 1997. 1053 [RFC2743] Linn, J., "Generic Security Service Application Program 1054 Interface Version 2, Update 1", RFC 2743, January 2000. 1056 [RFC4513] Harrison, R., "Lightweight Directory Access Protocol 1057 (LDAP): Authentication Methods and Security Mechanisms", 1058 RFC 4513, June 2006. 1060 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1061 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1063 [TA-FORMAT] 1064 Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 1065 Format", draft-ietf-pkix-ta-format-04 (work in progress), 1066 October 2009. 1068 [TA-MGMT-REQS] 1069 Reddy, R. and C. Wallace, "Trust Anchor Management 1070 Requirements", draft-ietf-pkix-ta-mgmt-reqs-04 (work in 1071 progress), September 2009. 1073 [TAMP] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 1074 Management Protocol (TAMP)", draft-ietf-pkix-tamp-03 (work 1075 in progress), October 2009. 1077 Appendix A. Acknowledgments 1079 We would like to thank Robert Thurlow of Sun Microsystems for helping 1080 to author this document. 1082 We would also like to thank Peter McCann and and Nicolas Williams for 1083 their comments and suggestions. 1085 Authors' Addresses 1087 James Lentini 1088 NetApp 1089 1601 Trapelo Rd, Suite 16 1090 Waltham, MA 02451 1091 US 1093 Phone: +1 781-768-5359 1094 Email: jlentini@netapp.com 1096 Craig Everhart 1097 NetApp 1098 7301 Kit Creek Rd 1099 Research Triangle Park, NC 27709 1100 US 1102 Phone: +1 919-476-5320 1103 Email: everhart@netapp.com 1105 Daniel Ellard 1106 BBN Technologies 1107 10 Moulton Street 1108 Cambridge, MA 02138 1109 US 1111 Phone: +1 617-873-8000 1112 Email: dellard@bbn.com 1114 Renu Tewari 1115 IBM Almaden 1116 650 Harry Rd 1117 San Jose, CA 95120 1118 US 1120 Email: tewarir@us.ibm.com 1121 Manoj Naik 1122 IBM Almaden 1123 650 Harry Rd 1124 San Jose, CA 95120 1125 US 1127 Email: manoj@almaden.ibm.com