Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

Network File and Resource Sharing Protocols and the

TCP/IP Network File System (NFS)

To the typical end user, networks were created for one main reason: to permit the sharing of

information. Most information on computers exists in the form of files that reside on storage

devices such as hard disks; thus, one primary purpose of networks is to let users share

files. File transfer and message transfer protocols exist that allow users to “manually” move

files from one place to the next, but a more automated method is preferable in many cases.

Internetworking protocols provide such capabilities in the form of network file and resource

sharing protocols.

In this section, I provide a description of network file and resource sharing protocols from

the standpoint of TCP/IP networks. I begin with a brief overview of the concepts and

operation of this class of protocols, discussing some of the elements common to the

different types. I then describe the most common one defined specifically for TCP/IP: the

Network File System (NFS).

Related Information: Obviously, network file and resource sharing protocols and

services are closely related to the file and message transfer protocols I mentioned

earlier. For example, NFS can be used to accomplish tasks similar to those

performed by TCP/IP file and message transfer applications such as FTP and HTTP. I

consider those protocols more like specific end-user application unto themselves, and

therefore describe them in the section on application protocols. I realize that this distinction

between “manual” and “automatic” file transfer is somewhat arbitrary, but then, so are a lot

of other things in the great world of networking. ☺

Overview of File and Resource Sharing Protocol Concepts and

Operation

Networking is a pretty complicated subject—if you don't believe me, try glancing at the topic

list for this Guide. To people like you, who are probably reading this Guide to learn about

networks to enhance your ability to make a living in the technology world, this complexity

means enhanced job security, so don't knock it. ☺ On the other hand, the main body of

“regular users” just want to be able to do things on the network, without being forced to

understand how everything works underneath. This is only common sense.

Contrasting "Manual" and "Automatic" File and Resource Sharing

A primary reason why networks and internetworks are created is to allow files and other

resources to be shared between computers. Thus, in any internetworking protocol stack,

we need some mechanism by which users can easily moves files across a network in a

simple way. Application-layer file and message transfer protocols like FTP and HTTP were

created for just this purpose: to let users access resources across a network while hiding

the details of how the network operates at the layers below them.

However, even though these protocols hide the lower layers, they are somewhat “manual”

in nature: they require a user to invoke an application protocol and use specific commands

that accomplish network-based resource access. In fact, the problem with such protocols

isn't so much that they require manual intervention, but that they make sharing more difficult

because they don't allow a file to be used directly on another resource. To see what I mean,

consider a protocol like FTP. It does lets me share files between machines, but draws a

clear distinction between a file that is mine and a file that is someone else's. If I want to use

a file on Joe's machine, I have to transfer it to mine, use it, and then transfer it back. Also, if

I don't transfer the file back, Joe might never even see the updated version.

The ultimate in file and resource sharing is achieved when we can hide even the details of

how the files are located and the commands required to move them around. Such a system

would use an “automatic” sharing protocol that lets files and resources be used over a

network seamlessly. Once set up, a network resource in such a scheme can be used in

much the same way that one on a local computer is. Such protocols are sometimes called

network file and resource sharing protocols.

It is this “blurring” of the line between a local file and a remote one that makes file and

resource sharing protocols so powerful. Once the system is set up, a user can access

resources on another host as readily as on his own host. This is an extremely powerful

capability, especially in the modern era of client/server computing. For example, it allows a

company to store information that is used by many individuals in a common place, such as

in a directory on a server, and allow each of those individuals to access it. In essence, a

“virtual file system” is created that spans network devices, instead of being simply on one

storage device on a single computer.

Components of a File and Resource Sharing Protocol

Network file and resource sharing protocols allow users to share files “effortlessly”, but that

doesn't mean the work doesn't still have to happen. It is still there, but shouldered by those

who write the protocol, and those who administer its operation. Generally speaking, these

protocols require at least the following general components:

☯ File System Model and Architecture: A mechanism for defining resources and files

to be shared, and for describing how the “virtual file system” works.

☯ Resource Access Method: Procedures that describe how a user can attach or

detach a distant resource from his or her local host.

☯ Operation Set: A set of operations for accomplishing various tasks that the user

needs to perform on files on other hots.

☯ Messaging Protocol: Message formats that carry operations to be performed, status

information and more, and a protocol for exchanging these messages between

devices.

☯ Administrative Tools: Miscellaneous functionality needed to support the operation of

the protocol and tie the other elements together.

The most common file and resource sharing protocol used in TCP/IP today is the Network

File System (NFS). It is described in more detail in the next section.

TCP/IP Network File System (NFS)

File and resource sharing protocols are important because they let users seamlessly share

files over a network. Due to the dominance of Microsoft operating systems in the industry,

many people are familiar with the way Microsoft Networking can be used in this way.

However, Microsoft is somewhat of a “Johnny come lately” to file sharing protocols. Long

before Microsoft Windows even existed, the Network File System (NFS) was letting users

share files over a network using the UNIX operating system.

In this section, I provide a brief look at the operation of NFS. I begin with an overview and

history of the protocol, and discussion of its common versions and standards. I describe the

architecture of NFS and the three components that comprise it. I then describe the NFS file

system model, and how data is encoded using the External Data Representation (XDR)

standard. I explain the client/server operation of NFS using Remote Procedure Calls

(RPCs). I then list the procedures and operations used in NFS, and conclude with a

description of the separate NFS Mount protocol, used to attach network resources to a

device.

Note: As I said above, NFS was originally developed specifically for the UNIX

operating system, and is still most closely associated with UNIX. As with all

protocol descriptions, I have attempted to keep my discussion of NFS “OS-

independent” as much as possible, but in some places in this section, it is not entirely

possible.

NFS Overview, History, Versions and Standards

The histories of TCP/IP and the Internet are inextricably linked, as you can read for yourself

in my discussion of the history of TCP/IP. However, there is a third partner that is less-often

mentioned, but very much part of the development history of these technologies. That is the

operating system that ran on the machines in the early Internet, still used on a large

percentage of Internet servers today: the UNIX operating system.

Sun Microsystems was one of the early pioneers in the development of UNIX, and in TCP/

IP networking. Early in the evolution of TCP/IP, certain tools were created to allow a user to

access another machine over the network—after all, this is arguably the entire point of

networking. Remote access protocols such as Telnet allowed a user to log in to another

host computer and use resources there. The File Transfer Protocol (FTP) allowed someone

to copy a file from a distant machine to their own and edit it.

However, neither of these solutions really fit the bill of allowing a user to access a file on a

remote machine in a way similar to how a local file is used. To fill this need, Sun created the

Network File System (NFS). NFS was specifically designed with the goal of eliminating the

distinction between a local and a remote file. To a user, after the appropriate setup is

performed, a file on a remote computer can be used as if it were on a hard disk on the

user's local machine. Sun also crafted NFS specifically to be vendor-independent, to

ensure that both hardware made by Sun and that made by other companies could

interoperate.

Overview of NFS Architecture and General Operation

NFS follows the classical TCP/IP client/server model of operation. A hard disk or a directory

on a storage device of a particular computer can be set up by an administrator as a shared

resource. This resource can then be accessed by client computers, which mount the shared

drive or directory, causing it to appear like a local directory on the client machine. Some

computers may act as only servers or only clients, while others may be both: sharing some

of their own resources and accessing resources provided by others.

NFS uses an architecture that includes three main components that define its operation.

The External Data Representation (XDR) standard defines how data is represented in

exchanges between clients and servers. The Remote Procedure Call (RPC) protocol is

used as a method of calling procedures on remote machines. Then, a set of NFS proce-

dures and operations works using RPC to carry out various requests. The separate Mount

