Name Service Doc

8/3/2019 Name Service Doc

1/25

Distributed Name Services

Cheng Peng 3022918

Peng Fu 3086289

Ming Xie 2776847

1. Introduction

In a distributed system, names are used to refer to a wide variety of resources such as

computers, services, remote objects and files, as well as to users. Naming is an issue that

is easily overlooked but is nonetheless fundamental in distributed system design. Names

facilitate communication and resource sharing. A name is needed to request a computersystem to act upon a specific resource chosen out of many; for example, a name in the

form of a URL is needed to access a specific web page. Processes cannot share particular

resources managed by a computer system unless they can name them consistently. Users

cannot communicate with one another via a distributed system unless they can name oneanother, for example with email addresses.

Names are not the only useful means of identification: descriptive attributes are another.

Sometimes clients do not know the name of the particular entity that they seek, but theydo have some information that describes it. Or the client requires a service (rather than a

particular entity that implements it) and knows some of the characteristics that the

required service must have.

This introduces name services, which provide clients with data about named objects in

distributed systems; and the related concepts of directory and discovery services, which

provide data about objects the satisfy a given description. We describe approaches to betaken in the design and implementation of these services, using the Domain Name

Service (DNS), GNS and X500 as case studies. We begin by examining the fundamental

concepts of names and attributes.

1.1 Names, Addresses and other Attributes

1.1.1 Names

A process uses a name or an identifier visiting a definite resource. The identifier issometimes used to refer to names that are interpreted only by programs, chosen for

looking up and storing the objects by software efficiently. It is a form of names. And we

also can divide names into two types. One is Pure Names, used in simply un-interpretedbit patterns, the other one is Non-Pure Names which contain information about the object

that they name; in particular, they may contain information about the location of the

object.


2/25

1.1.2 Addresses

Lets take a look again on the pure names. When we use it, we have to look it up firstly.In some aspects, it is inefficient. We may use Objects Address to improve it. The

objects address is a value that identifies the location of the object rather than the object

itself. But sometimes it is not adequate, when the objects relocated.

1.1.3 Attributes

In order to implement a process upon a named resource or object, firstly, it is needed to

translate its name into data that can be looked up. It is called resolving. On the contrary, aname and an object associated are called binding. In fact, the name is not associated with

the object itself, but bound to the attributes of the named object. Then, what is an

attribute? An attribute is the value of a property associated with an object. A key attribute

of an entity that is usually relevant in a distributed system is its address, which can beconsidered as another name that must be looked up, or it may contain such a name.

Here is an example of composed naming domains used to access a resource from a URL.

In this example, we can see, firstly, the domain name portion in the URL is translated

into IP address via DNS resolvation and then use the ARP to find out an Ethernet addressfor the web server. The last portion is translated into proper address that can find the

relevant file by the help of file system.

2. Name services and the Domain Name System

2.1 Name Service

We have mentioned bindings before which are the associations between textual namesand attributes for objects, for example, computers, services, users, and remote objects. A

http://www.cdk3.net:8888/WebExamples/earth.html

URL

