Distributed Computing

Distributed File Systems and

Name Services
Overview
❏ Introduction and features of DFS, File models, File Accessing models,
File-Caching Schemes, File Replication.
❏ Case Study:
1. Distributed File Systems (DSF)
2. Network File System (NFS)
3. Andrew File System (AFS).
❏ Introduction to Name services & Domain Name System, Directory
Services.
❏ Case Study:
1. The Global Name Service
2. The X.500 Directory Service.
❏ Designing Distributed Systems: Google Case Study.
Introduction
A file system is sub system of an OS that performs file management activities
such as organization, storing, retrieval, naming, sharing and protection of files.

A DFS provides following three:

1. Storage services
2. True file services
3. Name services
Distributed File system
❏ A special case of distributed system
❏ Allows multi-computer systems to share files, even when no other IPC or
RPC is needed
❏ Sharing devices: Special case of sharing files
❏ Eg, NFS (Sun’s Network File System), Windows NT, 2000, XP, Andrew File
System (AFS)
❏ One of most common uses of distributed computing
❏ Goal: provide common view of centralized file system, but distributed
implementation.
1. Ability to open & update any file on any machine on network.
2. All of synchronization issues and capabilities of shared local files
DFS Architecture
❏ In general, files in a DFS can be located in “any” system. We call the
“source(s)” of files to be servers and those accessing them to be clients.
❏ Potentially, a server for a file can become a client for another file.
❏ However, most distributed systems distinguish between clients and
servers in more strict way:
1. Clients simply access files and do not have/share local files.
2. Even if clients have disks, they (disks) are used for swapping, caching,
loading the OS, etc.
3. Servers are the actual sources of files.
4. In most cases, servers are more powerful machines (in terms of CPU,
physical memory, disk bandwidth, ..)
❏ Service: software entity running on one or more machines and providing
a particular type of function to a priori unknown clients.
❏ Server: service software running on a single machine.
❏ Client: process that can invoke a service using a set of operations that
forms its client interface.
1. A client interface for a file service is formed by a set of primitive file
operations(create, delete, read, write).
2. Interface of a DFS should be transparent i.e not distinguish between local
and remote files.
Features of DFS
❏ Transparency : Structure, Access, Naming, Replication
❏ User Mobility
❏ Performance
❏ Simplicity and ease of use
❏ Scalability
❏ High availability
❏ High reliability
❏ Data Integrity
❏ Security
❏ Heterogeneity
Design issues
❏ Naming: Locating the file/directory in a DFS based on name.
❏ Location of cache: disk, main memory, both.
❏ Writing policy: Updating original data source when cache content gets
modified.
❏ Cache consistency: Modifying cache when data source gets modified.
❏ Availability: More copies of files/resources.
❏ Scalability: Ability to handle more clients/users.
❏ Semantics: Meaning of different operations (read, write,…)
Naming of distributed files
Naming – mapping between logical and physical objects.
❏ A Transparent DFS hides the location where in the network the file is
stored.
❏ Location transparency – file name does not reveal the file’s physical
storage location.
1. File name denotes a specific, hidden, set of physical disk blocks.
2. Convenient way to share data.
3. Could expose correspondence between component units and machines.
❏ Location independence – filename does not need to be changed when
the file’s physical storage location changes.
1. Better file abstraction.
2. Promotes sharing the storage space itself.
3. Separates the naming hierarchy from the storage-devices hierarchy.
Naming
❏ Name space: (e.g.,) /home/students/jack, /home/staff/jill.
❏ Namespace is a collection of names.
❏ Location transparency: file names do not indicate their physical locations.
❏ Name resolution: mapping namespace to an object/device/file/directory.
❏ Naming approaches:
❏ Simple Concatenation: add hostname to file names.
❏ Guarantees unique names.
❏ No transparency. Moving a file to another host involves a file name
change.
DFS: Three Naming Schemes
1.Mount remote directories to local directories, giving the appearance of a
coherent local directory tree
•Mounted remote directories can be accessed transparently.
•Unix/Linux with NFS; Windows with mapped drives
2.Files named by combination of host name and local name;
•Guarantees a unique system wide name
•Windows Network Places, Apollo Domain
3.Total integration of component file systems.
•A single global name structure spans all the files in the system.
•If a server is unavailable, some arbitrary set of directories on different
machines also becomes unavailable.
Mechanism of DFS
❏ Mounting: to help in combining files/directories in different systems and
form a single file system structure.
❏ Caching: to reduce the response time in bringing data from remote
machines. Modified caching
❏ Bulk data transfer: helps in reducing the delay due to transfer of files
over the network. Bulk:
● Obtain multiple number of blocks with a single seek
● Format, transfer large number of packets in a single context switch.
● Reduce the number of acknowledgements to be sent.
● (e.g) useful when downloading OS onto a diskless client.
❏ Encryption: Establish a key for encryption with the help of an
authentication server.
File Access Model : Remote File access
❏ Reduce network traffic by retaining recently accessed disk blocks in a
cache, so that repeated accesses to the same information can be handled
locally.
–If needed data not already cached, a copy of data is brought from the server
to the user.
–Accesses are performed on the cached copy.
–Files identified with one master copy residing at the server machine, but
copies of (parts of) the file are scattered in different caches.
–Cache-consistency problem keeping the cached copies consistent with the
master file.
Caching
❏ Performance of distributed file system, in terms of response time,
depends on the ability to “get” the files to the user.
❏ When files are in different servers, caching might be needed to improve
the response time.
❏ A copy of data (in files) is brought to the client (when referenced).
Subsequent data accesses are made on the client cache.
❏ Client cache can be on disk or main memory.
❏ Data cached may include future blocks that may be referenced too.
❏ Caching implies DFS needs to guarantee consistency of data.
DFS : File Caches
In client memory
❏ Performance speed up; faster access
❏ Good when local usage is transient
❏ Enables diskless workstations
On client disk
❏ Good when local usage dominates (e.g, AFS)
❏ Caches larger files
❏ Helps protect clients from server crashes
DFS : Cache update policy
❏ When does the client update the master file?
I.e. when is cached data written from the cache to the file?
❏ Write-through – write data through to disk ASAP
● I.e., following write() or put(), same as on local disks.
● Reliable, but poor performance.
❏ Delayed-write – cache and then written to the server later.
● Write operations complete quickly; some data may be overwritten in
cache, saving needless network I/O.
● Poor reliability
1. unwritten data may be lost when client machine crashes
2. Inconsistent data
● Variation – scan cache at regular intervals and flush dirty blocks.
DFS Data access
DFS - File consistency
Is locally cached copy of the data consistent with the master copy?
Client-initiated approach
❏ Client initiates a validity check with server.
❏ Server verifies local data with the master copy
❏ E.g., time stamps, etc.
Server-initiated approach
❏ Server records (parts of) files cached in each client.
❏ When server detects a potential inconsistency, it reacts
When should a modified source content be transferred to the cache?
Server-initiated policy:
❏ Server cache manager informs client cache managers that can then
retrieve the data.
Client-initiated policy:
❏ Client cache manager checks the freshness of data before delivering to
users. Overhead for every data access.
❏ Concurrent-write sharing policy:
❏ Multiple clients open the file, at least one client is writing.
❏ File server asks other clients to purge/remove the cached data for the file,
to maintain consistency.
 Sequential-write sharing policy: a client opens a file that was