protocol is used to mount resources as mentioned above.

One of the most important design goals of NFS was performance. Obviously, even if you

set up a file on a distant machine as if it were local, the actual read and write operations

have to travel across a network. Usually this takes more time than simply sending data

within a computer, so the protocol itself needed to be as “lean and mean” as possible. This

decision led to some interesting decisions, such as the use of the unreliable User Datagram

Protocol (UDP) for transport in TCP/IP, instead of the reliable TCP like most file transfer

protocols do. This in turn has interesting implications on how the protocol works as a whole.

Another key design goal for NFS was simplicity (which of course is related to perfor-

mance). NFS servers are said to be stateless, which means that the protocol is designed so

that servers do not need to keep track of which files have been opened by which clients.

This allows requests to be made independently of each other, and allows a server to grace-

fully deal with events such as crashes without the need for complex recovery procedures.

The protocol is also designed so that if requests are lost or duplicated, file corruption will not

occur.

Key Concept: The Network File System (NFS) was created to allow client hosts to

access files on remote servers as if they were local. It was designed primarily with

the goals of performance, simplicity and cross-vendor compatibility.

NFS Versions and Standards

Since it was initially designed and marketed by Sun, NFS began as a de facto standard.

The first widespread version of NFS was version 2, and this is still the most common

version of the protocol. NFS version 2 was eventually codified as an official TCP/IP

standard when RFC 1094, NFS: Network File System Protocol Specification

, was published

in 1989.

NFS Version 3 was subsequently developed, and published in 1995 as RFC 1813, NFS

Version 3 Protocol Specification. It is similar to version 2 but makes a few changes and

adds some new capabilities. These include support for larger file transfers, better support

for setting file attributes, and several new file access and manipulation procedures. NFS

version 3 also provides support for larger files than version 2 did.

NFS Version 4 was published in 2000 as RFC 3010, NFS version 4 Protocol

. Where version

3 of NFS contained only relatively small changes to version 2, NFSv4 is virtually a rewrite of

NFS. It includes numerous changes, most notably the following:

☯ Reflecting the needs of modern internetworking, NFSv4 puts greater emphasis on

security.

☯ NFSv4 introduces the concept of a Compound procedure, which allows several

simpler procedures to be sent from a client to server as a group.

☯ NFSv4 almost doubles the number of individual procedures that a client can use in

accessing a file on an NFS server.

☯ Version 4 also makes a significant change in messaging, with the specification of TCP

as the transport protocol for NFS.

☯ Finally, NFS integrates the functions of the Mount protocol into the basic NFS protocol,

eliminating it as a separate protocol as it is in versions 2 and 3.

The version 4 standard also has a lot more details about implementation and optional

features than the earlier standards—it's 275 pages long. So much for simplicity! ☺ RFC

3010 was later updated by RFC 3530, Network File System (NFS) version 4 Protocol

, in

April 2003. This standard makes several further revisions and clarifications to the operation

of NFS version 4.

NFS Architecture and Components

Considered from the perspective of the TCP/IP protocol suite as a whole, the Network File

System (NFS) is a single protocol that resides at the application layer of the TCP/IP (DOD)

model. This TCP/IP layer encompasses the session, presentation and application layers of

the OSI Reference Model. As I have said before in this Guide, I don't see much value in

trying to differentiate between layers 5 through 7 most of the time. In some cases, however,

these layers can be helpful in understanding the architecture of a protocol, and that's the

case with NFS.

NFS Architecture and Main Components

The operation of NFS is defined in the form of three main components that can be viewed

as logically residing at each of the three OSI model layers corresponding to the TCP/IP

application layer (see Figure 253). These components are:

☯ Remote Procedure Call (RPC): RPC is a generic session layer service used to

implement client/server internetworking functionality. It extends the notion of a

program calling a local procedure on a particular host computer, to the calling of a

procedure on a remote device across a network.

