oops, no text

[[e-mail]]

You probably actually want to see the text too. Sorry about that.
	Mark


OSI Directory Services 					Mark Knopper
Working Group						Merit Network
INTERNET--DRAFT						July 1992


	Representing Networking Infrastructure Information in X.500

Status of this Memo

This internet draft suggests a method for representing information
pertaining to network infrastructure in the X.500 directory. An object
model for representing generalized network objects is proposed and
followed.  Examples of real-world network objects that may be stored in
the directory are IP Network, Autonomous System, Circuit and Node.  A
goal is to use the directory to associate organizations and contact
people with these network objects. Searches can be made by naming the
object, or by organization.

This draft document will be submitted to the RFC editor as an informational
document.  Distribution of this memo is unlimited.  Please send comments
to the authors or to the discussion group [e-mail].

Acknowledgements

Part of this text was lifted without permission from a design document
by the friendly folks at SRI, Ruth Lang and Ken Harrenstein, our
co-conspirators on the FOX project. SRI supports a prototype X.500
implementation of the WHOIS database. Ruth and Chris Weider helped
write the initial draft, and Tim Howes and Mark Smith of the University
of Michigan Unix Group reviewed several drafts. Sue Hares of Merit
provided guidance on object and attribute definitions.


INTERNET--DRAFT		X.500 Network Infrastructure	July 1992


1.0  Introduction and Goals

Information related to the Internet Network Infrastructure is stored and
created by a number of different organizations, such as the Network Information
Center (NIC), the Internet Assigned Numbers Authority (IANA), and the NSFNET
Network Operations Center (NOC). The information is in general "mastered"
(stored and maintained) by these organizations on a centralized basis, i.e. 
there is a single place to look for a definitive list of entries for these
categories.  This has worked well in the past but given the tremendous growth
of the Internet and its number of users and networks, it is essential that a
distributed scheme be used.  

The X.500 Directory standard seems to be an ideal technology for implementing
this distributed method of managing network infrastructure information. X.500
allows distributed ownership of different parts of the global Directory
Information Tree, and with replication can provide this information 
to users rapidly.  Some access control and security capabilities exist in
the current standards and additional capabilities are being developed by IETF
working groups and implementors.  Using the X.500 heirarchical structure,
this information can be organized in a fashion that is intuitive and
easily searchable by users.

This document focuses on IP Networks as the protypical network object,
but the methods suggested by this model can be generalized to other
kinds of network objects (such as autonomous systems, which are
described herein, circuits, interfaces and routers). The following
goals are accomplished by the model defined in this document:

    1. Define network objects
    2. Allow searching of objects by organization
    3. Allow searching by network number
    4. Support delegation of addressing authorities
    5. Include "special purpose" attributes for use by
       network service providers




INTERNET--DRAFT		X.500 Network Infrastructure	July 1992


2.0 Object Model

2.1 Object: network

A top level object, "network", will be defined as follows:

network OBJECT CLASS
    SUBCLASS OF top
    MUST CONTAIN {commonName}
    MAY CONTAIN {
	parentOrganization,
	administrativeContact,
	technicalContact
	}

parentOrganization ATTRIBUTE
	WITH ATTRIBUTE SYNTAX distinguishedNameSyntax

administrativeContact ATTRIBUTE
	WITH ATTRIBUTE SYNTAX distinguishedNameSyntax
		
technicalContact ATTRIBUTE
	WITH ATTRIBUTE SYNTAX distinguishedNameSyntax

It is assumed that networks of any kind can be listed in the directory
with these common attributes. The parentOrganization attribute can be
used as a pointer to the entry of an organization listed in the
directory. The administrative and technical contacts identify "person"
or "organizational role" entries in the directory.

2.2 Object: iPnetwork

An IP network is a special case of the generic "network", and
inherits its attributes as well as having a set of attributes
of its own.

iPnetwork OBJECT CLASS
    SUBCLASS OF network
    MAY CONTAIN { 
	aSpath,
	configurationDate,
	configurationHistory,
	registrationDate,
	sponsoringAgency,
	countryName,
	activationDate,
	usagePolicy,
	networkName,
	in-AddrServer,
	onlineDate,
	Source
	seeAlso
	}

Note that the first three optional attributes (aSpath, configurationDate,
and configurationHistory) are intended to be specific to a particular
network service provider. It may be possible that an entry for a
particular IP network can be found in multiple places in the directory,
with different provider-specific information in these attributes.
See section 3.3 for an example.

The other attributes contain information that is managed by the
address authority which assigned the IP network number. There is
only one such authority for any given IP number so this information
should not be found in duplicate entries for an IP number.

The AS path includes reachability information for the NSFNET backbone,
including route metric and AS number. This is used as an exapmle of a
service provider-specific use of an attribute. There can be multiple AS
paths for alternate routes. This attribute is currently specified as a
character string, but this syntax may need to be changed upon further
study.

aSPath ATTRIBUTE
	WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax

IP networks are named by their IP number represented as a string,
eg. "cn=35.0.0.0". The NIC also requires that each network have a
name for internal use. 

networkName ATTRIBUTE
	WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax

The NIC currently requires specification of a sponsoring government
agency and a usage policy for each IP network. The syntax for usage
policy is currently string but may need to be changed after further
study.

sponsoringAgency ATTRIBUTE
	WITH ATTRIBUTE SYNTAX distinguishedNameSyntax

usagePolicy ATTRIBUTE
	WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax



The in-addr server is assumed to be a computer named in the directory.

in-AddrServer ATTRIBUTE
	WITH ATTRIBUTE SYNTAX distinguishedNameSyntax

Configuration and online dates are with respect to NSFNET or other
network service provider.

configurationDate ATTRIBUTE
	WITH ATTRIBUTE SYNTAX uTCTimeSyntax

onlineDate ATTRIBUTE
	WITH ATTRIBUTE SYNTAX uTCTimeSyntax

Configuration history is currently a text string but could be
changed to allow multiple entries with date and configuration 
information. This is for further study.

configurationHistory ATTRIBUTE
	WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax


"Source" names the organization that is responsible for the
information in this entry. This is a transitional attribute,
that is until all address authorities have started using the
X.500 system, this field can be used simply as a pointer to
the authoritative organization while the entry is stored
in the centralized subtree.

source ATTRIBUTE
	WITH ATTRIBUTE SYNTAX distinguishedNameSyntax

2.3 Object: autonomousSystem

An Autonomous System is a collection of networks grouped into a
common routing domain with a single owning authority. Typically
this might be a mid-level network. The directory will associate
contact and authority information with AS name and number, as
well as giving routing information related to the AS.

autonomousSystem OBJECT CLASS
    SUBCLASS OF network
    MAY CONTAIN { 
	constituentNetwork,
	routingMetric,
	asName,
	sponsoringAgency
	}

The AS contains multiple consitituent networks, so this attribute would
normally appear multiple times in the entries.

constituentNetwork ATTRIBUTE
	WITH ATTRIBUTE SYNTAX distinguishedNameSyntax

The routing metric as well as the above constituent network attributes
are currently in character string format, but this could be made 
more structured in future. It may also be necessary to provide
a metric/network pairing relationship.

routingMetric ATTRIBUTE
	WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax

The AS name is an arbitrarily named string supplied by the owner.
In the directory AS's are named by their number. The name usually
gives a clue about the owning organization.

asName ATTRIBUTE
	WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax

Sponsoring agency is a field collected by the NIC and currently
included in the WHOIS database.

sponsoringAgency ATTRIBUTE
	WITH ATTRIBUTE SYNTAX distinguishedNameSyntax


3.0 Directory Information Tree Organization

A requirement for structuring the network-related information is
to allow distribution of address authority using heirarchical
delegation. The DIT structure should reflect the delegated
authority and make it easier for the new authority to manage
its entries. The following three models and uses are accomodated
by this structure, and are illustrated in a potential order
of a transition from the current Internet address assignment model.


3.1 Organization Assuming Current, Centralized Address Authority Model
    for Internet Registry

In this model a single organization is the address authority for
all IP network numbers. In the tree for this organization can
be found a large single flat subtree containing all IP network
numbers. Within each IP network number entry can be found all
attributes associated with address authority information. See
Figure 1 (nii.fig1.ps).

In order to support searching by organization, it is suggested that
organizations which own IP networks can support alias entries refering
to the master entries within the main directory. This is illustrated
in Figure 1. [Note: Figures are available by FTP from merit.edu in
pub/x.500/nii.fig*.]




3.2 Delegated Address Authority Model

In this model there can be up to three entries in the DIT for a
particular IP network. The master list of all IP nets would still exist
but some entries would simply be aliases refering to the master
information existing within the domain of a delegated address
authority. The actual owning organization of the IP net would still
have an alias pointing to either the main NIC's entry for the network
or to the service provider's entry.  Figure 2 (nii.fig2.ps) shows that
a "not delegated" entry is wholly contained within the "o=Internet"
master directory for IP Networks, but delegated entries are listed
there as aliases. "Advanced Altered Performance Inc." is an example
network service provider who might be a delegated address authority for
a block of addresses.




3.3 Special Purpose Attributes Supported by a Service Provider

It may be the case that a particular service provider (who may or
may not be the delegated address authority for a network) would
hold yet another entry for the network. This entry would contain
information specific to that service provider but would not contain
any of the attributes designated for use by the address authority
(unless it was also that authority). In the following example 
(Figures 3, nii.fig3.ps), the NIC has not delegated the address authority
but a service provider has created an entry for the network.




4.0 Author's Address

	Mark Knopper, [e-mail]
	Merit Network, Inc.
	1071 Beal Avenue
	Ann Arbor, MI 48109

5.0 References

S.E.  Kille.   X.500  and  domains.   Research  Note  RN/89/47,
         Department  of  Computer  Science,  University  College  Lon-
         don,  May 1989.   Also Internet Draft:  DRAFT-UCL-KILLE-
         X500DOMAINS-00.PS
	 				
S.E. Kille. The COSINE and Internet X.500 Naming Architecture.
	 Internet Draft: DRAFT-IETF-OSIDS-COSINEX500-02.TXT

S.E. Kille. Representing Real World Objects in the Directory,
	OSI-DS 25

Cerf, V. RFC 1174