recently closed after writing.
1. This client may have outdated cache blocks of the file (since the other
client might have modified the file contents).
❏ Use time stamps for both cache and files. Compare the time stamps to
know the freshness of blocks.
2. The other client (which was writing previously) may still have modified
data in its cache that has not yet been updated on server.(e.g.,) due to
delayed writing.
❏ Server can force the previous client to flush its cache whenever a new
client opens the file.
DFS - Remote Service vs Caching
Remote Service – all file actions implemented by server.
❏ RPC functions
❏ Use for small memory diskless machines
❏ Particularly applicable if large amount of write activity
Cached System
❏ Many “remote” accesses handled efficiently by the local cache
❏ Most served as fast as local ones.
❏ Servers contacted only occasionally
❏ Reduces server load and network traffic.
❏ Enhances potential for scalability.
❏ Reduces total network overhead
DFS - File Server semantics
Stateless Service
❏ Avoids state information in server by making each request self-contained.
❏ Each request identifies the file and position in the file.
❏ No need to establish and terminate a connection by open and close
operations.
❏ Poor support for locking or synchronization among concurrent accesses
Stateful Service
❏ Client opens a file (as in Unix & Windows).
❏ Server fetches information about file from disk, stores in server memory,
1. Returns to client a connection identifier unique to client and open file.
2. Identifier used for subsequent accesses until session ends.
❏ Server must reclaim space used by no longer active clients.
❏ Increased performance; fewer disk accesses.
❏ Server retains knowledge about file
E.g, read ahead next blocks for sequential access.
E.g, file locking for managing writes, Windows
DFS - Server Semantics comparison
Failure Recovery: Stateful server loses all volatile state in a crash.
1. Restore state by recovery protocol based on a dialog with clients.
2. Server needs to be aware of crashed client processes
orphan detection and elimination.
Failure Recovery: Stateless server failure and recovery are almost unnoticeable.
1. Newly restarted server responds to self-contained requests without difficulty.
Penalties for using the robust stateless service:
1. longer request messages
2. slower request processing
Some environments require stateful service.
1. Server-initiated cache validation cannot provide stateless service.
2. File locking (one writer, many readers).
DFS - Replication
❏ Replicas of the same file reside on failure-independent machines.
❏ Improves availability and can shorten service time.
❏ Naming scheme maps a replicated file name to a particular replica.
1. Existence of replicas should be invisible to higher levels.
2. Replicas must be distinguished from one another by different lower-level
names.
❏ Updates
1. Replicas of a file denote the same logical entity.
2. Update to any replica must be reflected on all other replicas.
DFS - Case Studies
NFS (Network File System)
❏ Developed by Sun Microsystems (in 1985)
❏ Most popular, open, and widely used.
❏ NFS protocol standardised through IETF (RFC 1813)
AFS (Andrew File System)
❏ Developed by Carnegie Mellon University as part of Andrew distributed
computing environments (in 1986)
❏ A research project to create campus wide file system.
❏ Public domain implementation is available on Linux (LinuxAFS)
❏ It was adopted as a basis for the DCE/DFS file system in the Open
Software Foundation (OSF, www.opengroup.org) DCE (Distributed
Computing Environment)
Fundamentals
❏ NFS was developed to allow a machine to mount a disk partition on a
remote machine as if it were local.
❏ This allows for fast, seamless sharing of file across network.
❏ There is no global naming hierarchy.
❏ NFS allows any machine to be client or server.