☯ External Data Representation (XDR): XDR is a descriptive language that allows data

types to be defined in a consistent manner. XDR conceptually resides at the presen-

tation layer; its universal representations allow data to be exchanged using NFS

between computers that may use very different internal methods of storing data.

☯ NFS Procedures and Operations: The actual functionality of NFS is implemented in

the form of procedures and operations that conceptually function at layer seven of the

OSI model. These procedures specify particular tasks to be carried out on files over

the network, using XDR to represent data and RPC to carry the commands across an

internetwork.

These three key “subprotocols” if you will, comprise the bulk of the NFS protocol. Each is

described in more detail in a separate topic of this section on NFS.

Key Concept: NFS resides architecturally at the application layer of the TCP/IP

model. Its functions are implemented primarily through three distinct functional

components that implement the functions of layers five through seven of the OSI

reference model: the Remote Procedure Call (RPC), which provide session-layer services;

the External Data Representation (XDR) standard, which manages data representation and

conversion, and NFS procedures and operations, which allow application-layer tasks to be

performed using the other two components.

Other Important NFS Functions

Aside from these three components, the NFS protocol as a whole involves a number of

other functions, some of which I think are worth specific mention:

☯ Mount Protocol: A specific decision was made by the creators of NFS to not have

NFS deal with the particulars of file opening and closing. Instead, a separate protocol

called the Mount protocol is used for this purpose. Accessing a file or other resource

over the network involves first mounting it using this protocol. The Mount Protocol is

architecturally distinct, but obviously closely related to NFS, and is even defined in an

appendix of the NFS standard. I describe it in the last topic of this section. (Note that in

NFSv4 the functions of the Mount Protocol have been incorporated into NFS “proper”.)

☯ NFS File System Model: NFS uses a particular model to implement the directory and

file structure of the systems that use it. This model is closely based on the file system

model of UNIX but is not specific to only that operating system. It is discussed in

conjunction with the explanation of the Mount Protocol.

☯ Security: Versions 2 and 3 of NFS include only limited security provisions. They use

UNIX style authentication to check permissions for various operations. NFS version 4

greatly increases the security options available for NFS implementations. This

includes both the option of multiple authentication and encryption algorithms, and

many changes made to the protocol as a whole to make it more “security minded”.

Like other TCP/IP protocols, NFS is implemented in the form of client and server software

that implements the functions above. The NFS standards, especially for versions 3 and 4,

discuss numerous issues related to proper NFS client/server implementation, including

interaction between servers and clients, file locking, permission issues, caching, retrans-

mission policies, international support and more. Many of these issues require extensive

discussion that is beyond the scope of this Guide. You will want to refer to the standards for

NFS, especially versions 3 and 4, for full details.

Figure 253: NFS Architectural Components

NFS resides architecturally at the TCP/IP application layer. Even though in the TCP/IP model no clear

distinction is made generally between the functions of layers five through seven of the OSI Reference Model,

NFS’s three subprotocols correspond well to those three layers as shown.

OSI Model

7 Application

1 Physical

6 Presentation

5 Session

4 Transport

3 Network

2 Data Link

TCP/IP Model

ApplicationApplication

Transport

Internet

Network Interface

Application

Remote Procedure Call

(RPC) Service

External Data

Representation (XDR)

NFS Procedures

and Operations

Network File System

(NFS)

NFS Data Storage and Data Types, and the External Data

Representation (XDR) Standard

The overall idea behind NFS is to allow someone on one computer to read from or write to

a file on another computer as readily as they do on a local machine. Of course, the files on

your local machine are all stored in the same file system, using the same file structure and

the same means of representing different types of data. You can't be sure that this will be

the case when accessing a remote device, and this creates a bit of a “Tower of Babel”

problem that NFS has to deal with.

Creating a Method of Universal Data Exchange: XDR

One approach to representation consistency would be to simply restrict access only to