Resource ID (IP number, port number,

Network address

2:60:8c:2:b0:5 file

55.55.55.55 WebExamples/earth.html8888

DNS lookup

Socke

Web server


3/25

name service is a collection of the sets of this kind of bindings naming contexts. The

major function of a name service is to look up attributes form a given name name

resolution, and other aspects related to the bindings.

One service that is needed to be picking up from others is Name Management, which has

two motivations. One is Unification that it is convenient for resources managed by

different services to use the same naming scheme. The other is Integration that it isconvenient to integrate service for sharing information by a common naming service.

Name service is a simple technology used for single machine or in a small network.

When put it in the interconnected networks area, the problem comes out that is a muchlarger name-mapping problem. With the invention of multi-domain name services and the

development of the Global Name Service, it needs to some requirement of handling an

essentially arbitrary number of names and to serve an arbitrary number of administrative

organizations; a long lifetime; high availability; fault isolation function; and tolerance ofmistrust. A good example is the Internet Domain Name System is less ambitious in the

number of objects it is designed for, but it continues to be widespread use. We willdiscuss it later.

2.1.1 Name space

A Name Space is the collection of all valid names recognized by a particular service.

What kind of name is valid? A name can be looked up by the service, even though that

name may prove not to correspond to any object to be unbound. Name space requires a

syntactic definition. For example, is not acceptable as the DNS name of a computer.

In the windows, files are arranged in a tree structure. Meanwhile, names may have an

internal structure that represents their position in a hierarchic name space, or in an

organizational hierarchy, as is the case for Internet domain names; or they may be chosen

from a flat set of numeric or symbolic identifiers. And in the windows operation systemswe can easily find a file because in the hierarchic name spaces, each part of a name is

resolved relative to a separate context, and same name may be used with different

meanings in different contexts. In the case of file systems, each directory represents a

context. And different people can manage different contexts.

2.1.2 Naming domains

A naming domain is a name space for which there exists a single overall administrative

authority for assigning names within it. This authority is in overall control of whichnames may be bound within the domain. In particular, domains in DNS are collections of

domain names; syntactically, a domains name is the common suffix of the domain

names within it, but it may not be distinguished from a computer name. Whats more, theadministration of domains may be devolved to sub-domains. Responsibility for a naming

domain normally goes hand in hand with responsibility for managing and keeping up to

date the corresponding part of the database stored in an authoritative name server and


4/25

used by the name service. Naming data belonging to different naming domains are in

general stored by distinct name servers managed by the corresponding authorities.

2.1.3 Combining and customizing name spaces

DNS provides a global and homogeneous name space in which a given name refers to the

same entity, no matter which process on which computer looks up the name. By contrast,some name services allow distinct name spaces sometimes heterogeneous name spaces

to be embedded into them; and some name services allow the name space to be

customized to suit the needs of individual groups, users or even processes.

Merging: A part of one name space is conveniently embedded in another.Although we can always merge name spaces by creating a higher-level root

context, here comes a problem of compatibility. We need to hybrid name spaces

and the inconvenience of having to translate old names between the users of thecomputers.

Heterogeneity: The Distributed Computing Environment name space allowsheterogeneous name spaces to be embedded within it. DCE names may contain

junctions. This kind of name is be made up by a cell and a junction under thejunctions principals.

Customization: uses can construct their name spaces independently rather than

sharing a single name space, or when the same name is made to refer to differentfiles on different computers. Sometimes people want to make a name space just

for his or her self. Here a good example is the spring naming service.

2.1.4 Name resolution

While IP is designed to work with the 32-bit IP addresses of the source and the

destination hosts, people who are not very good at using and remembering the IPaddresses of the computers with which they wish to communicate use computers. It is

much better at using and remembering names than IP addresses. If a name is used as analias for the IP address, there must exist a mechanism for assigning names to IP nodes to

ensure its uniqueness and resolving a name to its IP address.

The Name Resolution is an iterative process whereby a name is repeatedly presented tonaming contexts. A naming context either maps a given name onto a set of primitive

attributes directly, or a further naming context, and a derived name to be presented to thatcontext. It can also implement on the aliases.

2.2 Name Servers and Navigation

In any name services, there is a very large database supported in the backend, no matter

how big its storage capability is, it still cannot contain all the naming information that

required by the large population users. Such a server would be a bottleneck and a critical

point of failure. To solve this problem we should use replication to achieve highavailability. As far as the DNS is concerned, each subset of DNS database is replicated in


5/25

at least two failure-independent servers. The process of locating naming data from among

more than one name server in order to resolve a name is called navigation. Here we

introduce some categories of navigation.

Iterative Navigation

In this mode, a client presents the name to the local name server, which attempts to

resolve it. If the local name server has the name, it returns the result immediately. If it

does not, it will suggest another server that will be able to help. Resolution proceeds atthe new server, with further navigation as necessary until the name is located or

discovered to be bound.

Multicast Navigation: A client multicast the name to be resolved and the required

object type to the group of name servers. Only the server that holds the namedattributes responds to the request. If the name proves to be unbound, then the

request is greeted with silence.

Non-recursive Server-control Navigation: The client may choose any name server

and this server communicates multicast or iteratively with its peers we havemention the above.

Client 1

2

3

A client iteratively contacts name servers NS1NS3 in order to resolve a

NS2

NS1

NS3

Name

Servers


6/25

Recursive Server-control Navigation: The client once more contacts a single. If itdoes not store the name, the server contacts a peer storing a prefix of the name,

which in turn attempts to resolve it. This procedure continues recursively until the

name is resolved.

2.3 The Domain Name System

With the development of computer technology and networking technology, more and

more organization and individuals are involved in the information technologies. One ofthe conveniences of information technology is that it often remains complex interactions

under the cover of a simple human performance. Here is a good example -- the Internet.

Everyday, millions of users move from Web site to Web site by simply typing domain

names into a computer's Internet browser. But normally users cannot know that eachentry actually triggers a critical, time-sensitive process before the Web site can be

accessed.

In order for Internet users to reach a Web site, their computer must find the address of the

Web server that hosts the desired site. Each Web site on the Internet there is a unique

domain name and numeric address, known as an IP address. This number, while quiteconvenient for the computer to use, is difficult for Internet users to remember; thus the

need for domain names. The Domain Name System (DNS) is used to convert domain

names into IP addresses. Each time a user enters a domain name into a computer'sbrowser, a process translates the user-friendly name into the computer friendly IP address

needed to locate the appropriate Web server. Hierarchical partitioning of the name

database, and replication of the naming data, and cashing achieve this.

2.3.1 Domain Names

The Domain Name System is a distributed hierarchical system for resolving host names

into IP addresses. The DNS has a root domain at the top of the hierarchy and directly

1

2

3

5

1

2

34

4

A name server NS1 communicates with other name servers on behalf of a client

client client

Recursiveserver-controlled

NS2

NS1

NS3

NS2

NS1

NS3

Non-recursive

server-controlled


7/25

under are the top-level domains. The root of the tree has no name. All siblings of a

domain must have unique names. Children of a domain are called sub-domains of the

parent.

ROOT

COM EDU GOV MIL NET ORG INT US ARPA

The information is distributed among thousands of name servers. The root name servers

only have complete information about the top-level domains. No servers have completeinformation about all domains, but the root name servers have pointers to the servers for

the second level domains. This gives them complete access to the information about all

domains by querying its list of name servers.

Descriptions of each main top-level domain that divide up the Internet Name Space are:

COM: Any commercial, for-profit business may register in the COM domain.

This is the most common type of domain being registered today.

EDU: Originally, the EDU domain was designed to be the top-level domain for alleducational institutions.

GOV: This top-level domain is reserved for certain Federal Government Agencies

and only under specific circumstances.

MIL: Any department or agency of the US military may register a name in theMIL domain.

NET: The NET domain is intended to hold only the computers of network

providers. The appropriate entity for a NET domain is an Internet ServiceProvider or an administrative organization providing Internet support functions.

ORG: The ORG domain is for non-profit organizations and other organizationsthat did not fit anywhere else. Currently, registering in the ORG domain is

restricted to only non-profit organizations.

INT: The INT domain is used only for registering organizations established by

international treaties between governments or Internet infrastructure databases.

US: This is the top-level country domain for the United States. The US Domain

currently registers hosts of businesses, individuals, federal government agencies,state government agencies, K12 schools, community colleges,

technical/vocational schools, private schools, libraries, museums, city and countygovernment agencies.

ARPA: This was originally used during the ARPANET's transition from hosttables to DNS. All ARPANET hosts originally had host names under "arpa" so

they were easy to find. Later, they moved into various sub-domains of the

organizational top-level domains.

2.3.2 DNS Queries

The Internet DNS is primarily used for simple host name resolution and for looking up

electronic mail hosts.


8/25

Host Name Resolution: Applications use the DNS to resolve host names into IPaddresses.

Mail Host Location: Electronic mail software uses the DNS to resolve domain

names into the IP addresses of mail hosts computers that will accept mail forthose domains.

Reverse Resolution: Some software requires a domain name to be returned givenan IP address.

Host Information: The DNS can store the machine architecture type and operatingsystem against the domain names of hosts.

Well-known Services: A list of the services run by a computer and the protocol

used to obtain them can be returned, given the computers domain name, provided

that the name server supports this information.

The DNS can be used to store arbitrary attributes. A query is specified by a domain name,class and type.

2.3.3 Navigation and Query Processing

A DNS is called a resolver. Resolver is the client that access name server. Programsrunning on a host that need information from the domain namespace use the resolver to

deal with querying a name server, interpreting responses, and returning the information to

the programs that requested it.

The DNS architecture allows for recursive navigation and iterative navigation. The

resolver specifies which type navigation is required when contacting a name server.However name servers are not bound to implement recursive navigation. Recursive

navigation may tie up server threads, meaning that other requests might be delayed.

Therefore, DNS allows multiple queries to be packed into the same request message andfor name servers correspondingly to send multiple replies in their response messages.

2.3.4 The BIND implementation of the DNS

The standardized format for the resource data associated with a particular host name is

known as a resource record. DNS specifies the format of a resource record as it is passed

across the network. DNS does not specify the format of a resource record in the system

administrators local file system.

A common misconception about DNS is that the resource record formats and files that

are associated with the DNS server, Berkeley Internet Name Domain (BIND) actually

form part of the DNS protocol. This is due to the fact that BIND is the most common

implementation of DNS servers that is used on Internet hosts. Even though the BINDformat is based upon the original format that was centrally administered and then

distributed about the Internet prior to DNS, it is not specifically part of any DNS

standardized protocol. The Bind format is also used in the DNS standard as the textual


9/25

expression of resource records. DNS servers do not necessarily use this as their storage

format.

BIND is an implementation of the Domain Name System (DNS) protocols and provides

an openly re-distributable reference implementation of the major components of the

Domain Name System, including: a Domain Name System server (named); a Domain

Name System resolver library; and tools for verifying the proper operation of the DNSserver. The BIND DNS Server is used on the vast majority of name serving machines on

the Internet, providing a robust and stable architecture on top of which an organization's

naming architecture can be built. The resolver library included in the BIND distribution

provides the standard APIs for translation between domain names and Internet addressesand is intended to be linked with applications requiring name service.

2.6 Discussion of the DNS

Under the amount of naming data and scale of the networks, The DNS implementation

achieves relatively short average response times for lookups by a combination ofpartitioning, replicating and caching naming data. The objects named are primarily

computer, name servers and mail hosts. Since the host name mapping IP address changes

not frequently, as well as the identities of name servers and mail hosts, cashing and

replication occur in a relatively clement condition. If naming data changes servers mayprovide clients with old data for periods in the order of days. This is the inconsistency of

naming data, and it is of no consequence until such time as a client attempts to use old

data. The DNS does not address itself to how staleness of addresses is detected.

General speaking, the DNS stores a limited variety of naming data, but this is sufficient.The DNS database represents the lowest common denominator of what would be

considered useful by the many user communities. In the Internet, DNS is not the only

name service. There are local name and directory services that store data most pertinent

to local needs as well. Since the rigidity with respect to changes in the structure of thename space, and the lack of ability to customize the name space to suit local need, the

DNS deal with this problem. And we will discuss the GNS for example later.

3. Directory and discovery services

3.1 directory servicesDistributed processing involves the interaction of multiple systems to do work that is

done on one system in a traditional computing environment. One challenge resultingfrom this network-wide working environment is the need for a universally consistent way

to identify and locate people and resources anywhere in the network.

The Directory Service makes it possible to contact people and to use resources such asdisks, print queues, and servers anywhere in the network without knowing their physical

location. The Directory Service is much like a telephone directory assistance service that

provides a phone number when given a person's name. The Directory Service, given theunique name of a person, server, or resource, can return the network address and other


10/25

information associated with that name. The Directory Service stores addresses and other

relevant information as attributes of the name.

Attributes are more powerful than names as designators of objects: programs can bewritten to select objects according to precise attribute specifications where names might

not be known. Whats more, we need not to expose the structure of organizations to

outside world, as do organizationally partitioned names. However, the relative simplicity

of use of textual names makes them unlikely to be substituted by attribute based namingin many applications. X.500 is a typical example of directory service usage, and we will

discuss it latterly.

3.2 Discovery Services

A discovery service is a directory service that registers the services provided in

spontaneous networking environment. Distributed systems are very dynamic and keep

changing ceaselessly. Various components are loaded and unloaded as the necessitieskeep changing. The dynamism of such systems is further increased by component crashes,

which are inevitable in any distributed system. In such systems, it is necessary to keeptrack of components currently active. The Discovery service tracks software components

as well as persons present in an active apace. Information about currently active

components is required for diagnostics and self-healing activities that stabilize the

system by handling component failures. Information about persons present in an activeapace is required for setting user preferences and many other functions. The Discovery

service is a service that keeps track of entities present in an active apace at any time.

These entities can be services, devices and even persons. Presence and Informer services

are the two major components of Discovery service. An active apace can have a lot of

services and devices running in it at the same time.

Component failures are inevitable in any system and have to be tracked. For this reason,

the Presence service keeps track of which entities are currently running in an active space.

All service and device entities send heartbeats at regular intervals, to show that they areup and running. The presence service listens to and filters these heartbeats to know which

entities are currently running in the active space. Whenever a new entity is discovered,

presence sends a message announcing the starting of the new entity. When an existing

entity stops sending heartbeats, presence service sends a message announcing that the

entity has stopped. Thus, component crashes can be detected and action can be taken toheal the system.

While presence service keeps track of service and device entities in an active space,

Informer service keeps track of the persons present in an active space. Persons in anactive space are detected by devices. All such sensing devices send periodic updates of

which persons have been detected in the room. The Informer service listens to and filters

these information packets to know who is present in the active space. Informer servicesends messages when persons enter or exit an active space. These messages can be used

by other services that set the user preferences or space sharing attributes.


11/25

Resent developments in this area include the Jini discovery service, the service location

protocol, the intentional naming system, the simple service discovery protocol, which is

at the heart of the universal plug and play initiative and the secure service discoveryservice.

4. Global Name Service (GNS)

4.1 Overview

A name service maps a name for an entity (an individual, organization, or facility) into a

set of labeled properties, each of which is a string. The global name service (GNS)

accomplishes name services for billions of names distributed throughout the world. Itaddresses the problems of high availability, large size, continuing evolution, fault

isolation and lack of global trust.

A Global Name Service (GNS) is designed and implemented to provide facilities forresource location, mail addressing, and authentication in a distributed computing system.

GNS can be used in an inter-network to support a naming database that may extend to

include the names of millions of computers and eventually email addressed for billions of

users. GNS also supports that the naming database is likely to have a long lifetime, that itmust continue to operate effectively while it grows from small to large scale and while

the network on which it is based evolves.

The design objectives for GNS are as following:

Large size, to handle an essentially arbitrary number of names and serve an arbitrary

number of administrative organizations.

Long life, during which many changes will occur in the organization of the name

space and the component that implement the service.

High availability, because the system cant work when the name service is broken.

Fault isolation, so that local failures dont cause the entire service to fail.

Tolerance of mistrust, since a large-scale service wont have any component which istrusted by all the clients.

GNS implies a hierarchical system to accomplish the requirements. Hierarchy is the

fundamental method for accommodating growth and isolating faults.

4.2 Name Space Architecture

Global name services can be divided into two levels. At the client level there are

hierarchical names and their values, with operations for reading and updating them, and

facilities for protection and authentication. The naming database which is distributed and


12/25

replicated is invisible at this level. At the administrative level the copies of the database

are visible, together with the mechanisms for locating copies and keeping them

synchronized.

4.2.1 Client Level

Directory tree and value tree structure

Names in GNS have two parts: . The first part identifies adirectory; the second refers to a value tree, or some portion of a value tree. GNS manages

a naming database that is composed of a tree of directories holding names and values.

Directories are named by multi-part pathnames referred to a root, or relative to a workingdirectory, by which it can be reached from its parent. Each directory is also assigned an

integer, which serves as a unique directory identifier(DI). The arcs of the tree are called

directory references (DRs). A DR is the value of the name; it consists simply of the DIfor the child directory. Thus a directory can be named relative to a root by a path namecalled itsfull name (FN).

A directory contains a list of names and references. The values stored at the leaves of thedirectory tree are organized to into the value trees, so that the attributes associated with

names can be structured values. An arc of the value tree carries a label (L), which is just a

string, written next to the arc in the figure. A node carries a time-stamp (TS), represented

by a number, and a markwhich is eitherpresentorabsent. A path through the tree isdefined by a sequence of labels (L*). For the value of the path, there are three cases:

If the path l*/lends in a leaf that is an only child, we say that lis the value ofl*.

If the path l*/li ends in a leaf that is not an only child, and its siblings are labeled l1...ln, we say that the set {l1... ln} is the value ofl*.

If the path l* does not end in a leaf, we say that the sub-tree rooted in the node where

it ends is the value ofl*.

An update to a directory makes the node at the end of a given path present or absent. The

update is time-stamped, and a later time-stamp takes precedence over an earlier one with

the same path. The subtleties of this scheme are discussed later; its purpose is to allow the

tree to be updated concurrently from a number of places without any priorsynchronization.

Figure: GNS directory tree and value tree for user Peter.Smith


13/25

Access Control and Authentication

Access control is based on the notion of aprincipal, which is an entity that can beauthenticated by its knowledge of some encryption key (which acts as its password). Aprincipal is identified either by a full name or, in case the root of the full name is not

trusted, by a relative name, a path through the directory tree starting at the target

directory and using .. to denote the parent. Each directory has an access control functionwhich maps a principal and a path into a set ofrights drawn from {read, write, test}.

Each of the operations provided by the name service requires the principal that invokes it

to have certain rights to the nodes involved in the operation. For the convenience of the

users, the access control function is defined by a set of triples (principal pattern, pathpattern, rights).

Authentication is based on the use of encryption to provide asecure channelbetween thecaller of an operation and its implementor. A directory has an authentication functionaf,which is a mapping from keys to principals; it accepts a message encrypted with key kas

coming from principal af(k). Each directory has a few values for which afis defined by

some external means (such as a courier). In particular, there is a secure channel for each

parent-child link; the parents afmaps this channels key to the childs name, and the

childs afmaps it to ...

The authentication function can be extended by a certificate, a message encryptedwith key k'which says, Key kauthenticates the principal whose name isNrelative to

U F

A

QMDI:

Peter.Smit

passwormailboxe

DI: 599 (EC

DI:DI:

DI:

Alph GammBet


14/25

me. This allows af(k) to be defined as af(k')/N. A sequence of certificates can establish a

secure channel between any two directories; the relative names to which the directories

map the channel will depend on what other directories participated in setting it up.

4.2.2 Administrative Level

The client sees a single name service and is not concerned with the actual machine on

which it is implemented or the replication of the database that makes it reliable. The

administrator allocates resources to the implementation of the service and reconfigures it

to deal with long term failures. Instead of a single directory, she sees a set ofdirectory

copies (DC), each one stored on a differentserver(S) machine. A directory reference

(DR) now includes not just the DI of the directory, but also a list of the servers that store

its DCs. A lookup can try one or more of the servers to find a copy from which to read.

Replication

The directory tree is partitioned and stored in many servers, with each partition replicated

in several servers. The consistency of the tree is maintained in the face of two or more

concurrent updates - for example, two users may simultaneously attempt to create entrieswith the sane name, and only one should succeed. Replicated directories present a second

consistency problem: this is addressed by an asynchronous update distribution algorithm

that ensures eventual consistency, but with no guarantee that all copies are always current.

This level of consistency is considered satisfactory for the purpose.

The copies are kept approximately but not exactly the same. Every directory copy keeps

latest updated time stamps called lastSweep time. Each copy also has a nextTSvalue, thenext time-stamp it will assign to a new update; this value can only increase.

An update originates at one DC, and is initially recorded there. The basic method for

spreading updates to all the copies is asweep operation, which visits every DC, collects acomplete set of updates, and then writes this set back to every DC. The sweep has a time-

stampsweepTS. Before it reads from a DC it increases that DCs nextTStosweepTS; this

ensures that the sweep collects all updates earlier thansweepTS. After it writes back to a

DC, it sets that DCs lastSweep tosweepTS. In order to speed up the spreading ofupdates, any DC may send some updates to any other DC in a message.

The set of servers in the DR stored in the parent is not suitable, because it is too difficult

to ensure that the sweep gets a complete set if the directorys parent or the set of DCs ischanging during the sweep. To obtain the set of Dcs reliably, all the DCs are linked into aring, directed by arrows. Each arrow represents the name of the server to which it points.

The sweep starts at any DC and follows the arrows; if it eventually reaches the starting

point, then it has found a complete set of DCs. Of course, this operation need not be donesequentially; given a hint about the contents of the set, say from the parent DR, the sweep

can visit all the DCs and read out the ring pointers in parallel. DCs can be added or

removed by straightforward splicing of the ring.

If a server fails permanently, or if the set of servers is partitioned by a network failure

that lasts for a long time, the ringmust be reformed. In the process, an update will be lost


15/25

if it originated in a server that is not in the new ring and has not been distributed.

Reforming the ring is done by starting a new epoch for the directory and building a new

ring from scratch, using the DR or information provided by the administrator about whichservers should be included. An epoch is identified by a time-stamp, and the most recent

epoch that has ever had a complete ring is the one that defines the contents of the

directory. Once the new epochs ring has been successfully completed, the ring pointers

for older epochs can be removed. Since starting a new epoch may change the database, itis never done automatically, but must be controlled by an administrator.

The servers are themselves named in the database, byserver names (SN) that are simply

full names. The value of a SN is a uniqueserver identifier(SI) and the network addressof the server.

4.3 Scalability of GNS

The structure of the name space may change during the time to reflect changes in

organizational structures. The service should accommodate changes in the names of theindividuals, organizations and groups that it holds; and changes in the naming structure

such as those that occur when one company is taken over by another. In this section, we

shall focus on those features of the design that enable it to accommodate such changes.

To accommodate the growth and change in the structure of the naming database, GNSadopts merging trees under new root to support the growth and moving directory trees to

restructure the name database. Although GNS successfully addresses needs for scalabilityand reconfigurability, the solution adopted for merging and moving results in a requirement for a

database (the table of well-known directories) that must be replicated at every node. In a large-scale network, reconfigurations may occur at any level, and this table could grow to a large size,conflicting with the scalability goal. Here we discuss the growth and restructuring first.

Growth

The basic mechanism for growth of the name space is its hierarchical structure. Each directory isa context within which names can be generated independently of what is going on in any otherdirectory. The growth is accommodated through extension of the directory tree in the usualmanner. We may wish to integrate the naming trees of two previous separate GNS services.Each directory can have its own administrator, and they do not have to coordinate their

actions. Since new directory names can be created as easily as new entity names, the

organization of the name space can readily be made broader or deeper.

The growth is accomplished by combining existing name services, each with its own root,and adding a new root, making the existing roots its children. The technology will affect

the clients that continue to use absolute names (beginning with the symbol for the root /)

referring to the old root before the integration, because they do not know the current newworking root (initial contexts against which names beginning with the root / are to be

lookup). A file system name is normally relative to the working directory, or to the root

of the file system. A full name begins with the DI of the root directory for that name.Thus the DIs act as names in an imaginary super-root which has all the directories as its

children; an FN behaves like a file system name relative to the superroot.


16/25

GNS uses unique directory identifiers to solve this problem. The working root for each

program must be identified as part of its execution environment as a working directory. Auser will have a working root, which is prefixed to any name she types. When a client

uses a name, its local user agent, which is aware of the working root, prefixes the

directory identifier to produce a new name with more complete information. The user

agent passes this derived name in the lookup request to a GNS server. The user agentmay deal similar with relative names referred to working directories. Clients that are

aware of the new configuration may also supply absolute names to the GNS server,

which are referred to the conceptual super-root directory containing all directory

identifiers, finally it can get the real full name. The technology allows users and clientprograms to continue to use names that are defined relative to an old root, even when a

new real root is inserted.

At any time, an instance of the name service has a single root, and there are datastructures maintained by the administrative level that allow a copy of the root to be found

from any serve. Only full names beginning with the roots DI can be looked up, which isfine when the root is created first and growth occurs at the leaves. There is a

implementation problem: in a distributed naming database that may contain millions of

directories, how can the GNS service locate a directory given only its identifier. The

solution adopted by GNS is to list those directories that are used as working roots, in atable of well-known directories held in the current real root directory of the naming

database. Whenever the real root of the naming database changes, all GNS servers are

informed of the new location of the real root. They can then interpret names of the form

which are referred to the real root in the usual way, and they can interpret names of the

form by using the table of well-known directories to translate them to full pathnamebeginning at the real root. The table of well-known directories that maps certain DIs into

links which are full names relative to the root. When a lookup reaches the root, it can

consult the well-known table and replace the full names DI with a path that starts at the

root itself. When combining name services, it is prudent to make the old roots well-known in the new root, so that old names can still be looked up.

Figure: Merging trees under a new root


17/25

Restructuring

GNS supports the restructuring of the database to accommodate organizational change.

When a directory A wishes to move to another directory B, the subtree rooted in the A

directory will be moved under the B directory. Moving a subtree is the only restructuringoperation; as long as it doesnt form a cycle (not allowed), it preserves the tree structure

of the service.

The obvious problem with this move is that if the subtree A is simply moved to the newdirectory, all the names that begin from the old directory will no longer work, since oldfather directory of A no longer has a child A. The solution adopted by GNS is to insert a

'symbol link' in place of the original entry. The GNS directory lookup procedure

interprets the link as redirection to the A directory in its new location.

As the figure shown, we suppose US becomes part of the European Community. GNS

moves the US subtree under EC directory, and insert a symbol link #633/EC/US in

place of the original entry to redirect US to the new location.

Figure: Restructuring the directory

EC

UK FR

DI: 599

DI: 574DI: 543

NORTH AMERICA

US

DI: 642

DI: 457DI: 732

#599 = #633/EC

#642 = #633/NORTH AMERICA

Well-known directories:

CANADA

DI: 633 (WORLD)


18/25

4.4 Caching

Caching

The potentially large naming database and the scale of the distributed environment make

name lookup not likely to be especially cheap. Indeed, if the servers that store the name

or its parent directories are far away in the network, lookup may be quite expensive. It is

very desirable for a client to be able to cache the result of a lookup for a while, ratherthan repeating it every time the value is needed. GNS make use of caching essentially

and render it extremely difficult to maintain complete consistency between all copies of a

database entry.

Since it is impractical for the service to keep track of clients that are doing this and notify

them when there is a change, the cache consistency strategy relies on the assumption that

updates to the database will be infrequent and that slow dissemination of update is

acceptable. In other words, caching must be paid for either by enforcing a slow rate ofchange on the naming database, or by tolerating some inaccuracy in the cached

information which requires no work from the service, since clients can detect and recover

from the use of out-of-date naming data.

The enforcement mechanism is an expiration time (TX) on entries in the data base, and in

particular on parent-child arcs in the directory tree and on links. The rule is: an arc or linkmay not be changed until its TX has expired, except that an arc may be deleted by a sub-

tree move if it is replaced by a link to the moved sub-tree.

One important client for caching is the name service itself which will make use ofcaching directory names from the root to avoid access bottleneck. Authentication is

another client of caching, since key authenticates principal is the result of a name

lookup.

EC

UK FR

DI: 599

DI: 574DI: 543

NORTH AMERICA

US

DI: 642

DI: 457DI: 732

#599 = #633/EC#642 = #633/NORTH AMERICA

Well-known directories:

CANADA

DI: 633 (WORLD)

#633/EC/US

US


19/25

5. X.500 Directory Service5.1 Overview

X.500 is a directory service. It is primarily used to satisfy descriptive queries and to

discover the names and attributes of other users or system resources. The uses for such aservice are directly analogous to the use of telephone directories, such as white pages

access to obtain a users electronic mail address or a yellow pages query aimed at

obtaining the names and telephone numbers of garages specializing in the repair of a

particular make of car, to the use of the directory to access personal details such as job

roles, dietary habits or even photographic images of the individuals.

The ITU and ISO standards organizations have defined the X.500 Directory Service as anetwork service intended to meet these requirements. The standard refers to it as a

service for access to information about hardware and software services and devices.

X.500 is specified as an application level service in the Open System Interconnection set

of standards, but its design does not depend to any significant extent on the other OSI

standards, and it can be viewed as a design for a general-purpose directory service.

5.2 X.500 Service Architecture

5.2.1 Objects and Entries

The data stored in X.500 servers is organized in a tree structure with named nodes in

which a wide range of attributes are stored at each node in the tree and access is not just

by name but also by searching for entries with any required combination attributes.

An entry holds information about an object of interest to users of the Directory. Theseobjects might typically be associated with, or be some facet of, real world things such as

information processing systems or telecommunications equipment or people. Directory

objects, and hence entries, can have a one-to-one many-to-one or one-to-manyrelationship with real world things. For example, a directory object/entry may be a

mailing list containing the names of many real people (one-to-many correspondence).

Alternatively, a real person may be represented in the directory as both a residentialperson object/entry and an organizational person object/entry (many-to-onecorrespondence). In the latter case, the organizational person directory entry would hold

information that is relevant to describing the person in their working environment,

holding their office room number, internal telephone extension number, electronic mail

address, and the department etc., the residential person directory entry would describe theperson in their residential capacity, holding their home postal address and home

telephone number etc.

5.2.2 The Structure of the DIB


20/25

The complete set of all information held in the directory is known as the Directory

Information Base (DIB) which consists of entries. These entries held in the DIB are

structured in a hierarchical manner, using a tree structure, which is similar to a structurechart used by most hierarchical organizations. The DIB can therefore be represented as a

Directory Information Tree (DIT), in which each node in the tree represents a directory

entry.

There is intended to be a single integrated DIB containing information provided byorganizations throughout the world with portions of the DIB located in the individual

X.500 servers. As shown in the figure 1, the servers are called Directory Service Agents

(DSAs). Clients, named formally as Directory User Agents (DUAs), access the directoryby visiting any servers and issuing access requests. If the data required are not in the

segment of the DIB held by the contacted server, it will either invoke other servers or

resolve the query or redirect the client to another server.

5.2.4 Naming Entries

Each object entry known to the directory is distinguished from all other objects by itsname. Thus each entry is said to have a distinguished name (DN), 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 basenode, and then use shorter relative names that give the path from the base node to thenamed entry, which is called relative distinguished name (RDN). An entry's RDN

uniquely identifies it from all of its peers. Since each RDN is guaranteed to be unique

below any particular non-leaf node, each entry is guaranteed to have a unique DN.Figure 2 shows the portion of the directory information tree that includes the University

of Gormenghast, Great Britain. An example of an entry under Pat King is shown here:

DSA

DSA

DSA

DSA

DSADSADUA

DUA

DUA


21/25

Country=Great Britain@organization= University of Gormenghast@organizationalUnit=

Department of Computer Science@organizationalUnit= Departmental Staff@person= Pat

King

Figure 2

Figure 3 is one of the associated DIB entries. 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. New attribute types can be defined if they are required. For

each distinct type name there is a corresponding type definition, which includes a typedescription and a syntax definition in the ASN.1 Notation defining representations for all

permissible values of the type.

.. France (country) Great Britain countr Greece countr ..

BT Plc (organization) University of Gormenghast (organization)... ...

Department of Computer Science (organizationalUnit)

Com utin Service or anizationalUnit

Engineering Department (organizationalUnit)

..

..

X.500 Service (root)

Departmental Staff (organizationalUnit)

Research Students (organizationalUnit)el a licationProcess

..

..

Alice Flintstone erson Pat Kin erson James Heale erson .... Janet Papworth (person)..


22/25

Figure 3

5.2 Access Methods in X.500

5.2.1 Read

An absolute or relative name (a domain name in X.500 terminology) for an entry is given,

together with a list of attributes to be read. The DSA locates the named entry bynavigating in the DIT, passing requests to other DSA servers where it does not hold

relevant parts of the tree. It retrieves the required attributes and returns them to the client.

5.2.2 Search

This is an attribute-based access request. A base name and a filter expression are supplied

as arguments. The base name specifies the node in the DIT from which the search is tocommence; the filter expression is a Boolean expression that is to be evaluated for every

node below the base node. The filter specifies a search criterion: a logical combination of

tests on the values of any of the attributes in an entry. The search command returns a list

of names for all of the entries below the base node for which the filter evaluates to TRUE.

5.3 X.500 and LDAP

5.3.1 Introduction

LDAP (Lightweight Directory Access Protocol) arose from initial experience with

deploying X.500 directory services on the Internet in 1989-91. The goal of the originalLDAP was to give simple lightweight access to an X.500 directory, to facilitate the

development of X.500 DUAs and use of X.500 for a wide variety of applications.

infoAlice Flintstone, Departmental Staff, Department of Computer Science,

University of Gormenghast,

commonNam

AliceA.

surnam

telephoneNumbe

+44 986 33

ui

alf

mail

[email protected]

roomNumbe

userClas

Research


23/25

LDAP is 'simple', relative to X.500, because:

1. While the LDAP PDUs are based on those from X.500, elements of the protocol have

been modified to produce a protocol that is significantly simpler.

2. Names and attributes use text encoding. Names and attributes are pervasive in the

protocol. In X.500, these have a complex ASN.1 encoding, whereas in LDAP they aregiven a simple string encoding. This is particularly helpful for applications that do not

need to handle the detailed structure of names or attributes.

3. Mapping directly onto TCP/IP. LDAP maps directly onto TCP/IP (the Internet

transport layer), and removes the need for a non-trivial amount of OSI protocol.

4. LDAP relies on X.500 for the service definition and distributed operations. Because

LDAP is defined as an access protocol to X.500 and not as a complete directory service,it is possible to specify LDAP very concisely. The detailed service definitions, whileoften intuitive from the protocol, are formally specified in X.500. Where the directory

service is provided by more than one Directory Server, the procedures for doing this are

not defined by LDAP.

5.3.2 X.500 and LDAP

The most important thing to understand about X.500 and LDAP is that they have more in

common than different. The things that they have in common relate to the information

model and standard services, which are absolutely central to both X.500 and LDAP. This

section describes the common core:

1. Hierarchical Names. LDAP and X.500 both define a hierarchical directory with

hierarchical names.

2. Typed Name Components. Name components are typed. This contrasts with other

schemes which have typeless names, such as the domain name scheme. It is

straightforward to represent typeless names in a typed naming scheme.

3. Typed Objects. Objects are represented as Entries in an X.500/LDAP directory. These

entries are given a type (or types), known as the object class, by use of an Object Class

attribute. Typical object classes are People, Organizations, and Computers. X.500 andLDAP share object class definitions.

4. Typed Attributes. Information within objects is held as a set of typed attributes For

example there may be a 'telephone number' attribute with one or more values. Many

attributes are encoded as strings. Other attributes have an encoding which is inferred fromthe attribute type. This can be used for non-string data such as pictures or to handled

structured information. X.500 and LDAP share attribute type definitions.


24/25

5. Directory Operations. X.500 and LDAP share a common set of operations to access

and manage data in the directory. These are: read; compare; search; add; delete; modify

entry; modify RDN.

5.4 Discussion of X.500

Based on D W Chadwicks report, some of the factors which were critical to the success

of the X.500 are identified. These were:

1. Integration of directory access with other applications or communications services

such as E-mail is essential if the vast majority of users are to frequently use the directory;

2. The establishment of organizational procedures, administrator commitment, andsoftware tools for gathering and updating the data in the directory are essential but time

consuming tasks, which are often underestimated;

3. Senior management support for the deployment of an electronic directory is paramount.

Other issues which can have significance to the success (or otherwise) of the X.500 were:

User involvement in the project, user interfaces, naming the entries in the DIT, technical

problems, response times, security and legal issues. However, it must be remembered thatsince a majority of these projects were not initially intended for mission critical

operational use by all users, (in other words, the directory was seen as being simply

another nice service to have) some of these issues may become more critical once this is

the case.

One thing that is evident, is that X.500 can be used in a wide variety of organizations all

over the world, for a wide variety of purposes, and that X.500 would appear to have

fulfilled its purpose of being an truly International Standard for directory services.

References

1. G. Coulouris, J. Dollimore, T. Kindberg,Distributed Systems: Concepts and Design,2001

2. B. Lampson, Designing a global name service, Proc. 4th ACM Symposium on

Principles of Distributed Computing, Minaki, Ontario, 1986, pp 1-10

3. Kendra Cooper,An Introduction to the Domain Name Service (DNS), August 2002

4. Madhavarapu Jnana Pradeep Discovery Service, January 2001

5. Damon Fenacci, The Jini Lookup Service: Introduction & Discovery Protocols,December 5., 2000

6. RFC1943, Building an X.500 Directory Service in the US, 1996


25/25

7. D W Chadwick, Important Lessons Derived from X.500 Case Studies, University of

Salford, Salford, M5 4WT

8. D W Chadwick, Understanding X.500 - The Directory, International ThompsonPublishing, July 1996

9. Steve Kille, LDAP and X.500, Messaging Magazine, September 1996

10. ITU-T, Information technology - Open Systems Interconnection - The Directory:

Overview of concepts, models and service, Recommendation X.500, International

Telecommunications Union, Geneva, 1993.

Name Service Doc

Documents

Transcript of Name Service Doc