NFS Protocols:

❏ Mount Protocol
❏ File Access Protocol
❏ Their functionality is defined as a set of Remote Procedure Calls (RPC).
NFS
❏ NFS developed by SUN Microsystems for use on its UNIX-based
workstations.
❏ A distributed file system which allows users to access files and directories
located on remote computers but, data potentially stored on another
machine.
❏ NFS builds on the Open Network Computing Remote Procedure Call (ONC
RPC) system.
❏ Mechanism for storing files on a network. Allows users to ‘Share’ a
directory.
❏ NFS most commonly used with UNIX systems. Other software platforms:
-Mac OS, Microsoft Windows, Novell NetWare, etc.
❏ NFS runs over LAN, even WAN (slowly)
❏ Any system may be both a client and server
❏ Basic idea:
1. Remote directory is mounted onto local directory.
2. Remote directory may contain mounted directories within.
Version 1 and Version 2
❏ Sun used only for in-house experimental purposes
❏ Did not release it to the public
❏ V2 of the protocol originally operated entirely over UDP and was meant to
keep the protocol stateless, with locking (for example) implemented
outside of the core protocol.
❏ Both suffered from performance problems Both suffered from security
problems (security dependant upon IP address).
Version 3
❏ NFS v3 can operate across TCP as well as UDP Support for asynchronous
writes on the server
❏ Obtains multiple file name, handles and attributes Support for 64-bit file
sizes and offsets
Handle files larger than 4 gigabytes (GB) Improves performance, and allowed
it to work more reliably across the Internet.