remote files on machines that use the same operating system. However, this would remove

much of the effectiveness of NFS. It would also be highly impractical to require every

computer to understand the internal representation of every other one. A more general

method was needed to allow even very dissimilar machines to share data. To this end, the

creators of NFS defined it so that it deals with data using a universal data description

language. This language is called the External Data Representation (XDR) standard, and

was originally described in RFC 1014; it was updated in RFC 1832, XDR: External Data

Representation Standard, in 1995.

The idea behind XDR is simple, and can be easily understood in the form of an analogy. If

you had delegates speaking 50 different languages at a convention, they would have a hard

time communicating. You could hire translators to facilitate, but you'd never find translators

to handle all the different possible combinations of languages. A more practical solution is

to declare one language, such as English, to be a common language. You then only need

49 translators: one to translate from English to each of the non-English languages and back

again. To translate from Swedish to Portuguese, you translate from Swedish to English and

then from English to Portuguese. The common language could be French, or Spanish, or

something else, as long as a translator could be found from all the other languages to that

common language.

XDR works in the same manner. When information about how to access a file is to be trans-

ferred from device A to device B, device A first converts it from A's internal representation to

the XDR representation of those data types. The information is transmitted across the

network using XDR encoding. Then, device B translates from XDR back to its own internal

representation, so it can be presented to the user as if it were on the local file system. Each

device needs to know only how to convert from its own “language” to XDR and back again;

device A doesn't need to know device B's internal details and vice-versa. This sort of trans-

lation is of course a classic job of the presentation layer, which is where XDR resides in the

OSI Reference Model. XDR is itself based on an ISO standard called the Abstract Syntax

Notation.

Incidentally, the idea described here is also used in other protocols to allow the exchange of

data independent of the nature of the underlying systems. For example, a similar idea is

behind the way management information is exchanged using the Simple Network

Management Protocol (SNMP). The same basic idea underlies the important Network

Virtual Terminal (NVT) paradigm used in the Telnet protocol.

Key Concept: The purpose of the External Data Representation (XDR) standard is

to define a common method for representing common data types. Using this

universal representation, data can be exchanged between devices regardless of

what internal file system each uses. This enables NFS to exchange file data between

clients and servers that may be implemented using very different hardware and software

platforms.

XDR Data Types

For XDR to be universal, it must allow the description of all the common types of data that

are used in computers. For example, it must allow integers, floating point numbers, strings

and other data constructs to be exchanged. The XDR standard describes the structure of

many data types using a notation somewhat similar to the language “C”. As you may know,

this is one of the most popular languages in computing history, and is closely associated

with UNIX and, as a result, certain TCP/IP technologies as well.

Table 182 shows the data types defined by XDR, which can be used by NFS in exchanging

data between client and server. For each I have included the data type code, its size in

bytes, and a name and a brief description.

Table 182: NFS External Data Representation (XDR) Data Types (Page 1 of 2)

Data Type Code

Size

(bytes)

Description

int 4

Signed Integer: A 32-bit signed integer in two's complement notation,

capable of holding a value from -2,147,483,648 to +2,147,483,647.

unsigned int 4 Unsigned Integer: A 32-bit unsigned integer, from 0 to 4,294,967,295.

enum 4

Enumeration: An alternate way of expressing a signed integer where

some of the integer values are used to stand for particular constant values.

For example, you could represent the colors of the rainbow, by defining the

value 1 to stand for “PURPLE”, 2 to stand for “BLUE” and so on.

bool 4

Boolean: A logical representation of an integer, analogous to a two-level

enumeration where a value of 0 is defined as “FALSE” and 1 is “TRUE”.

hyper 8

Signed Hyper Integer: Same as a regular signed integer, but 8 bytes wide

to allow much larger numbers.

unsigned hyper 8

Unsigned Hyper Integer: Same as a regular unsigned integer but 8 bytes

wide to allow much larger numbers.