Ch 4' Naming

1
Ch 4. Naming

• Name service basics
• Domain Name System
• Directory service
• Locating mobile entities
• Removing unreferenced entities
• Tanenbaum, van Steen Ch4
• CoDoKi Ch9

2
Names and addresses

• Needed for identification of resources
• communication
• sharing
• Wide variety of resources
• (computers, services, files, processes,
  users)
• Alternative descriptive identification
• Name vs address
• The name identifies the object
• An address tells where it is
• A route tells how to get there

3
Name service

• Mapping name gt address (or other attributes
  or identity)
• Basic services
• Maintaining the Name DataBase
• naming (registration of a unique binding name
  ltgt address)
• updating (relocation allowed)
• Resolving names
• Administration of group names
• Generalization directory service
• DB entry description of an object
• description a set of attributes (name, type,
  address, )

4
The structure of mapping
textual file name
/users/smith/F
Server FS
file name service
55.55.55.55 888 222
55.55.55.55 888 222
F
5
Name service requirements (1)

• Specific name services
• (file system, mail system, process management,
  ...)
• General name services
• A name has a meaning only within a context
• (name service collection of naming contexts)
• Operations resolve, bind, unbind, add/delete
  context
• Naming systems of distributed environments are
  open gt
• unification the same naming scheme for all
  services
• integration expansion over different
  administrations

6
Name service requirements (2)

• An arbitrary number of names, an arbitrary number
  of administrative organizations
• A long lifetime (gt many changes will occur)
• High availability
• Fault isolation
• Tolerance of mistrust
• Notice
• Name service cannot be provided by a DB system

7
Name spaces

• Structured name organization of names
• (e.g., a tree or a directed graph path names)
• local authority of naming
• potentially infinite name spaces
• Flat names
• Structured names
• absolute names (with respect to the root of the
  system)
• relative names (with respect to a context)
• Domain area of name administration
• (DNS the domains have names)

8
Combining name spaces

• Merging
• Traditionally mounting of file systems
• Merging of entire file systems
• Create a higher-level root
• Old absolute names?
• Heterogeneity
• different name spaces embedded (e.g., OSF/DCE)
• //dcs.qmw.ac.uk/principals/Jean.Dollimore
• cell junction (a new
  context)

9
Composed naming domains used to access a resource
from a URL
CoDoKi, Fig. 9.1
10
Name Space Distribution (1)

• An example partitioning of the DNS name
  space, including Internet-accessible files, into
  three layers.

11
Name Space Distribution (2)

• A comparison between name servers for
  implementing nodes from a large-scale name space
  partitioned into a global layer, as an
  administrational layer, and a managerial layer.

12
Name resolution

• name gt naming context gt
• set of primitive attributes
• OR
• a new naming context (with a derived name)
• a name-service database may be
• partitioned
• replicated (so is the corresponding
  server) (typically data partitioned according
  to domain)
• navigation
• client controlled, iterative (Fig. 9.2)
• server controlled non-recursive, recursive (Fig.
  9.3)
• multicast navigation
• performance caching

13
Implementation of Name Resolution (1)

• The principle of iterative name resolution.

14
Implementation of Name Resolution (2)

• The principle of recursive name resolution.

15
Implementation of Name Resolution (3)

• Recursive name resolution of ltnl, vu, cs,
  ftpgt. Name servers cache intermediate results for
  subsequent lookups.

16
The Domain Name System

• Original Internet NS
• centralized (but local organizations wished own
  names)
• customers downloaded when needed
• attributes computer addresses
• gt did not scale to large numbers of computers
• DNS 1987 (Mockapetris)
• in principle any type of object can be named
• in practice hosts, domains
• name resolution host name to IP address
• mail host location domain name to IP
  address of mail host (responsible for the
  domain)

17
DNS queries

• Host name resolution host name to IP address
• FTP, SMTP, etc
• www browsers
• Mail host location domain name to IP address of
  mail host (responsible for the domain)
• Reverse resolution
• IP name to domain name
• Host information
• Well-known services
• IP name gt the host available services (and
  protocols needed to use them)

18
DNS Name Servers (1)

• Techniques for scalability, performance
• partitioning, replicating, caching
• Zone (unit of administration)
• attribute data for names in a domain (less
  sub-domains administered by lower level
  authorities)
• names and addresses of at least two authoritative
  name servers (for that zone master, secondary
  file/server)
• names of authoritative name servers for
  sub-domains
• zone management parameters (caching, replication)

19
DNS Name Servers (2)

• A server can hold authorized data for 0,1,
  zones
• A server is free to cache
• Consistency
• update primary (master) server
• secondary downloads the updates periodically
  (period zone parameter e.g., once a day)
• cache data time-to-live stamp (zone parameter)

20
DNS Name Servers (3)
Note Name server names are in italics, and the
corresponding domains are in parentheses.
Arrows denote name server entries