Version 4

❏ Currently version 2 and version 3 protocols are in use with version 4

under consideration for a standard
❏ includes more performance improvements
❏ Mandates strong security introduces a stateful protocol developed with
the IETF (Internet Engineering Task Force)
Mounting remote directories
Nested mounting
NFS implementation
NFS operations
Lookup
❏ Fundamental NFS operation
❏ Takes pathname, returns file handle
File Handle
❏ Unique identifier of file within server
❏ Persistent; never reused
❏ Storable, but opaque to client: 64 bytes in NFS v3; 128 bytes in NFS v4
Most other operations take file handle as argument
Other NFS operations
❏ read, write
❏ link, symlink
❏ mknod, mkdir
❏ rename, rmdir
❏ readdir, readlink
❏ getattr, setattr
❏ create, remove
NFS Version 3 - Stateless service
❏ Server retains no knowledge of client : Server crashes invisible to client
❏ The server simply delivers all the information that is required to service a
client request.
❏ If a server crash happens, the client would simply have to retry the
request. Because of their simplicity, NFS implements a stateless protocol.
❏ Every operation provides file handle
❏ Server caching
1. Performance only
2. Based on recent usage
❏ Client caching
1. Client checks validity of caches files
2. Client responsible for writing out caches
❏ No locking, No synchronization.
❏ Unix file semantics not guaranteed. E.g., read after write
❏ Session semantics not even guaranteed. E.g., open after close

Solution :
❏ Global lock manager: Separate from NFS
❏ Typical locking operations
•Lock – acquire lock (non-blocking)
•Lockt – test a lock
•Locku – unlock a lock
•Renew – renew lease on a lock
NFS implementation
❏ Remote procedure calls for all operations:
1. Implemented in Sun ONC.
2. XDR is interface definition language.
❏ Network communication is client-initiated:
1. RPC based on UDP (non-reliable protocol).
2. Response to remote procedure call is de facto acknowledgement.
❏ Lost requests are simply re-transmitted:
1. As many times as necessary to get a response.
NFS Caching
❏ On client open(), client asks server if its cached attribute blocks are up to
date.
❏ Once file is open, different client processes can write it and get
inconsistent data.
❏ Modified data is flushed back to the server every 30 seconds.
NFS Failure Recovery
Server crashes are transparent to client
❏ Each client request contains all information
❏ Server can re-fetch from disk if not in its caches
❏ Client retransmits request if interrupted by crash (i.e., no response)

Client crashes are transparent to server

