Network Information in the Directory: a Deployment Strategy OSI-DS Working Group July 1993 Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Expires: January 2, 1994 [Page 1] Internet Draft June 1993 Abstract This document describes a strategy for deploying the X.500 Directory in the Internet. The focus is mainly on the Internet related information. Contents ======== 1.Introduction 2 2.Deployment Issues 2 3.Network Information 3 4.General strategy 4 4.1 The interrelation of the information in the existing sources 4 4.2 Local representation of information 6 4.3 Relation of the information with the Global Directory. 7 4.2 Where Should The Organization-info go? 8 4.3 The DIT Structure 9 4.4 Directory service infrastructure 10 4.5 Administrative Requirements 12 4.6 Deployment Stages 12 5. Mapping NIC-INFO onto the Directory 13 6.References 14 1. Introduction. =============== The phenomenal and continued growth of networking in general and the Internet in particular has led to the growing need of a distributed framework which allows users and applications to access information about users, services, networks, ... easily and globally. The OSI X.500 Directory services provides a rich framework to support a globally distributed information service system. A strategic plan for the deployment of an Internet Directory Service has been proposed in [STR]. Towards realizing this plan a substantial effort has been carried out by the IETF OSI-DS WG in setting up the a coherent information framework for the Directory. Presently several different but cooperating pilots [PSI, FOX, Paradise] are offering Directory services. These basically deal with person and organization related information. There has been a substantial effort within the IETF OSI-DS WG to chart network information in the Directory. Schemas have been developed for this purpose. [ND, IP, DNS]. Experimental mini-pilots have been Expires: January 2, 1994 [Page 2] Internet Draft June 1993 established [IP2] In this work we address the technical issue of deploying the directory and spreading its use and application by covering information about the network infrastructure. This is essential in making the Directory Information Services itself a success. The issues cover strategies for populating the Directory with Network Information. It should be noted that though some of the services that are or may be offered by the Directory do overlap with existing services, there is no immediate or near future plan of replacing any existing service. The proposed services may be viewed as an experimental and/or auxiliary service. Depending on the application it may be a preferred service, in some cases. So there is not going to be any *migration* from some system to the Directory system. 2. Deployment Issues ==================== - Technical o fixing the schemas atleast on an experimental basis o arranging for distribution of the schemas o setting up the Directory infrastructure o providing the user applications and interfaces - Organizational/Administrative o Set-up an organizational structure for IDMD o Administrators/POCs o Management/distribution of schemas - General o Education regarding the utility and necessity of the Directory o Applications to make the Directory more attractive o A viable bootstrapping strategy that takes care of the transitional state There has been considerable activity in the OSI-DS WG on the schemas for networks and network objects. Work is progressing on the distribution mechanism for the schemas. The Directory infrastructure requires an OSI-stack. Available implementations have been examined and catalogued by the IETF DISI WG in [IMP]. Important developments have take place in the user application area with the LDAP [LDAP] protocol progressing in the standards track. The usage of this protocol removes the burden of implementing an OSI stack from user applications of the Directory. Several attractive applications are being worked upon in the IETF OSI-DS WG. The SoftPages [SPP] project involves optimising document Expires: January 2, 1994 [Page 3] Internet Draft June 1993 retrieval by using the network information stored in the Directory. The Organizational and Administrative framework for the directory in the Internet requires a lot of work. There is an initiative within the IETF OSI-DS WG to formulate this framework. In this work we briefly explore this issue. More detailed discussion will be found in [ADMIN-DOC] The educative aspects and the applications aspect are being taken up in the IETF DISI WG. In the following we examine in detail the issue of the bootstrapping strategy for populating the Directory with Network information. 3. NetWork Information. ====================== The network information basically consist of: * information about the interconnection between the various elements. * properties and functions of the various network elements and the interconnections. e.g. speed, charge, protocol, OS, etc. Functions include services offered by a network element. [File Server, DNS Server, mail gateway, ...] * various name and address information of the networks and network elements [ DNS info, ...] * information about various administrative and management details related to the networks and network elements. [ Managers POCs, owners, ..] * the policy related information [ Autonomous System Number] Schemas have been drawn up to represent the IP network information in the Directory. The defined objects are IPNetworkImage, IPNodeImage, delegatedBlock, asNumber. With the stage being set for servicing IP-Network information in the Directory the deployment problem boils down to one of populating the directory. 4. General strategy. ==================== It is clear that one will have to make use of existing data to populate Expires: January 2, 1994 [Page 4] Internet Draft June 1993 the Directory. A lot of information already exists in a disorganized, unconnected form. The existing information pool consists of NIC information, DNS information, routing policy information, Service information, .... The list is neither exclusive nor exhaustive. The Internic, National NICs and various NOCs also contain a substantial amount of information related to networks, numbers, administrators and organizations. The DNS system is a global distributed database that contains a lot of network related information . At the lowest level,the yellow pages and password files contain user/mailbox related information. There is no doubt that an effective bootstrapping strategy would have to make use of these massive pools of information. 4.1 The interrelation of the information in the existing sources. ================================================================= Network information in the present sources covers not only information about the sources (e.g. NICs :NIC-Profiles) but also covers in varying degrees of depth the network information and services offered by that source as well as administrative information related to the various components. All the components of the information are interrelated. A person is a member of an organization and at the same time maybe the manager of a Network. A Network may belong to an Organization and have a Manager, ... +-------------+ +--------------+ | | Affiliation | | | |<-----------------------| | | Org.Info | | Person.info | | | | | +-------------+ +--------------+ X X \ / \ / Owned by,\ /Manager, Assigned to/by /point of contact \ / \ / \ / \ / \ / +-------------------+ | | | Network.info | | | +-------------------+ Expires: January 2, 1994 [Page 5] Internet Draft June 1993 Taking a closer look at the NIC information base we see that it contains information related to the Network : network number name Nameserver Reverse-server Domain name Domain : name Name Server Reverse-server network number AutonomousSystem: ASs from which routes are accepted ASs to which routes are announced The default Handling of routes Person: Name and contact Organization Name and address The primary information held in the NIC is the Network, Domain and routing policy related [AutonomousSystem] related info. The Person and Organization info is secondary basically as owner of network, poc, admin-c etc.etc. 4.2 Local representation of information ======================================= A simple method would be map the data directly to create IpNw, DNS, AsNum objects each of which would contain a copy of the organization info, and person info. This is shown in the figure below. Expires: January 2, 1994 [Page 6] Internet Draft June 1993 +---------------------------------------------------------+ | +-----------+ | | +-----------+ +-----------+ | admin-c | | | | | | | +-----------+ | | | Org | | DNS | | | | | | | +-----------+ | | +-----------+ +-----------+ | techn-c | | | +-----------+ | +-------------------> DNS OBJECT <------------------------+ +---------------------------------------------------------+ | +-----------+ | | +-----------+ +-----------+ | admin-c | | | | | | | +-----------+ | | | Org | | IpNW | | | | | | | +-----------+ | | +-----------+ +-----------+ | techn-c | | | +-----------+ | +-------------------> IpNw OBJECT <-----------------------+ +---------------------------------------------------------+ | +-----------+ | | +-----------+ +-----------+ | admin-c | | | | | | | +-----------+ | | | Org | | AsNum | | | | | | | +-----------+ | | +-----------+ +-----------+ | techn-c | | | +-----------+ | +-------------------> AsNum OBJECT <----------------------+ The disadvantage of the scheme is that generally the Organization info will be the same for all the three objects and also in most cases the administrative contacts(admin-c) and the technical contacts(techn-c) are the same. This leads to a lot of "local duplication" of information. There is no scope of avoiding it. Another design is to separate the objects based on the nature of information. The organization, admin-c and techn-c details are not held in the network objects. Instead, pointers are maintained to organization and person (admin-c and techn-c) objects. This scheme is shown in the figure below: Expires: January 2, 1994 [Page 7] Internet Draft June 1993 +-----------+ | | /| DNS |---+ / | | | / +-----------+ | / | +-----------+ +-----------+ / +-----------+ | /| admin-c | | |/ | | | / +-----------+ | Org |------| IpNW |----- | |\ | | | \ +-----------+ +-----------+ \ +-----------+ | \| techn-c | \ | +-----------+ \ +-----------+ | \ | | | \| AsNum |---+ | | +-----------+ The advantages of this method are obvious. Though the figure has been drawn for the best case, in the worst case, where the contacts and organizations are different for the DNS, IpNW and AsNum, the performance is similar to that in the earlier method. 4.3 Relation of the information with the Global Directory. ========================================================== It is clear that the primary information should be mastered in the NIC - the problem arises with the case of the secondary information. Though this information is held locally it is generally mastered at some other place. A good strategy would avoid explicit duplication of information. By explicit duplication of information we mean where the information is duplicated outside the directory framework. For example person XXXX is registered with his complete information [ Name, Address, Sex, Age, ...] in the employer, in the Locality of his residence, in the Club of which he is a member, ... . This goes against the grain of a distributed information system and makes the problem of maintaining the information more difficult. For example if the Persons address changes the change will have to be carried out at all the places, else there will be outdated information in the system. The Directory allows the creation of pointers so that the persons information remains in one place all other places refer to this place for the information by a pointer [ But that will remain transparent to the user]. As far the user is concerned he needs to maintain the information in one place only. The Directory offers several ways of handling this case Expires: January 2, 1994 [Page 8] Internet Draft June 1993 o strong coupling : maintain an alias which is a pointer to the original object. o loose coupling : maintain a seeAlso attribute which is a pointer attribute. Its existence and semantics will be understood and interpreted by user applications not by the directory protocol. This is a loose coupling. o no coupling : the less preferable alternative - the data is copied on to several places by defining additional attributes. There are relative merits and demerits of each cases. By a strong coupling the integrity is ensured. But, control over the availablilty of the information gets distributed. The remote DSA holding the original object may become unavailable causing "holes" in the local database. - The loose coupling case may cause data to get outdated. However, with the existence of the seeAlso pointers, houseKeeping programs may periodically check the correctness/integrity. - The No coupling case is the easiest in terms of implementation. But will be a nightmare in terms of ensuring integrity of the information. Along with coupling the problem of maintaining the intergrity of the distributed database arises - the design has to incorporate pruning tools that weed out dangling pointers. 4.2 Where Should The Organization-info go? ========================================== The Organization-info is necessary, for all Internet related organizations. o It is not advisable/preferable/possible to rely on respective organizations to maintain their part of the DIT and therefrom provide the Organization-info. The following are the reasons -organizations WILL be slow in joining the Directory -reliability of the access to the org's DIT cannot be taken for granted o It is not possible for some specific organization(s) [ INTERNIC, ... ] to maintain DITs of all organizations, that would be an unscalable solution. o Keeping a copy of the pertinent Organization-info would run counter to the Distributed DB concept. It would lead to duplication of data and keeping data updated will be a problem. Expires: January 2, 1994 [Page 9] Internet Draft June 1993 A framework is proposed which can reasonably accomodate all the requirements /conditions. *a copy* of all the *necessary* Organization-info is retained. Since only the *necessary* info will be kept the NIC will not be burdened to act as the repository of the org's DIT. These objects may be kept in a separate subtree of affiliated-organizations [organizations affiliated to the NIC] * The problem of information duplication/consistency will arise when the organizational DITs/DSAs do come into existence. At that stage a "shadow"ing mechanism which will attempt to maintain the data consistency may be resorted to. * The X.500/ISO 9594 :1993 implementations are expected to have appropriate shadowing mechanisms It may be noted that what is suggested is not a duplication of an entire white-pages-like structure at the NIC. It suggests an "affiliated organizations" node. The entries under this node will perhaps contain only "nicOrgAttributeSet". And it certainly wont copy/contain "ou", "pilot-person", ... entries. In effect, the affiliated organization objects will have the attributes to hold the *necessary* organization info nothing more, nothing less. Operationally, and content wise the NIC DSA will hold exactly the amount of info that is desired by the NIC. When an organization sets up its DSA and when the Organization informs the NIC about it, the NIC will set up the shadowing arrangement to obtain info on changes of interest [ and forget about it]. It may be emphasized that the entries under the "affiliated organizations" are physical entities [replicated and refined from the Master entries, if and when they exist..]. If an NIC dislikes the idea of users poring over the entries in the affiliated organizations - appropriate access control can be applied. Though duplication is unavoidable, the proposal attempts to make it transparent, by delegating the responsibility of maintaining the integrity to the Directory. The directory prohibits updates on the shadow-objects. Only Master objects can be updated... this suits us fine. Also, the shadowed subtree depth/filter can be specified making it possible to specify single objects as units of replication. Further, attributes to be shadowed can be specifed, too - thus the shadow object attributes can be a subset of those of the shaodwed object. That is just what we are looking for. [There is lot of good news in the [X.500/ISO 9594 :1993 ] document. The regular edited version is yet to come out. I recd the final draft version on Monday. The bad news about the document is that it has Expires: January 2, 1994 [Page 10] Internet Draft June 1993 become fatter. Maybe double or even triple the 1988 version :-(] 4.3 The DIT Structure. ====================== We introduce the concept of a the Internet Directory Management Domains. These are entities that provide decentralized management of Internet Related information in the directory. An IDMD will have o=Internet as the root. We refer to the tree rooted at o=Internet as the root IDMD. Conceptually it represents the administrative areas of Internet Directory. Naturally, with the growing trend of delegation, this administrative tree will be divided and further subdivided into administrative sub-domains which are IDMDs too. For example the global IDMD will be rooted at the root of the directory while a countries IDMD will be rooted under the countries entry "c=US" for example. Thus the IDMD will be a recurring structure with pointers showing the relationship. The information content of an IDMD will cover ASNumber, IPNumber, DNS, NIC infrmation, etc. Each of these will be represented as an organizational unit. For example ou=ASNo, ou = DNS, ... . The DIT structure for the DNS, IpNumber trees are discussed separately. Just for clarity, the ou = DNS@dc=jp component is likely to be mastered in c=JP@ou=Internet@ou=DNS@ dc=jp sub tree. : : o=Internet : c=JP c=XX | ....................|................. | : | : +----------+--------+-------+ : o=Internet : ou=NICs ou=IpNo ou=DNS ou=afOrg: | : | +----+---+ | : +--------+---------+-------+ : | | +----+----+ : ou=NICs ou=IpNo ou=DNS ou=afOrg: | | | | | : | | | : | | dc=jp --:----|--------|-----> dc=jp : | dbl=abc-----------------:----|---->dbl=abc | : | : | +----+----+ : ou=JPNIC -------------------------:-> ou=JPNIC dc=ac dc=ad dc=co : : : : : root IDMD : c=JPs IDMD : ========= : ========== : Also the ou=NICs will likely have pointers to the national NICs. 4.4 Directory service infrastructure. Expires: January 2, 1994 [Page 11] Internet Draft June 1993 ===================================== A minimal Directory Services infrastructure is already in place. According to a latest count of the Paradise/White Pages pilot DIT there are approximately 482 DSAs in about 30 countries covering roughly 2760 organizations and with a total population of over a million entries[ E- mail]. At the final stage of deployment one can expect the active participation of as many organizations participating in the Internet in the Directory. However there is no denying that this goal will be hard to achieve. Further the degree of difficulty will critically depend on the initial success of deployment and subsequent application development. At the initial stage of deployment we envisage large organizations that are active in networking and related services and research to be participants. We expect NICS - the larger ones to start with- [InterNic, RIPE-NIC, APNIC, JPNIC ..] and others to provide infrastructural support in the form of setting up and maintaining DSAs. Smaller organizations will need to be supported. The large organizations may possibly "rent" DIT space on their systems to the smaller organizations. The root IDMD will possibly be administered by ISOC wherefrom the administration of the subordinate parts of the IDMD tree will be delegated to other organizations. 4.5 Administrative Requirements. ================================ - an administrator - redundant DSAs - registration at the higher level To determine the higher level the general namespace guidelines will be followed. 4.6 Deployment Stages. ====================== Three stages of deployment are being contemplated 1. Put the NIC information in the Directory Put the top level DNS info in the Directory 3. Couple the DNS and the Directory that will bring the directory DNS info live. 4. Distribute the IDMD. At this stage more detailed information on the Network will be expected. Expires: January 2, 1994 [Page 12] Internet Draft June 1993 5. Mapping NIC-INFO onto the Directory. ======================================== The information held in the NIC may be mapped in the following manner: Domain information ======================================= | Attribute| Value | ======================================== | domain | assocDomain | | descr | organization | | admin-c | [adminContact] | | tech-c | [technContact] | | nserver | [primaryNameServer] | | | [secondaryNameServer] | | sub-dom:| ira |<= | dom-net:| [IpNwNumber] | | | [IpNwNumber] | | changed:| lastModifiedBy | | | lastModifiedTime | | source: | ---- |<= ======================================= Autonomous System information ======================================= | Attribute| Value | ======================================== | AsNum | asNumber | | descr | description | | AsIn | asIn | | AsOut | asOut | | Default | asDefault | | admin-c | [adminContact] | | tech-c | [technContact] | | guardIan| [asGuardian] | | remarks | conencts to Asxxx |<= | | will connect to AsXXX |<= | changed:| lastModifiedBy | | | lastModifiedTime | | source: | ---- |<= ======================================= Expires: January 2, 1994 [Page 13] Internet Draft June 1993 Network information ========================================== | Attribute| Value | ========================================== | netname: | ipNetworkImagename | | descr: | ------ | | country: | NL |<= | admin-c: | [adminContact] | | tech-c: | [technContact] | | connect: | ---- | | gateway: | [externalGateway] | | remarks: | country is really Europe |<= | rev-srv: | [inAddrServer] | | changed: | lastModifiedBy | | | lastModifiedTime | | source: | ---- | ========================================= Person information ================================= | Attribute| X500Attribute | ================================= | person: | surname/CommonName | | address | postalAddress | | phone: | telephoneNumber | | fax-no: | facsimileNumber | | e-mail: | mail | | nic-hdl | NIChandle | | changed | lastModifiedBy | | | lastModifiedTime | | source: | ---- |<= ================================= 6. References ============= [STR] S. Hardcastle-Kille, et.al, A Strategic Plan for Deploying an Internet X.500 Directory, RFC 1430, February, 1993. service. [ND] G. Mansfield, Johannsen, Th., Mark Knopper: Charting Networks in the Directory, Work in Progress, OSI-DS-37 February 1993. [IP] Johannsen, Th. et.al, Representing IP information in the X.500 Directory, Work in Progress, OSI-DS-38 June 1993. Expires: January 2, 1994 [Page 14] Internet Draft June 1993 [DNS] S. Hardcastle-Kille, X.500 and Domains, RFC 1279, November, 1991. [X.500] CCITT: The Directory - Overview of Con- cepts, Models and Services Recommendations X.500 - X.521 [IMP] Lang, R., and R. Wright, "A Catalog of Available X.500 Implementations", FYI 11, RFC 1292, SRI International, Lawrence Berkeley Laboratory, January 1992. [SPP] Johannsen, Th., G. Mansfield: The SoftPages Pro- ject; Work in Progress, OSI-DS-39 February 1992. [Schema] P. Barker, Kille, S. The COSINE and Internet X.500 Schema RFC 1274, November 1991. Expires: January 2, 1994 [Page 15]