CoDoKi, Fig. 9.4
21
DNS Name Servers (4)

• Root servers entries for several levels of
  domain
• authoritative for for the name servers for the
  top level
• authoritative for generic top-level domains
• not name servers for the country domains
• Root servers are replicated
• All name servers know
• one or more root servers
• an authoritative server for the parent domain
• Navigation iterative or recursive (not
  obligatory)

22
DNS resource records

• The most important types of resource records
  forming the contents of nodes in the DNS name
  space.

23
DNS Implementation

• An excerpt from the DNS database for the
  zone cs.vu.nl.

24
DNS Discussion

• Short response times
• Design for performance partitioning,
  replicating, caching naming data
• Objects named computers, name servers, mail
  servers
• Data consistency not enforced (stale data users
  problem)

25
Directory Services

• Name service mapping namegtattributes
• Directory service
• in values of attributes to identify a set of
  objects
• out a selection of directory entries (related
  to objects possessing the specified attribute
  values)
• Examples X.500, LDAP (yellow pages)
• Discovery services
• ad hoc networks devices come and go
• customers / services a dynamically changing
  collection
• automatic registering/de-registering lookup
• Jini service discovery, transactions, shared
  data spaces

26
Directory Contents

• Descriptions of entities

27
X.500 Directory Service (1)

• Directory service (and name service)
• Queries descriptive (specif. through attributes)
• Users end users, processes (what is the
  difference?)
• ITU-T, ISO
• Collection of open systems which cooperate to
  hold a logical database of information about a
  set of objects in the real world
• A worldwide database a tree of entries with
  attributes about the objects, distributed in
  individual servers

28
X.500 Directory Service (2)

• Service architecture (see CoDoKi, Fig. 9.10)
• Directory Service Agents
• Directory User Agents
• navigation iterative or recursive
• Directory Information Tree
• see Fig. 4-16.
• attribute type, value (types open ended)
• entries classified (open ended)
• object class mandatory attributes, optional
  attributes
• Naming a path of distinguished attributes

29
X.500 service architecture
DUA
DSA
DSA
DSA
DUA
DSA
DSA
DUA
DSA
CoDoKi, Fig. 9.10
30
The X.500 Name Space (1)

• A simple example of a X.500 directory entry
  using X.500 naming conventions.

31
The X.500 Name Space (2)

• Fig. 4-16. Part of the directory
  information tree.

32
X.500 Operations
33
X.500 Discussion

• A general model for all kinds of directories
• The implementation of a DSA is free
• Practical impact intranet level (due to
  Lightweight Directory Access Protocol )
• A global directory standard ?
• privacy ?
• integration with naming (DNS, etc) ?
• scope of information gt standardization of object
  classes ?

34
Locating Mobile Entities

• A name identifies the intended entity
• An address is the name of its location (at
  the level of the searching/routing tool)
• The mapping name gt location may be stored in
  several directories
• An entity
• may have several names
• may move from one location to another one
• Mobility gt consistency of directory entries?

35
Naming versus Locating Entities

• Direct, single level mapping between names and
  addresses.
• T-level mapping using identities gt separation
  of naming and locating
• (mobility is transparent to the naming
  service)

36
Mapping id gt mobile address

• Use Local Area Networks
• Broadcasting (no directory needed)
• client Anybody called NN here?
• NN NN at address.NN !
• an example the Internet Address Resolution
  Protocol
• Forwarding pointers
• E moves from A to B
• A info E in B

37
Forwarding Pointers (1)

• Fig. 4-18. The principle of forwarding pointers
  using (proxy, skeleton) pairs.

38
Forwarding Pointers (2)

• Fig. 4-19. Redirecting a forwarding pointer, by
  storing a shortcut in a proxy.

Trade-off shortcut vs. updated chain? Problem
crash in chain gt entity lost Backup up-to-date,
fault-tolerant information at the home of the
entity
39
Home-Based Approaches

• Fig. 4-20. The principle of Mobile IP.

40
The Problem of Unreferenced Objects
A solution reference counting

• Fig. 4-28. An example of a graph representing
  objects containing
• references to each other.

41
Reference Counting (1)

• Fig. 4-29. The problem of maintaining a proper
  reference
• count in the presence of unreliable communication.

42
Reference Counting (2)
A solution.

• Copying a reference to another
• process and incrementing the
• counter too late

Fig. 4-30.
43
Advanced Methods

• (Weighted reference counting see Ch.4.3.2)
• Reference listing
• a skeleton maintains a list of all proxies
  pointing to it
• adding to / removing from
• idempotent operations
• must be acknowledged
• see Ch. 4.3.3
• Identifying unreachable entities mark-and-sweep
• mark all reachable entities
• sweep through all entities, remove the not-marked
  ones
• (see Ch. 4.3.4)