❏ Server maintains no record of which client(s) have cached files.
NFS version 4
❏ Stateful file service
❏ Based on TCP - reliable transport protocol
❏ More ways to access server
❏ Compound requests : i.e multiple RPC calls in same packet
❏ More emphasis on security
❏ Mount protocol integrated with reset of NFS protocol.
❏ Additional RPC operations : Long list of managing files, caches, validating
versions etc
Andrew File System (AFS)
❏ Design objectives :
1. Highly scalable
2. Secure
❏ Andrew distinguishes between client machines (workstations) and
dedicated server machines. Servers and clients run the 4.2BSD UNIX OS
and are interconnected by an internet of LANs.
❏ Dedicated servers, called Vice, present the shared namespace to the
clients as an homogeneous, identical, and location transparent file
hierarchy.
❏ Clients are presented with a partitioned space of file names: a local
namespace and a shared namespace.
❏ The local name space is the root file system of a workstation, from which
the shared namespace descends.
❏ Workstations run the Virtue protocol to communicate with Vice, and are
required to have local disks where they store their local name space.
❏ Clients and servers are structured in clusters interconnected by a
backbone LAN.
❏ A cluster consists of a collection of workstations and a cluster server and
is connected to the backbone by a router.
❏ Servers collectively are responsible for the storage and management of
the shared namespace.
❏ A key mechanism selected for remote file operations is whole file caching.
Opening a file causes it to be cached, in its entirety, on the local disk.
AFS shared namespace
❏ Andrew’s volumes are small component units associated with the files
of a single client.
❏ A fid identifies a Vice file or directory. A fid is 96 bits long and has
three equal-length components:
1. volume number
2. vnode number – index into an array containing the inodes of files in a
single volume.
3. uniquifier – allows reuse of vnode numbers, thereby keeping certain
data structures, compact.
❏ Fids are location transparent; therefore, file movements from server
to server do not invalidate cached directory contents.
❏ Location information is kept on a volume basis, and the information
is replicated on each server.
AFS file operations
❏ Andrew caches entire files from servers. A client workstation interacts
with Vice servers only during opening and closing of files.
❏ Venus – caches files from Vice when they are opened, and stores modified
copies of files back when they are closed.
❏ Reading and writing bytes of a file are done by the kernel without Venus
intervention on the cached copy.
❏ Venus caches contents of directories and symbolic links, for path-name
translation.
❏ Exceptions to the caching policy are modifications to directories that are
made directly on the server responsibility for that directory.
AFS implementation
❏ Client processes are interfaced to a UNIX kernel with the usual set of
system calls.
❏ Venus carries out path-name translation component by component.
❏ The UNIX file system is used as a low-level storage system for both
servers and clients. The client cache is a local directory on the
workstation’s disk.
❏ Both Venus and server processes access UNIX files directly by their inodes
to avoid the expensive path name-to-inode translation routine.
❏ Venus manages two separate caches:
1. one for status
2. one for data
❏ LRU algorithm used to keep each of them bounded in size.
❏ The status cache is kept in virtual memory to allow rapid servicing of stat
(file status returning) system calls.
❏ The data cache is resident on the local disk, but the UNIX I/O buffering
mechanism does some caching of the disk blocks in memory that are
transparent to Venus.
Role of names
❏ Resources are accessed using identifier or reference
– An identifier can be stored in variables and retrieved from tables quickly
– Identifier includes or can be transformed to an address for an object . E.g. NFS file
handle, Corba remote object reference
– A name is human-readable value (usually a string) that can be resolved to an
identifier or address : Internet domain name, file pathname, process number
E.g ./etc/passwd, http://www.cdk3.net/ y
❏ For many purposes, names are preferable to identifiers
– because the binding of the named resource to a physical location is deferred and
can be changed
– because they are more meaningful to users
Resolving and binding names
❏ A name is resolved when it is translated into data about the named
resource or object – often in order to invoke an action upon it
❏ The association between a name and an object is called a binding
1. In general, names are bound to attributes of the named objects
2. An attribute is the value of a property associated with an object
3. E.g., DNS maps domain names to the attributes of a host computer: its IP
address
Composed naming domains used to access a resource
using a URL
Name and resources
Name Services
❏ A name service stores a collection of one or more naming contexts – sets
of bindings between textual names and attributes for objects such as
users, computers, services and remote objects.
❏ The major operation is to resolve a name – that is, to look up attributes
from a given name
❏ General requirements for name services
1. To handle an essentially arbitrary number of names and to serve an
arbitrary number of administrative organizations
2. High availability
Namespace
❏ A name space is the collection of all valid names recognized by a particular
service
❏ Allow simple but meaningful names to be used
❏ Potentially infinite number of names
❏ Structured – to allow same subnames without clashes – to group related names
❏ Aliases: one domain name is defined to stand for another – http://espn.go.com/
and http://www.espn.com
❏ Naming domains: is a namespace for which there exists a single overall
administrative authority for assigning names within it
1. Domains in DNS are collections of domain names; syntactically, a domain’s
name is the common suffix of the domain names within it
2. The administration of domains may be devolved to sub-domains
Name Resolution: iterative navigation
❏ The partitioning of data implies that the local name server cannot answer
all enquiries without the help of other name servers
❏ The process of locating naming data from among more than one name
server in order to resolve a name is called navigation
❏ DNS supports the model known as iterative navigation: to resolve a name,
a client presents entire name to servers, starting at a local server, NS1. If
NS1 has the requested name, it is resolved, else NS1 suggests contacting
NS2 (a server for a domain that includes the requested name)
Non recursive and recursive server-controlled navigation

