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 . 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