Network Working S.E. Hardcastle-Kille
Group University College London
INTERNET-DRAFT January 1992
DSA Naming
(OSI-DS 13 (v2))
Status of this Memo
This INTERNET--DRAFT describes a few problems with DSA Naming as
currently deployed in pilot exercises, and suggests a new approach.
An approach is suggested for use in the Internet Directory Pilot,
which overcomes a number of existing problems, and is an important
component for the next stage in increase of scale.
This draft document will be submitted to the RFC editor as a protocol
specification. Distribution of this memo is unlimited. Please send
comments to the author or to the discussion group
<osi-ds@CS.UCL.AC.UK>.
INTERNET--DRAFT DSA Naming January 1992
1 Problem Statement
There are a number of difficulties with the approach being used in
QUIPU based pilots, which is described in the original QUIPU Design
and in the QUIPU documentation [Kil88]. The problems are:
1. It is hard to achieve very high replication of knowledge
information, as this is very widely spread. This is particularly
true of secondary DSAs, which are named inside an organisation.
Due to the sensitivity of sibling information, replication of this
data outside the organisation is less likely.
2. There is a need to give DSAs more reasonable names. The current
names are too high up the tree to indicate the role of the DSA.
This can lead to management confusion.
3. There is too much DIT clutter --- more endangered South American
animals than organisations!
4. There is no real concept of DMD (Directory Management Domain)
authority. This needs to be introduced, in order to allow DSAs to
be named by the authority that runs them.
The following are good properties of the current approach, which must
not be lost in any changes.
1. The directory should be used to look up the presentation addresses
of DSAs as described in [HK91] and not require them to be manually
associated with all knowledge references as implied in X.500.
2. The approach must be deadlock free. This will not be the case if
DSAs are named in a careless manner, and the directory is used to
look up the presentation addresses of DSAs.
3. There should be no manual replication of information, which is
implied by the presentation address configuration approach of the
standard.
Some non-QUIPU implementations have followed the QUIPU approach and
have inherited the same problems. Others have taken a simpler
approach to naming, which has usually excluded the possibility of
Hardcastle-Kille Page 1
INTERNET--DRAFT DSA Naming January 1992
using the directory to manage DSA presentation addresses. In this
case, this proposal will provide a useful improvement for such
systems.
2 What is a DMD
A DMD is a special type of Organisation, which has two roles.
1. Managing directory configuration information.
2. Operating one or more DSAs (A DSA belongs to the DMD that operates
it)
Because a DMD is an Organisation, it should be represented in the DIT
as if it was any other Organisation. A common case is for an
Organisation (or Organisational Unit) to operate its own DSAs. In
this case the Organisation has a dual role as both a DMD and an
Organisation which is not a DMD. Such a DMD is primarily responsible
for operating a number of DSAs, and some minimal configuration
information associated with those DSAs. For most organisations, the
number of DSAs will be small, although a large organisation may run
quite a large number.
Another common case is for a DMD to be primarily concerned with
managing configuration information between a large number of DSAs, and
perhaps operating a small number of DSAs in order to achieve this. A
research network pilot is an example of such a DMD. Such a DMD will:
o Collect and distribute configuration information
o Collect and distribute user data (replication)
An Administrative DMD (as distinct from a Private DMD) is one which
systematically maintains knowledge of the root configuration within
the DMD. This will only be a useful distinction if this knowledge is
restricted (it is not in the current pilot environment). For now it
should be assumed that this information is widely replicated, as
adequate performance of the global directory depends on it.
A DMD may have a peer relationship with other DMDs. There may also be
a hierarchical relationship. This is appropriate for a DMD which
wishes to obtain all of its configuration information and replicated
Hardcastle-Kille Page 2
INTERNET--DRAFT DSA Naming January 1992
from a parent DMD. A hierarchical relationship does not preclude other
relationships between DMDs (e.g., to mutually replicate data).
A DMD has the following responsibilities:
o It must operate at least one DSA, to manage the information
associated with the DMD.
o It may operate DSAs to store information for Organisations
supported by the DMD. These DSAs are named within the DMD
o Allocate sub-DMDs. The EDB for such a DMD should be mastered in
the DMD DSA
o Manage the replication of knowledge information within the DMD,
and make it available for external replication.
3 Naming DMDs and DSAs
The problem of giving DSAs reasonable names, and remaining
deadlock-free is awkward. To resolve this, the concept of a DSA
Naming Tree is introduced. An example of this is given in Figure 1.
DSA Naming trees have the following rules:
1. There may be multiple DSA Naming Trees
2. All DSAs are named within a DSA Naming Tree. This prevents
deadlock for all of the DIT not in a DSA Naming Tree.
3. DSA Naming Trees are ordered by Rank, and each DSA named in a
given DSA Naming Tree is at the same Rank as the DSA Naming Tree.
4. Each DSA Naming Tree has a string RDN. The two DSA Naming Trees
defined initially have names ``End DSAs'' and ``DMD DSAs'', the
latter being of higher rank.
5. All data in a DSA Naming Tree of a given rank must be mastered in
a DSA of higher Rank. This prevents deadlock occurring for any
DSA Naming Tree. Slave copies of data in a DSA Naming Tree of a
given rank which are referenced within that DSA Naming Tree should
be stored in DSA of a higher rank, in order to improve performance
and availability.
Hardcastle-Kille Page 3
INTERNET--DRAFT DSA Naming January 1992
(root)
`` ``
` `` ` `` `` `
`` ` ```
GB
End D`S`A``s`
| `` `` ` ``
| `` ` `` ``
DE GB
a aa a FR
aa a a
a aaa
X-Tel Services Cambridbgbe University
| j j jj b b
| j j b bb
Operations Screeching Cayman Banana Sloth
QQ Q
Q QQ
DSA 1 DSA 2
Figure 1: Example DSA Naming Tree
Hardcastle-Kille Page 4
INTERNET--DRAFT DSA Naming January 1992
6. All entries in a DSA Naming Tree have analogous entries in the
DIT. This means that most naming authority functions are handled
in the normal manner. For example, if there is an entry in the
DMD DSAs Naming Tree:
O=Performance Systems International,
C=US,
CN=DMD DSAs
There will be an entry in the DIT of:
Performance Systems International,
US
7. Non-DSA (usually non-leaf) entries in a DSA Naming Tree will
contain a subset of the information in the analogous DIT entry.
Typically, this will either be the minimum required to support
naming or a full copy of the analogous DIT entry. This data must
be systematically maintained.
8. The DIT entry analogous to a DSA entry in the DSA Naming Tree will
be a special object used for name assignment. The DSA Entry will
be indicated by a SeeAlso attribute in the DIT Entry. This will
allow users to look at DSA entries, without having to see the DSA
Naming Tree. This special object class is used, as opposed to an
alias, in order to prevent operational problems if the DIT entry
was referred to by a DSA. This object class is defined as:
DSAAssignedObject OBJECT-CLASS
SUBCLASS OF pilotObject
MUST CONTAIN -
commonName,
seeAlso "
MAY CONTAIN -
description,
localityName,
organisationName,
organisationalUnitName "
DSA Naming Trees are rooted by an entry of a special object class
DSANamingTreeRoot OBJECT-CLASS
Hardcastle-Kille Page 5
INTERNET--DRAFT DSA Naming January 1992
MUST CONTAIN -commonName"
However many Ranks of DSA Naming Tree there are, there is a bootstrap
problem for the root level data and the highest rank DSA Naming Tree.
This is solved by naming a small number of DSAs at the root level.
One of these, ``Giant Tortoise'', is the master for all root
information and for information in the highest Rank DSA Naming Tree.
The other DSAs hold copies of this information, and are intended to
give higher availability of this data. It is expected that there will
be a very small number of these DSAs (perhaps two or three). This
information will also be replicated in most of the DSAs in the highest
Rank DSA naming tree, and so the DSAs named at the root level should
be accessed infrequently. In general, information in the DSA Naming
Trees will be highly replicated.
Two Ranks of DSA Naming Tree will be used initially. It is not
expected to increase the number of ranks to more than two in the short
or medium term. The ``End DSAs'' DSA Naming Tree is fundamental, and
so there will never be DSAs below this Rank. The ``DMD DSAs'' DSA
Naming Tree may have DSA Naming Trees inserted above or below.
End DSAs This is used to name DSAs, which hold end information (i.e.,
data other than DSA Names). This will be most DSAs.
DMD DSAs This is used to name DSAs which name other DSAs. These will
typically be DMD operated DSAs, used to connect pilots. In the
current pilot there are typically one or two such DSAs per
country.
4 Examples
The description so far is rather abstract. This section tries to give
some example DSA Names, and describes how they might interact.
4.1 The Example DIT
The following entries exist in the DIT, and are real entries with real
information.
O=University College London, C=GB
Hardcastle-Kille Page 6
INTERNET--DRAFT DSA Naming January 1992
OU=Physics, O=University College London, C=GB
O=Performance Systems International, C=US
O=X-Tel Services, C=GB
O=Paradise DMD, C=GB
4.2 Special DSAs
The following are special DSAs, named at the root:
CN=Giant Tortoise
CN=Backup Root DSA
Giant Tortoise is ``well known'', and holds masters of all the
information in the ``DMD DSAs'' DSA Naming Tree. The DSA Backup Root
DSA holds replicas of data in Giant Tortoise.
4.3 DMD DSAs
DSAs named in this DSA Naming Tree belong to (Directory) Management
Domains, and is mastered in Giant Tortoise. Examples:
CN=DSA1, O=Performance Systems International, C=US, CN=DMD DSAs
CN=DSA2, O=Performance Systems International, C=US, CN=DMD DSAs
CN=Flame-Tailed Armadillo, O=Paradise DMD, C=GB, CN=DMD DSAs
4.4 End DSAs
All data in this DSA Naming Tree is mastered in a DSA named in the DMD
DSAs DSA Naming Tree. Typically, this will be done by a DMD with
which the organisation in question has an agreement.
CN=Vicuna, O=University College London,
C=GB, CN=End DSAs
Hardcastle-Kille Page 7
INTERNET--DRAFT DSA Naming January 1992
CN=Master DSA, OU=Physics, O=University College London,
C=GB, CN=End DSAs
CN=Backup DSA, OU=Physics, O=University College London,
C=GB, CN=End DSAs
CN=Peruvian Blotto, O=X-Tel Services, C=GB, CN=End DSAs
4.5 DSAs Named outside DSA Naming Trees
It is important to note that each DSA will have an entry outside of a
DSA Naming Tree. These entries will contain descriptive user
information, and a ``SeeAlso'' to the DSA name. For example:
CN=DSA1, O=Performance Systems International, C=US
CN=DSA2, O=Performance Systems International, C=US
CN=Flame-Tailed Armadillo, O=Paradise DMD, C=GB
CN=Vicuna, O=University College London, C=GB
CN=Master DSA, OU=Physics, O=University College London,
C=GB
CN=Backup DSA, OU=Physics, O=University College London,
C=GB
CN=Peruvian Blotto, O=X-Tel Services, C=GB
5 Information on DSA Managers
A related problem is to obtain information on a DSA Manager. This is
referenced by a the DSAManager attribute in the DSA Entry. It is
quite common for this information to be particularly useful when the
DSA is unavailable, and this information is often stored in the DSA in
question. To solve this, a new attribute is proposed for each DSA,
which holds a cache of all of the publically readable information in
Hardcastle-Kille Page 8
INTERNET--DRAFT DSA Naming January 1992
the DSA Manager's entry. This cache should be maintained
automatically
attributeSyntax ATTRIBUTE-SYNTAX
Attribute
MATCHES FOR EQUALITY
DSAManagerInformation ATTRIBUTE
WITH ATTRIBUTE-SYNTAX attributeSyntax
SINGLE VALUE
6 Acknowledgements
Particular credit is due to Wengyik Yeong of PSI, to Marshall T. Rose
of DBC and to Colin Robbins of X-Tel for useful input to this
document.
References
[HK91] S.E. Hardcastle-Kille. Replication and distributed operations
extensions to provide an internet directory using X.500.
Request for Comments RFC 1276, Department of Computer Science,
University College London, November 1991.
[Kil88] S.E. Kille. The QUIPU directory service. In IFIP WG 6.5
Conference on Message Handling Systems and Distributed
Applications, pages 173--186. North Holland Publishing,
October 1988.
7 Security Considerations
Security issues are not considered in this INTERNET--DRAFT .
8 Author's Address
Steve Hardcastle-Kille
Department of Computer Science
University College London
Gower Street
Hardcastle-Kille Page 9
INTERNET--DRAFT DSA Naming January 1992
WC1E 6BT
England
Phone: +44-71-380-7294
EMail: S.Kille@CS.UCL.AC.UK
Hardcastle-Kille Page 10