❏ An alternative model that DNS supports: a name server coordinates the

resolution of the name and passes the result back to the user agent
1. Non-recursive server-controlled: any name server may be chosen by the
client.
2. Recursive server-controlled: the client contacts a single server
❏ Recursive navigation must be used in domains that limit client access to
their DNS information for security reasons
DNS - The Domain Name System
❏ DNS is a name service design whose main naming database is used
across the Internet: Derived in 1987 to replace the original Internet
naming scheme, in which all host names and addresses were held in a
single central master file and downloaded by FTP to all computers that
required them
❏ Major shortcomings of old scheme:
1. Did not scale
2. Local organizations wished to administer their own naming systems
3. A general name service was needed, not one that serves only for looking
up computer addresses
❏ Name structure reflects administrative structure of the Internet
❏ Rapidly resolves domain names to IP addresses
1. Exploits caching heavily
2. Typical query time ~100 milliseconds
❏ Scales to millions of computers
1. partitioned database
2. caching
❏ Resilient to failure of a server – replication
Domain names
❏ The internet DNS name space is partitioned both organizationally and according
to geography
❏ The names are written with the highest-level domain on the right
❏ The original top-level organizational domains (also called generic domains):
1. com: commercial organizations
2. edu: universities and other educational institutions
3. gov: US governmental agencies
4. mil:US military organizations
5. net: major network support centers
6. org: organizations not mentioned above
7. int: international organizations
DNS queries
❏ Main function is to resolve domain names for computers, i.e. to get their
IP addresses – caches the results of previous searches until they pass
their 'time to live
❏ Other functions:
1. get mail host for a domain
2. reverse resolution
3. get domain name from IP address
4. Host information - type of hardware and OS
5. Well-known services - a list of well-known services offered by a host
6. Other attributes can be included (optional): in principle, the DNS can be
used to store arbitrary attributes
DNS name servers
Basic DNS algorithm for name resolution
Basic DNS algorithm for name resolution

(domain name -> IP number)

1. Look for the name in the local cache

2. Try a superior DNS server, which responds with:
● another recommended DNS server
● the IP address (which may not be entirely up to date)
DNS in typical operation
DNS resource records
Directory services

“A service that stores collections of bindings between names and attributes,

