Doc[1] Charting Networks

[Glenn Mansfield <[e-mail]>]

Hi again !

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


glenn

> - - - - - - - - - - - - - DRAFT PROPOSAL - - - - - - - - - - - - -
 
 
               Charting Networks in the Directory
 
        Glenn Mansfield  Thomas Johannsen  Mark Knopper
 
                       October 1992
 
 
 
 Status of this Memo
 
 
 This draft document  is for  unlimited  distribution for  discussion. 
 Please   send comments  to the   authors,  or to the discussion  group
 '[e-mail]'o.jp'. This document will be  submitted to the  Internet RFC
 editor for consideration as informational document.
 
 
 Abstract
 
 
 There is a need   for   a framework  wherein the  infrastructural  and
 service related information  about communication networks  can be made
 accessible from all places and at all  times in a reasonably efficient
 manner and with reasonable  accuracy.  This document presents  a model
 in which  a communication  network  with all its  related details  and
 descriptions can be  represented  in the X.500  Directory. Schemas  of
 objects and  their attributes which may  be used for  this purpose are
 presented.  The model envisages  physical objects and several  logical
 abstractions of the physical objects.
 
 
 1. Introduction
 
 
 The rapid  and  widespread use  of computer networking has highlighted
 the importance  of  holding  and   servicing  information  about   the
 networking infrastructure itself. The  growing and  active interest in
 network  management, which has  concentrated  mainly  in the areas  of
 fault and   performance  management on  a   local  scale,  is severely
 constrained by the lack of any organized pool of information about the
 network infrastructure itself.  Some attempts  have  been made,  on  a
 piecemeal basis, to provide a larger view of some particular aspect of
 the  network (  WHOIS,  DNS,   ..  in the   case   of  the   Internet;
 \cite{whois}, \cite{dns}).  But to date,  little or no effort has been
 made  in setting up  the   infrastructural  framework,  for   such  an
 information pool. In this work we explore the possibility of setting up
 a framework to hold and serve the  infrastructural  information of a 
 network.
 

 2. Infrastructural information requirements 
 
 
 Network  operation  and  management  requires   information  about the
 structure of  the  network,  the nodes,  links and  their properties. 
 Further, with current networks extending literally  beyond bounds, the
 scope  of  the information covers  networks beyond  the  span of local
 domain   of authority  or  administration.   When   the   Network  was
 relatively small   and  simple the  map    was already  known to   the
 knowledgable network  administrator.   Based   on this knowledge   the
 course of the packets to  different destinations would be charted. But
 presently the  size of the Network is  already beyond such usages. The
 current  growth of the Network is  near explosive. This is giving rise
 to the urgent necessity of having infrastructural  and service related
 information  made accessible from all places  and at   all  times in a
 reasonably  efficient manner and with  reasonable accuracy. This 
 information is referred to as 'network map' in the rest of this paper .
 
 The network map should meet the following requirements:
 
 1. Show the interconnection between the various network elements. This 
    will basically represent
    the Network as a connected graph where nodes represent objects like 
    gateways/workstations/subnetworks and edges represent the connecting 
    circuits. 
 2. Show properties of these interconnections. Attributes of edges 
    represent various properties of interconnections - for example speed, 
    charge, etc.
 3. Show the functions of the various network elements. Attributes 
    of nodes describe various functions of the network element in question. 
    Functions include services offered by a network element.  
 4. Contain various name and address information of the network elements
 5. Contain information about various administrative and management
    details related to the network element.
 6. Contain the policy related information, part of which may be private
    while the other part may be made public.
 
 
 Using this map the following services may be provided
 
 1. Configuration management:
   - Display the physical configuration of a network, i.e. nodes and
      their physical interconnections
   - Display the logical configuration of a network, i.e. nodes and
      their logical interconnections.
 
 2.  Route management:
   - Find alternate routes by referring to the physical and logical 
     configurations.
   - Generate routing tables considering local policy and policy
     of transit domains
   - Check routing tables for routing loops, non-optimality, 
     incorrect paths, etc.
 
 3. Fault management: In case of network failures alternate routes may
    be found and used to bypass the problem node or link.
 4. Service management: Locate various services and servers in the
    Network.
 5. Optimization: The information available can be used to carry out 
    various optimizations, for example cost, traffic, response-time, etc.
 6. Provide mappings between the various names and addresses of 
    elements
 7. Depict administrative/autonomous domains.
 8. Network Administration and Management: References to people
    responsible for administering and technically maintaining a network
    will be useful.
 
 Examples of such usages are described in \cite{ip}, \cite{fn}.
 

 3. The Model
 
 
 For representing networks in the Directory we model a network as follows. 
 A network comprises of:
 
  1. a possibly null set of nodes,
  2. a possibly null set of lines,
  3. a possibly null set of (sub)networks.
 
 With this model,  hierarchies in network  relationship can be  shown. 
 Network maps always depict  information according to this model, i.e. 
 in terms of nodes, lines and subnetworks.
 
 The network model will be used for several levels  of abstraction of a
 network as discussed below.
 
 Just  as   there  are several  maps  of  the  same geographical domain
 (political, natural  ...)  one can envisage  several views of the same
 physical network. A  view  (called ``image'' in  the  remainder) could
 pertain to a particular  protocol suite (IP/OSI/..), an administrative
 domain or, purpose. By this way, images are an abstract representation
 of physical elements.  An  image generally will be  more than a simple
 filter superimposed on the physical picture. Images  have properties 
 that are not provided for in the physical map.
 
 Schemes for physical networks and logical  images of physical networks
 are defined in section \ref{schemes}.
 
 To represent  the relationship  of  physical  and logical  views of  a
 network we propose a model as follows:
 
  - The elements of the model are Communication Objects(COs), 
    which are either a Physical Communication Object (PCO) or an Image 
    Communication Object (ICO).
    The definition of PCOs and ICOs follow:
  
   o Physical Communication Object (PCO). These are the physical things 
     that make a communication network like computers, modems, bridges, 
     gateways, circuits, etc.
   o Image Communication Object (ICO). An Image Communication Object
     is an abstract view of the PCO. It may represent the 
     view of a provider, a user, a particular type of usage (OSI, IP,
     XNS, SNA, ..) or a particular type of service.
     It is obvious a PCO may have several ICOs.
 
  - Instances of COs are networks, nodes and lines according to the
    above given network model.
 
 It may be noted that this scheme allows different protocols to coexist
 in   the Directory  in harmony  -  IP,   XNS,  OSI  networks and their
 interrelation can be represented and accessed in a fashion independent
 of the   source/destination   network, namely,  using the  OSI   X.500
 protocol.
 
 A CO  will in general  have  a name and  possibly  a  reference to the
 technical and/or administrative contact pertaining to the CO.
 
 PCO and ICOs are  subclasses of a CO and  will contain descriptions of
 the physical and logical properties respectively, of the object.
 
 All objects are defined in section \ref{schemes}.
 
 
 4. Position in the Directory Information Tree (DIT)
 
 
 Information about networks will be contained in the DIT as subordinate
 of the organization maintaining  the  network. The network  model gets
 mapped into a tree  structure for network elements.  There is one {\em
 network} object   giving   general   descriptions  of  the   network. 
 Subordinates of this network object are {\em node  } and  {\em  line }
 objects for each  element  present in   the network. A network can  be
 physically or logically subdivided into several (sub)networks. In this
 case, a network entry will have network objects as  subordinates which
 again  build  the  same  structure.  These   entries   may be kept  as
 subordinates of organizationalUnit entries as well, with pointers from
 the "root" network.
 
 This structure  holds  for  physical  and  logical elements.  Physical
 elements are  named network, node and  line, and logical  elements are
 named networkImage, nodeImage and lineImage.
 
 [..figure missing here..]
 
 Figure 1: Part of the Directory Information Tree showing relations of
 White Pages and network objects.
 
 
 5. Proposed Schemes
 
 
 A physical network  comprises of wires  and machines. The physical map
 of the network will show the interconnections of these  nodes by these
 circuits.
 
 For each physical network element, one or  more images may exist.  The
 type  of images can grow along  with the requirements.  Also, the user
 and provider of an  image will view  an  object differently; further a
 user of an  object may also  be providing  the   services of the  same
 object to another user.  Appropriate attributes are introduced to take
 care of this relationship.
 
 Problems that are addressed in the scheme:
 
  - Avoiding data duplication
  - Preserving administrative boundaries/controls. 
  - Simple representation (minimal number of pointers)
  - Security: Though no special emphasis has been placed in this work 
    we believe the X.500 access control policies will provide reasonable
    privacy.
 
 Problems that are not addressed:
 
  - Caching policies, etc.: to be decided  locally
 
 5.1 Communication Object Classes
 
 The object classes  introduced  in section \ref{model}. are defined as
 follows:
 
 CommunicationObject OBJECT CLASS
     SUBCLASS of top
 MAY CONTAIN {
  	technContact 	:: distinguishedNameSyntax,
 		/* technical contact person */ 
  	adminContact 	:: distinguishedNameSyntax,
 		/* adminstrative contact person */ 
 	description 	:: as already defined
         }
 
 PhysicalCommunicationObject OBJECT CLASS
     SUBCLASS of CommunicationObject 
 MAY CONTAIN {
 	localityName 	:: as already defined }
 
 ImageCommunicationObject OBJECT CLASS
     SUBCLASS of CommunicationObject 
 MAY CONTAIN {
 	type :: caseIgnoreStringSyntax,
 		/* e.g. view of provider/user/IP/OSI/... */ 
 	PCO :: distinguishedNameSyntax
 		/* points to physical object the image 
 		is related to */ 
 	user :: distinguishedNameSyntax, 
 		/* points to user of element */ 
 	provider :: distinguishedNameSyntax  
 		/* points to provider of element */ 
 	sponsoringAgency :: distinguishedNameSyntax 
 		/* points to organization, organizationalUnit or 
 		similiar entry */
         }
 
 5.2 Physical elements
 
 The   following  objects describe   network  elements without   saying
 anything about their  usage.  All objects  inherit  properties of  the
 PhysicalCommunicationObject class.
 
 5.2.1 Network
 
 The network object supplies  general descriptions which are common for
 a set of nodes and circuits comprising one network.
 
 network OBJECT CLASS
     SUBCLASS of PhysicalCommunicationObject
     MUST CONTAIN { 
 	networkName 	:: caseIgnoreStringSyntax }
     MAY CONTAIN {
 	externalGateway :: distinguishedNameSyntax
 		/* points to one or more nodes that act as gateways to
 		   other networks */
 	configurationDate ::  uTCTimeSyntax
 	configurationHistory :: caseIgnoreStringSyntax
        }
 
 
 5.2.2 Node
 
 The node object describes any  kind  of device that  is  part  of  the
 network, such as simple nodes, printer, bridges.
 
 node OBJECT CLASS
     SUBCLASS of PhysicalCommunicationObject
     MUST CONTAIN {
 	 nodeName 	:: caseIgnoreStringSyntax }
     MAY CONTAIN {
 	machineType	:: caseIgnoreStringSyntax,
 		/* e.g. main frame, work station, PC, printer; 
 			might include manufacturer */
 	OS		:: caseIgnoreStringSyntax,
 		/* e.g. VM, UNIX, DOS; might include release */
         }
 
 Each node   object will  have    one or more   {\em  port} objects  as
 subordinates. Port objects provide information about interfaces of the
 node and connectivity.
 
 port OBJECT CLASS
     SUBCLASS of PhysicalCommunicationObject
     MUST CONTAIN {
 	portName 	:: caseIgnoreStringSyntax }
     MAY CONTAIN {
 	portAddress	:: caseIgnoreStringSyntax,
 		/* physical address (e.g. Ethernet board number) */
 	connectedLine	:: distinguishedNameSyntax,
 		/* pointer to object of circuit to which this port is
 		   connected */
         }
 
 
 5.2.3 Line
 
 The  properties of the  physical connection  between  network elements
 (nodes) may be  traced by a  concatenation of  circuits.  Line objects
 hold   information about the  type   of circuits (medium, broadcast or
 point-to-point, etc.)  and  properties  (speed  etc.). Note  that  the
 physical connection element "circuit" can  provide service for several
 protocols at a time. A lineImage for  a particular protocol  will give
 the specificiations that apply for this protocol only.
 
 line OBJECT CLASS
     SUBCLASS of PhysicalCommunicationObject
     MUST CONTAIN {
         lineName 	:: caseIgnoreStringSyntax }
     MAY CONTAIN {
 	lineType	:: caseIgnoreStringSyntax,
 		/* architecture of this network/line: 
 			proposed values:  bus, ring, star, mesh,
 					point-to-point */
 	media		:: caseIgnoreStringSyntax,
 		/* physical media: copper, fiber optic */
 	speed		:: numericStringSyntax,
 		/* nominal bandwidth, e.g. 64 kbps */
 	charge		:: numericStringSyntax,
 		/* to be paid by user for transmission 
 			of data (per packet/byte/time...)  */
 	cost		:: numericStringSyntax,
 		/* to be paid to service provider for use of line 
 			(per month, traffic...)  */
 	traffic		:: numericStringSyntax
 		/* (average) use in percent of nominal bandwidth */
         }
 
 5.3 Logical Elements
 
 An abstract view  of  a  physical  element  is  called  image  in this
 document.  The word image gets appended to the object type, leading to
 the new  objects networkImage, nodeImage,   lineImage and  portImage. 
 Images will either build Directory trees of themselves or be stored as
 part of the physical network tree (see section \ref{DIT}.).
 
 Image objects inherit properties of the ImageCommunicationObject class.
 
 Each image object has specific attributes which  vary depending on the
 point of view (IP, OSI,  ...). Therefore, in the following  a complete
 and general list of attributes cannot be given. We recommend to define
 subclasses of Image classes for each logical view.
 
 Examples for an IP-view are given in \cite{ip}.
 
 5.3.1 Network
 
 There may  be  several network images  for one  and the  same physical
 network: one for each protocol, application, etc.
 
 networkImage OBJECT CLASS
     SUBCLASS of ImageCommunicationObject
 
 5.3.2 Node
 
 Name and functionality within the  network might vary  for a node from
 protocol  to protocol considered. In particular,  a  node might act as
 gateway for one protocol  but  not  for the other. Routing  policy  is
 stored in the case of policy gateways.
 
 
 nodeImage OBJECT CLASS
     SUBCLASS of ImageCommunicationObject
 
 As with physical  nodes,  nodeImages  have   ports (portImages)  which
 describe connectivity to other  network elements. PortImages  are only
 given if the protocol is establishing connections via this port.
 
 portImage OBJECT CLASS
     SUBCLASS of ImageCommunicationObject
 
 5.3.3 Line
 
 ImageLines represent channels  on physical circuits  that are used for
 one  specific  protocol. Attributes  of   the  physical line    (e.g. 
 bandwidth) can be different for each image of this line.
 
 lineImage OBJECT CLASS
     SUBCLASS of  ImageCommunicationObject
 
 6. Security Considerations
 
 Security Considerations are not discussed in this draft. However, data
 access control will be taken care of by means of the Directory (namely
 X.509).
 
 
 7. Authors' 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 		                 Japan
 Aoba-ku, Sendai 980	
 Japan			                 Phone: [phone]
 
 EMail: [e-mail]  EMail: [e-mail]
 
 
 	Mark Knopper 
 	Merit Network, Inc. 
 	1071 Beal Avenue
 	Ann Arbor, MI 48109 
 
 EMail: [e-mail] 
 
 
 References
 
 [HK 91]
 Hardcastle-Kille, S.:
 X.500 and Domains; 
 RFC 1279, November 1991.
 
 
 [IP]
 Johannsen, Th., G. Mansfield:
 Representing IP information in the X.500 Directory; 
 Draft proposal, ftp.tohoku.ac.jp:pub/spp/ip-draft.ps, October 1992.
 
 [SPP]
 Johannsen, Th., G. Mansfield:
 Representing File information in the X.500 Directory; 
 Draft proposal, ftp.tohoku.ac.jp:pub/spp/fn-draft.ps, October 1992.
 
 [OSI-DS-14]
 Weider, Ch., M. Knopper:
 Interim Schema for Network Infrastructure Information in X.500;
 Internet Draft osi-ds-14, March 1991.
 
 [OSI-DS-16]
 Weider, Ch., M. Knopper:
 Schema for Network Information Center (NIC) Profiles in X.500;
 Internet Draft osi-ds-16-01, March 1992.
 
 
 [OSI-DS-19]
 Weider, Ch., M. Knopper, R. Lang:
 Interim Directory Structure for Schema for Network Infrastructure Information

 Internet Draft osi-ds-19, April 1991.
 
 [OSI-DS-??]
 Knopper, M:
 Representing Networking Infrastructure Information in X.500;
 Internet Draft, July 1992.
 
 [WHOIS]
 Harrenstein, K., M.K. Stahl, E.J. Feinler:
 NICNAME/WHOIS;
 RFC 954, October 1985.
 
 [DNS]
 Mockapetris, P.V.:
 Domain names - implementation and specification;
 RFC 1035, November 1987.
 
 - - - - - - - - - - - - - - - - END of DRAFT PROPOSAL - - - - - - - - -