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]
JPNICはインターネットの円滑な運営を支えるための組織です
- JPNIC
-
IPアドレス・AS番号
指定事業者向け各種申請手続/お知らせ
一般ユーザーの方
-
JPNIC会員
会員向け情報/各種変更手続
入会のご案内
