Doc[2] Representing IP Info..

[Glenn Mansfield <[e-mail]>]

Hi again !

Enclosed please find the ascii version of the document "Representing IP 
Information in the Directory ".
The postscript version will be available soon (:-( ) via anonymous ftp.

glenn

> - - - - - - - - - - - - - DRAFT PROPOSAL - - - - - - - - - - - - -






     Representing IP Information in the X.500 Directory

            Thomas Johannsen , Glenn Mansfield
                  AIC Systems Laboratories
                       September 1992

Status of this Memo

This draft document is for unlimited distribution  for  dis-
cussion. Please send comments to the authors, or to the dis-
cussion group '[e-mail]'o.jp'. This document will be submitted
to the Internet  RFC  editor for consideration as informational 
document.

Abstract

This document describes the objects necessary to include in-
formation  about  IP  numbers in the X.500 Directory. It ex-
tends the work "Charting networks  in  the  Directory"  [ND]
where  a  general  frame work is presented  for representing
networks in the diretory. This work applies the framework to
IP  networks.  This application of the Directory is intended
to support the work of  IP  network  assigning  authorities,
NICs, as well as other applications looking for a mapping of
IP numbers to data of related networks.

1. Introduction

Information related to the Internet  Network  Infrastructure
is  stored  and  created  by a number of different organiza-
tions, such as the Network Information Center (NIC), the In-
ternet  Assigned  Numbers  Authority  (IANA), and the NSFNET
Network Operations Center (NOC). The information is in  gen-
eral  "mastered"  (stored and maintained) by these organiza-
tions 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 offers the  appropriate  technology  for
implementing this distributed method of managing network in-
frastructure information.

The following goals are accomplished by the model defined in
this document:
      -Mapping from Network Number to network, host,owner,..
      -Support of delegation of IP address blocks
      -Support of "classless" network address formats
      -Provision of several organizational images of a 
       netWork

2. Objects

The  following  directory  objects  have  been  defined   to


                      November 9, 1992





                           - 2 -


represent the IP network in the directory.

2.1 Delegated Block object

This object provides information on a block of IP  addresses
delegated to some local-authority or service provider.

The object has a  name  that  is  of  the  form  LowerLimit-
UpperLimit  where  LowerLimit  and  UpperLimit represent the
lower and upper bounds of the block. It  is  envisaged  that
when  an  IP address is being sought first the Ipgroups will
be looked into followed by an ordered  substring  search  on
the delegatedBlock object name.

Note that the above does not make any assumption  about  the
network  masks being constrained by byte boundaries. It  can
thus represent in the same framework the subnetting within a
"network  (  number)" that often happens within an organiza-
tion.

This scheme does lead to some granularity in  the  otherwise
flat  IP-number  space. Further, the granularity is signifi-
cant as it may be used to identify the administrator of  the
block - a service provider or a domain manager. E.g. it fits
well into the scheme of  aggregating  networks  for  routing
purposes as has been proposed in RFC1338.

The object is of the form:
delegatedBlock OBJECT CLASS
        SUBCLASS of top
        MUST CONTAIN
         delegatedBlockName: caseIgnoreStringSyntax
                /* semantics -> LowerLimit-UpperLimit           */
                /* LowerLimit and UpperLimit represent the lower*/
                /* and upper bounds of the address block        */
        MAY CONTAIN
         networkMask
                /* to allow classless networking */
         provider
                /* pointer to an organization object */



2.2 IP Group object

This object provides information for an IP  network  number.
Regardless  of the actual value of x, IP group objects exist
for IP numbers x.0.0.0, x.y.0.0 and x.y.z.0.  This  approach
includes "classical" class-A, -B and -C network addresses as
well as subnetworking for classes A and B  and  is  able  to
represent  number  assignment  for a group of numbers to one
organization (e.g. 193.0.0.0).

The IP group object is a non-leaf object and does not  carry
any  information  except its name (i.e. the IP number as de-



                      November 9, 1992





                           - 3 -


fined above). Subordinates of IP group  objects  are  Network
Image objects, IP group objects or IP reference objects.


ipGroup OBJECT CLASS
        MUST CONTAIN
         ipGroupName : CaseIgnoreString
                /* common name; x.0.0.0 or x.y.0.0 or x.y.z.0
                   where x, y, z in {0..255} */
        MAY CONTAIN


2.3 Organizational Network Image object

A organizational network image object is always  subordinate
to  an  IP  group object and provides information for the IP
number that gave the name for that IP  group  object.  There
might  be  several organizational network images for one and
the same IP number. In that case, several views (images) for
this network number are provided. The Organizational Network
Image object also leads to the functional view of  the  net-
work by pointing to the corresponding IpNetworkImage object.

orgNetworkImage OBJECT CLASS
        SUBCLASS of networkImage
        MUST CONTAIN
         orgNetworkImageName : CaseIgnoreString
                        /* common name; explanation see below */
        MAY CONTAIN
         orgNetworkImageOwner :  DN
                /* points to owner (org., ou, person, etc.) of this image */
         orgAssignedNetwork : DN
                /* points to orgNetworkImage that describes
                   an organizational view of the network*/
         funAssignedNetwork : DN
                /* points to ipNetworkImageObject that describes
                   the functional view of the network*/
         delegation : DN
                /* if this network is part of a delegation, this
                   attribute points to the delegation description */
         description


orgAssignedNetwork is a pointer to an entry  (preferably  of
object type orgNetworkImage which holds more information re-
lated to this IP number.  This  information  represents  the
view  of orgNetworkImageOwner. Different organizations (net-
work owner, assigning  authority,  network  providers)  will
feel the need to store different things for one and the same
network. They should do this in their "personal" orgNetwork-
Image objects which are pointed to by assignedNetwork.

The attribute orgNetworkImageName (being the common name  of
the  object  at the same time) gives the function of the or-



                      November 9, 1992





                           - 4 -


ganization rather than the name. In order  to  indicate  the
relationship  of  a organization to the network, this attri-
bute is expected to be chosen from  a  list  of  recommended
names.  This  list may grow with the number of organizations
wishing to hold their image of a network.  Currently  recom-
mended are the following identifiers:

      - owner  (for  organization  owning  the  network,  i.e.
        lines, nodes...)
      - assign (for number assigning authority, e.g. Merit)
        provider +name of  provider  (for  network  providers,
        e.g. PTTs)

2.4 IP Network Image object

ipNetworkImage OBJECT CLASS
      SUBCLASS of networkImage
      MUST CONTAIN
        ipNetworkImageName : CaseIgnoreString
                /* common name; explanation see below */
        AssociatedDomain
                /* the domain name e.g. aic.co.jp;
                   refer to RFC1279 */
       MAY CONTAIN
        ipNetworkImageOwner :  DN
                /* points to owner (org., ou, person, etc.)
                   of this image */

      /*Network Connectivity */
        externalGateway :: distinguishedNameSyntax
                /* points to one or more nodes that act as
                   gateways to other networks */
        aSPath : caseIgnoreStringSyntax
                /* reachability info for the NSFNET backbone */

      /*DNS related info ; e.g, - */
        inAddrServer : DN
        primaryNameServer : DN
        secondaryNameServer : DN

      /*Routing policy; e.g, - */
        sourceUsagePolicy :: caseIgnoreStringSyntax
                /* semantics to be defined */
        transitUsagePolicy :: caseIgnoreStringSyntax
                /* semantics to be defined */
        destinationUsagePolicy :: caseIgnoreStringSyntax
                /* semantics to be defined */

      /*Any other - */
        registrationDate :: uTCTimeSyntax
        activationDate :: uTCTimeSyntax
        onlineDate :: uTCTimeSyntax
        description




                      November 9, 1992





                           - 5 -


2.5 IP Reference object

There is one IP reference object for each  IP  address.  The
purpose of this object is to

      - tell that this IP number is already assigned to a node
      - give a pointer to a node object (see [ND])


ipRef OBJECT CLASS
        SUBCLASS of ???
        MUST CONTAIN
         ipReferenceName : CaseIgnoreString
                /* common name; value is always an IP address */
        MAY CONTAIN      assignedNode : DN
                /* points to a node object which was assigned this IP address */









































                      November 9, 1992





                           - 6 -


3 Directory tree

All objects defined above build a single tree in the  Direc-
tory.  It  is  suggested  that this tree will have a root of
type organizationalUnit within @o=Internet.

     objectClass= organizationalUnit
     organizationalUnitName= IP networks
     description= root of IP number tree

The IP network objects are arranged in a tree instead  of  a
single  flat  representation.  The  tree is one of delegated
blocks and IP groups. The delegated blocks may  reflect  the
actual  delegation of IP-address blocks or could be an arbi-
trary     blocking     to     introduce     some     logical
granularity/hierarchy  into the address space. There may
be a maximum of three levels of IP group  entries,  one  for
each  byte  x,  where  x.y.z.0  is an IP number. E.g. at the
first level one will find the entries 1.0.0.0, 2.0.0.0,  ...
255.0.0.0.  Each  of these entries has (a maximum of) 256 IP
group entries as subordinates, e.g. 2.0.0.0 has the subordi-
nates  2.1.0.0,  2.2.0.0, ... 2.255.0.0. The same applies to
the second level. The IP group object 2.1.0.0 has  itself  a
maximum  of  256  IP  group  subordinate  entries  (2.1.1.0,
2.1.2.0, ... 2.1.255.0). IP group objects of the third level
have  a  maximum  of 256 IP reference entries ("real" IP ad-
dresses) as subordinates.

                    ou=Delegated Block(DBL)0
                          I
    +-----------+---------+---------+--------+------------+
    I           I         I         I        I            I
  ipG10       ipG11     DBL10     DBL11                 DBL1N
                          I
    +----------+----------+---------+------+------+----+---+
    I          I          I         I      I      I    I   I
  ipG20      ipG21      ipg22     DBL20   DBL21          DBL2P
                      150.80.0.0
                          I
     +--------------+-----+----------+------------------------+
     I              I                I                        I
orgNwImage=owner ipNwImage    ipG=150.80.1.0          ipG=150.80.255.0
                                     +
                                     I
    +----------------+---------------+------------------------+
    I                I                                        I
nwImage=owner    ipR=150.80.1.1                     ipR=150.80.1.255










                      November 9, 1992





                           - 7 -


4 Potential Applications

A whole range of applications are coming up based on the in-
frastructural  information  provided in the scheme. A few of
them are listed below.

4.1 SoftPages[SPP]

The Soft Pages Projectotnote{by  AIC  Systems  Lab.,  Tohoku
University  Sendai,  WIDE  Internet  Japan} started with the
wish to reduce ftp traffic on crowded overseas links and na-
tional  backbones.  The basic idea is to query for files al-
ways on filestores that are nearest/cheapest  to  the users'
site.   For  that  purpose,  it  is  necessary  to  evaluate
distance/cost between the users' host and  possible  servers.
Also, it is necessary to search the contents of the servers.

SoftPages makes use of the network  infrastructure  informa-
tion  concerning  network configuration, location of servers
and their contents, the links and their charges, ...  as  is
described  in  this document. SoftPages has in fact been the
test bed for the ideas in this scheme.

4.2 NIC interface

The proposed scheme supports the framework to provide infor-
mation  similar  to the "whois" database of Network Informa-
tion centers (NICs). It is obvious that the service based on
X.500 is much more powerful due to the global and distribut-
ed database and the connection to White  Pages  information.
Presently, an experimental user agent using an e-mail inter-
face based on a development by University  of  Michigan,  is
operational. Upon a request for a person, an organization, a
network, a node or an IP number, the answer is sent back  by
e-mail.

4.3 ConMan

A   project   for   Configuration    Management    involving
route,traffic, policy, .. management, is presently ongoing as
a collaborative  effort   among   AIC,   Tohoku   University
and   the   WIDE Project, Japan, using the proposed framework.

5 Security Considerations

Security Considerations are not discussed in this Draft.










                      November 9, 1992





                           - 8 -


Author's Addresses



Thomas Johannsen                        Glenn Mansfield
Tohoku University                       AIC Systems Laboratories
Research Institute of                   6-6-3 Minami Yoshinari
Electrical Communication                Aoba-ku, Sendai 989-32
2-1-1 Katahira,Aoba-ku,                 Japan
Sendai 980, Japan                       Phone: [phone]
[e-mail]        [e-mail]


Bibliography
============

[X.500-88] CCITT:
The Directory - Overview of Concepts, Models and Services
Recommendations X.500 - X.521

[ND]
G. Mansfield, Johannsen, Th., Mark Knopper:
Charting Networks in the Directory
Draft proposal, ftp.tohoku.ac.jp:pub/spp/nd-draft.ps, October 1992.

[SPP]
Johannsen, Th., G. Mansfield:
The SoftPages Project;
Draft proposal, ftp.tohoku.ac.jp:pub/spp/spp-draft.ps, October 1992.

[OSI-DS~19]
Weider, C., M. Knopper, R. Lang:
Interim Directory Tree Structure for Network Infrastructure Information;
OSI-Directory Services Working Group Document osi-ds-19, April 1991.

[RFC 1274]
P. Barker, Kille, S.
The COSINE and Internet X.500 Schema
RFC 1274, November 1991.

[OSI-DS~25]
S.E. Hardcastle-Kille:
Representing the Real World in the OSI Directory;
Document osi-ds-25, February 1992.

[RFC 1287]
Clark, D., L. Chapin, V. Cerf, R. Braden, R. Hobby:
Towards the Future Internet Architecture;
RFC 1287, December 1991.








                      November 9, 1992