and looks up entries that match attribute based specifications (e.g.,
Microsoft's Active Directory Service, X.500 and LDAP).”
X.500: Case Study
❏ X.500 is a directory service primarily used to satisfy descriptive queries,
discovering names and attributes of other users or system resources.
❏ White Pages Service: obtaining a specific translation.Eg, what is such and
such a user's email address.
❏ Yellow Pages Service: obtaining grouped information.Eg, list all garages
that can repair my Ferrari.
❏ Such queries may originate from users or from processes.
❏ Users can search the directory for specific information with only partial
knowledge of its name, structure or content.
X.500 Directory Service
❏ The ITU and ISO defined the X.500 standard as part of the ISO OSI seven
layer model.
❏ X.500 is designed to be a service for access to information about “real
world entities".
❏ It is specified as an application level service within OSI, and can be viewed
as a design for a general purpose directory service.
❏ It is the basis for LDAP and is used in the OSF's DCE directory service
technology.
X.500 Namespace
❏ Organized as a tree structure
❏ A wide range of attributes are stored at each node in the tree
❏ Access is not just by name but also by searching for entities with any
required combination of attributes
DIT and DIB
❏ The X.500 tree is called the Directory Information Tree (DIT).
❏ The tree and its associated data is called the Directory Information Base
(DIB).
❏ There is intended to be a global DIB with portions of the worldwide DIB
managed by individual X.500 servers.
❏ Each entry in the DIB consists of a name and a set of attributes.
Clients and X.500
❏ Clients access the directory by establishing a connection to a server.
❏ If the data required are not in the segment of the DIB held by the
contacted server, it will invoke other servers to resolve the query or
redirect the client to another server.
❏ In the terminology of the X.500 standard, servers are Directory Service
Agents (DSAs), and their clients are termed Directory User Agents (DUAs).
❏ Each entry in the DIB consists of a name and a set of attributes. As in
other name servers, the full name of an entry corresponds to a path
through the DIT from the root of the tree to the entry.
❏ In addition to full or absolute names, a DUA can establish a context, which
includes a base node, and then use shorter relative names that give the
path from the base node to the named entry.
X.500 Service Architecture
Part of the X.500 DIT
❏ The data structure for the entries in the DIB and the DIT is very flexible.
❏ A DIB entry consists of a set of attributes, where an attribute has a type
and one or more values. The type of each attribute is denoted by a type
name (for example, countryName, organizationName, commonName,
telephoneNumber, mailbox, objectClass).
❏ New attribute types can be defined if they are required. For each distinct
type name there is a corresponding type definition, which includes a type
description and a syntax definition in the ASN.1 notation (a standard
notation for syntax definitions) defining representations for all
permissible values of the type.
❏ DIB entries are classified in a manner similar to the object class structures
found in object-oriented programming languages
❏ Each entry includes an objectClass attribute, which determines the class
(or classes) of the object to which an entry refers.
❏ Organization, organizationalPerson and document are all examples of
objectClass values. Further classes can be defined as they are required.
❏ The definition of a class determines which attributes are mandatory and
which are optional for entries of the given class.
❏ The definitions of classes are organized in an inheritance hierarchy in
which all classes except one (called topClass) must contain an objectClass
attribute, and the value of the objectClass attribute must be the names of
one or more classes.
❏ If there are several objectClass values, the object inherits the mandatory
and optional attributes of each of the classes.
Administration and updating of the DIB: The DSA interface includes
operations for adding, deleting and modifying entries. Access control is
provided for both queries and updating operations, so access to parts of the
DIT may be restricted to certain users or classes of user
Lightweight Directory Access Protocol: X.500’s assumption that
organizations would provide information about themselves in public
directories within a common system has proved largely unfounded. group at
the University of Michigan proposed a more lightweight approach called the
Lightweight Directory Access Protocol (LDAP), in which a DUA accesses X.500
directory services directly over TCP/IP instead of the upper layers of the ISO
protocol stack.
An example X.500 DIB Entry
Implementing X.500
❏ As a standard (recommendation), X.500 does not address implementation
issues.
❏ It should be clear that any implementation must involve multiple servers
organized as a WAN, with extensive use made of replication and caching.
X.500 and LDAP
❏ University of Michigan proposed the Lightweight Directory Access
Protocol (LDAP) in which DUAs access X.500 servers directory over TCP/IP
(as opposed to an application level OSI protocol).
❏ LDAP is defined in RFC 2251, and provides a simple API for directory
access and does away with X.500's requirement to use ASN.1 as the
default textual encoding.
❏ LDAP is based on X.500 but does NOT require it.
❏ LDAP is widely used, for example, Microsoft's ADS provides an LDAP
interface.
❏ LDAP is particularly used for organizational intranet directory services