home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1600s / rfc1609.txt < prev    next >
Text File  |  1994-03-23  |  30KB  |  844 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       G. Mansfield
  8. Request for Comments: 1609                        AIC Systems Laboratory
  9. Category: Experimental                                      T. Johannsen
  10.                                                       Dresden University
  11.                                                               M. Knopper
  12.                                                     Merit Networks, Inc.
  13.                                                               March 1994
  14.  
  15.  
  16.                 Charting Networks in the X.500 Directory
  17.  
  18. Status of this Memo
  19.  
  20.    This memo defines an Experimental Protocol for the Internet
  21.    community.  This memo does not specify an Internet standard of any
  22.    kind.  Discussion and suggestions for improvement are requested.
  23.    Distribution of this memo is unlimited.
  24.  
  25. Abstract
  26.  
  27.    There is a need for a framework wherein the infrastructural and
  28.    service related information about communication networks can be made
  29.    accessible from all places and at all times in a reasonably efficient
  30.    manner and with reasonable accuracy.  This document presents a model
  31.    in which a communication network with all its related details and
  32.    descriptions can be represented in the X.500 Directory. Schemas of
  33.    objects and their attributes which may be used for this purpose are
  34.    presented.  The model envisages physical objects and several logical
  35.    abstractions of the physical objects.
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Mansfield, Johannsen & Knopper                                  [Page 1]
  59.  
  60. RFC 1609        Charting Networks in the X.500 Directory      March 1994
  61.  
  62.  
  63. Table of Contents
  64.  
  65.       1. Introduction                                       2
  66.       2. Infrastructural information requirements           2
  67.       3. The Nature of the Network Map - The X.500 Solution 4
  68.       4. The hierarchical model of a network                5
  69.       4.1 Network maps                                      5
  70.       4.2 Representation in the X.500 Directory             6
  71.       5. Position in The Directory Information Tree(DIT)    7
  72.       6. Proposed Schemes                                   8
  73.       6.1 Communication Object Classes                      9
  74.       6.2 Physical elements                                10
  75.       6.2.1 Network                                        10
  76.       6.2.2 Node                                           11
  77.       6.2.3 NetworkInterface                               12
  78.       6.3 Logical Elements                                 12
  79.       6.3.1 Network                                        13
  80.       6.3.2 Node                                           13
  81.       6.3.3 NetworkInterface                               13
  82.       7. Security Considerations                           14
  83.       8. Authors' Addresses                                14
  84.       9. References                                        15
  85.  
  86. 1. Introduction
  87.  
  88.    The rapid and widespread use of computer networking has highlighted
  89.    the importance of holding and servicing information about the
  90.    networking infrastructure itself.  The growing and active interest in
  91.    network management, which has concentrated mainly in the areas of
  92.    fault and performance management on a local scale, is severely
  93.    constrained by the lack of any organized pool of information about
  94.    the network infrastructure itself. Some attempts have been made, on a
  95.    piecemeal basis, to provide a larger view of some particular aspect
  96.    of the network (WHOIS, DNS, .. in the case of the Internet; [1],
  97.    [2]).  But to date, little or no effort has been made in setting up
  98.    the infrastructural framework, for such an information pool. In this
  99.    work we explore the possibility of setting up a framework to hold and
  100.    serve the infrastructural information of a network.
  101.  
  102. 2. Infrastructural information requirements
  103.  
  104.    Network operation and management requires information about the
  105.    structure of the network, the nodes, links and their properties.
  106.    Further, with current networks extending literally beyond bounds, the
  107.    scope of the information covers networks beyond the span of local
  108.    domain of authority or administration.  When the Network was
  109.    relatively small and simple the map was already known to the
  110.    knowledgable network administrator.  Based on this knowledge the
  111.  
  112.  
  113.  
  114. Mansfield, Johannsen & Knopper                                  [Page 2]
  115.  
  116. RFC 1609        Charting Networks in the X.500 Directory      March 1994
  117.  
  118.  
  119.    course of the packets to different destinations would be charted. But
  120.    presently the size of the Network is already beyond such usages. The
  121.    current growth of the Network is near explosive. This is giving rise
  122.    to the urgent necessity of having infrastructural and service related
  123.    information made accessible from all places and at all times in a
  124.    reasonably efficient manner and with reasonable accuracy. In the rest
  125.    of this work a network is the media for transmitting information.
  126.    Network elements are equipment with one or more network interfaces
  127.    whereby it is possible to exchange information with the network.
  128.    Network elements with multiple interfaces e.g.,
  129.    gateways/routers/bridges/repeaters...  may be used to connect
  130.    networks.  Network related information, referred to as 'network map'
  131.    in the rest of this paper, should
  132.  
  133.    1. Show the interconnection between the various network
  134.       elements. This will basically represent the Network as a graph
  135.       where vertices represent objects like gateways/workstations/
  136.       subnetworks and edges indicate the connections.
  137.  
  138.    2. Show properties and functions of the various network elements
  139.       and the interconnections. Attributes of vertices will represent
  140.       various properties of the objects e.g., speed, charge, protocol, OS,
  141.       etc. Functions include services offered by a network element.
  142.  
  143.    3. Contain various name and address information of the networks
  144.       and network elements
  145.  
  146.    4. Contain information about various administrative and management
  147.       details related to the networks and network elements.
  148.  
  149.    5. Contain the policy related information, part of which may be
  150.       private while the other part may be made public.
  151.  
  152.    Using this map the following services may be provided
  153.  
  154.    1. Configuration management:
  155.  
  156.       - Display the physical configuration of a network,
  157.         i.e., nodes and their physical interconnections
  158.       - Display the logical configuration of a network,
  159.         i.e., nodes and their logical interconnections.
  160.  
  161.    2. Route management:
  162.  
  163.       - Find alternate routes by referring to the physical
  164.         and logical configurations.
  165.       - Generate routing tables considering local policy and
  166.         policy of transit domains
  167.  
  168.  
  169.  
  170. Mansfield, Johannsen & Knopper                                  [Page 3]
  171.  
  172. RFC 1609        Charting Networks in the X.500 Directory      March 1994
  173.  
  174.  
  175.       - Check routing tables for routing loops,
  176.         non-optimality, incorrect paths, etc.
  177.  
  178.    3. Fault management: In case of network failures
  179.       alternatives may be found and used to bypass the
  180.       problem node or link.
  181.  
  182.    4. Service management: Locate various services and
  183.       servers in the Network.
  184.  
  185.    5. Optimization: The information available can be used
  186.       to carry out various optimizations, for example cost,
  187.       traffic, response-time, etc.
  188.  
  189.    6. Provide mappings between the various names and
  190.       addresses of elements
  191.  
  192.    7. Depict administrative/autonomous domains.
  193.  
  194.    8. Network Administration and Management: References to
  195.       people responsible for administering and technically
  196.       maintaining a network will be useful.
  197.  
  198.    Examples of such usages are described in [3], [4].
  199.  
  200. 3. The Nature of the Network Map - The X.500 solution
  201.  
  202.    Implementing and maintaining a detailed map of the network poses a
  203.    serious problem.  The scope of the map is global and the network
  204.    itself is expanding.  Some of the problems that are peculiar to the
  205.    network map are listed below.
  206.  
  207.    o The Network configuration is quasi-static. Nodes,
  208.      links and networks are being added,updated and deleted
  209.      someplace or the other.
  210.  
  211.    o The Network is huge and geographically distributed.
  212.  
  213.    o The network spans several political and administrative
  214.      areas. The related information is also controlled and
  215.      maintained in a distributed fashion.
  216.  
  217.    In short, global network configuration information is unwieldy and
  218.    growing continuously.  It is impossible to service such information
  219.    in a centralized fashion. There is need for a distributed framework
  220.    which allows users and applications to access information about
  221.    users, services, networks, ... easily and globally.  The OSI X.500
  222.    Directory services [5] provides a rich framework to support a
  223.  
  224.  
  225.  
  226. Mansfield, Johannsen & Knopper                                  [Page 4]
  227.  
  228. RFC 1609        Charting Networks in the X.500 Directory      March 1994
  229.  
  230.  
  231.    globally distributed information service system.  The X.500 Directory
  232.    is intended to be a very large and highly distributed database. It is
  233.    structured hierarchically with entries arranged in the form of a tree
  234.    in which each object corresponds to a node or an entry. Information
  235.    is stored about an object as a set of attributes.
  236.  
  237. 4. The hierarchical model of a network
  238.  
  239.    For representing networks in the Directory we use the following
  240.    hierarchical model.
  241.  
  242.    A network is the media for transmitting information with zero or more
  243.    network elements each having at least one network interface on the
  244.    media. The media may be any kind of a line (physical circuit/virtual
  245.    circuit), or a collection of interconnected networks.
  246.  
  247.        <  The postscript version of this document  >
  248.        <  has a figure here. However, the figure   >
  249.        <is too complex to be drawn in simple ASCII.>
  250.  
  251.  Figure 1:  Simple and composite networks and their mapping to the DIT.
  252.  
  253.    The model allows hierarchy of subnetworks.  Network elements with
  254.    multiple interfaces may act as external gateways to the attached
  255.    network and to networks higher up in the hierarchy.  Thus, a gateway
  256.    may be the external gateway of several networks which are either
  257.    interconnected or have a hierarchical relationship.
  258.  
  259.    A network may be simple consisting of zero or more network elements
  260.    or composite consisting of several sub-networks.  Examples of simple
  261.    networks are ethernets, optical fiber/copper cables, free space, .. .
  262.  
  263. 4.1 Network Maps
  264.  
  265.    Using the above model it is straight forward to draw the topological
  266.    graph of the network where the vertices represent the components of
  267.    the network and edges indicate the connections.  For visual
  268.    representation the graph may be translated to a more "physical"
  269.    illustration (figure 1).
  270.  
  271.    Just as there are several maps of the same geographical domain
  272.    (political, natural...)  one can envisage several views of the same
  273.    network and its components. A view (called "image" in the remainder)
  274.    could pertain to a particular protocol suite (IP/OSI/...), an
  275.    administrative domain or purpose.  Using images, several abstractions
  276.    of the same object are possible.
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Mansfield, Johannsen & Knopper                                  [Page 5]
  283.  
  284. RFC 1609        Charting Networks in the X.500 Directory      March 1994
  285.  
  286.  
  287. 4.2 Representation in the X.500 Directory
  288.  
  289.    To represent the various images of networks and its components along
  290.    with the real-image relationship among the various objects we
  291.    introduce the following classes of objects:
  292.  
  293.    o Communication Object Class (CO): All objects defined
  294.      furtheron in this document belong to this class.
  295.      Common attributes for all communication objects are
  296.      defined in section 6.
  297.  
  298.    o Physical Communication Object Class (PCO): A subclass
  299.      of CO-class, this class defines common properties for
  300.      all objects representing physical communication objects.
  301.  
  302.    o Image Communication Object Class (ICO): A subclass of
  303.      CO-class, this class defines common properties for all
  304.      objects representing images of communication objects.
  305.  
  306.    The above classes sort communication objects into physical or image
  307.    object.  As is implied in the nomenclature a physical object will
  308.    have several attributes describing it physical properties - location,
  309.    weight, size, ....  etc.  An image object will have an Image-of
  310.    attribute. The Image-of attribute will point to a physical object or
  311.    to another image object.
  312.  
  313.    Using this schema it is possible to represent the case of several
  314.    logical network systems (running different protocol stacks - IP, XNS,
  315.    SNA, OSI, ...) which coexist on the same physical network.
  316.    Information related to different types of networks, no matter what
  317.    the underlying communication protocol is, will reside in the
  318.    Directory in harmony.  Also, their interrelation will be represented
  319.    and accessed in a fashion independent of the source/destination
  320.    network, namely, using the OSI X.500 protocol.
  321.  
  322.    Schemes for physical networks and logical images of physical networks
  323.    are defined in section 6.
  324.  
  325.    All objects are defined in section 6.
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Mansfield, Johannsen & Knopper                                  [Page 6]
  339.  
  340. RFC 1609        Charting Networks in the X.500 Directory      March 1994
  341.  
  342.  
  343.                                               ...............
  344.                                              :              :
  345.                                              :   IP    OSI  :
  346.                                              :  +-+    +-+  :
  347.                                              :  |A|    |B|  :
  348.                              NetWork  -----> :  +-+    +-+  :
  349.                              /    \          :   |      |   :
  350.                             /      \         : ============ :
  351.                            /        \        :      |       :
  352.                           /          \       :     +-+      :
  353.                          /            \      :     |C|      :
  354.                         /              \     :     +-+      :
  355.                    OSI-image        IP-image :   IP + OSI   :
  356.                        |                |    +..............+
  357.                        V                V
  358.                      ........       ........
  359.                      :      :      :       :
  360.                  IP  : OSI  :      :   IP  : OSI
  361.                 +-+  : +-+  :      :  +-+  : +-+
  362.                 |A|  : |B|  :      :  |A|  : |B|
  363.                 +-+  : +-+  :      :  +-+  : +-+
  364.              ....|...:  |   :      :   |   :..|...
  365.              : ============ :      : ============ :
  366.              :      |       :      :      |       :
  367.              :     +-+      :      :     +-+      :
  368.              :     |C|      :      :     |C|      :
  369.              :     +-+      :      :     +-+      :
  370.              :   IP + OSI   :      :   IP + OSI   :
  371.              +..............+      +..............+
  372.  
  373.  
  374.       Figure 2: Several logical views of the same physical network
  375.  
  376. 5. Position in the Directory Information Tree (DIT)
  377.  
  378.    Information about networks usually will be contained in the DIT as
  379.    subordinate of the organization maintaining the network. The network
  380.    model gets mapped into a tree structure for network elements.  There
  381.    is one network object giving general descriptions of the network.
  382.    Subordinates of this network object are node objects for each node
  383.    element present in the network.  Node objects hold networkInterface
  384.    objects as subordinates.  A network can be physically or logically
  385.    subdivided into several (sub)networks.  In this case, a network entry
  386.    will have network objects as subordinates which again build the same
  387.    structure.  These entries may be kept as subordinates of
  388.    organizationalUnit entries as well, with pointers from the "root"
  389.    network.
  390.  
  391.  
  392.  
  393.  
  394. Mansfield, Johannsen & Knopper                                  [Page 7]
  395.  
  396. RFC 1609        Charting Networks in the X.500 Directory      March 1994
  397.  
  398.  
  399.    This structure holds for physical and logical elements.  Physical
  400.    elements are named network, node and networkInterface, and logical
  401.    elements are named networkImage, nodeImage and networkInterfaceImage.
  402.  
  403.                           _root_
  404.                          /      \
  405.                         /        \
  406.                        /          \
  407.                   country          \
  408.                      /              \
  409.                     /            organization
  410.                    /             /    |     \
  411.                   /             /     |      \
  412.                  /             /      |       \
  413.                 /             /       |        \
  414.                /  organizationalUnit* |         \
  415.               /   /             \ \   |          \
  416.              /   /               \ \__|_________  \
  417.             /   /                 \   |         \  \
  418.            Person                 Network*<====>NetworkImage*
  419.                                       |             |
  420.                                       |             |
  421.                                      Node      NodeImage
  422.                                       |             |
  423.                                       |             |
  424.                            NetworkInterface   NetworkInterfaceImage
  425.  
  426.            Legends: * the object may recursively contain objects of
  427.                     same class as children
  428.  
  429.            Figure 3: Part of the Directory Information Tree,
  430.           showing relations of White Pages and network objects
  431.  
  432. 6. Proposed Schemes
  433.  
  434.    A physical network comprises of wires and machines. The physical map
  435.    of the network will show the interconnections of these nodes by these
  436.    circuits.
  437.  
  438.    For each physical network element, one or more images may exist.
  439.    Similarly, an image may be attached to one or more physical objects.
  440.    The types of images can grow along with the requirements.
  441.    Relationship between elements (physical or logical) are expressed by
  442.    attributes or the position in the Directory tree.
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Mansfield, Johannsen & Knopper                                  [Page 8]
  451.  
  452. RFC 1609        Charting Networks in the X.500 Directory      March 1994
  453.  
  454.  
  455.    Problems that are addressed in the schema:
  456.  
  457.    1. Avoiding data duplication
  458.    2. Preserving administrative boundaries/controls.
  459.    3. Simple representation (minimal number of pointers)
  460.    4. Security: Though no special emphasis has been placed
  461.       in this work we believe the X.500 access control policies
  462.       policies will provide a reasonable secure framework for security
  463.       and privacy.
  464.  
  465.    Problems that are not addressed:
  466.  
  467.    1. Caching policies, etc.: to be decided locally
  468.  
  469. 6.1 Communication Object Classes
  470.  
  471.    The object classes introduced in section 4 are defined as follows:
  472.  
  473.    CommunicationObject OBJECT CLASS
  474.     SUBCLASS of top
  475.     MAY CONTAIN {
  476.      description :: CaseIgnoreStringSyntax,
  477.       /* can contain any information about the object,
  478.          however, wherever an appropriate attribute
  479.          exists, this should be used first to hold
  480.          information */
  481.      adminContact :: distinguishedNameSyntax,
  482.       /* points to the person which is responsible for
  483.          the administration of the instance this object
  484.          describes;
  485.          This refers to the instance only in the context
  486.          of the concrete object class */
  487.      technContact :: distinguishedNameSyntax,
  488.       /* points to the person which is responsible for
  489.          the technical maintenance of the instance this
  490.          object describes;
  491.          This refers to the instance only in the context
  492.          of the concrete object class;
  493.          Availability (e.g. hours of service) is not
  494.          covered by this attribute. */
  495.     }
  496.  
  497.    PhysicalCommunicationObject OBJECT CLASS
  498.     SUBCLASS of CommunicationObject
  499.     MAY CONTAIN{
  500.      owner :: distinguishedNameSyntax,
  501.       /* refers to organization or person owning the
  502.         physical element;
  503.  
  504.  
  505.  
  506. Mansfield, Johannsen & Knopper                                  [Page 9]
  507.  
  508. RFC 1609        Charting Networks in the X.500 Directory      March 1994
  509.  
  510.  
  511.         Note that more detailed information (like lease,
  512.         rental, etc.) can be covered in a specific image
  513.         (ownerImage) of this element */
  514.      localityName :: CaseIgnoreStringSyntax
  515.       /* where the object is located;
  516.          can be used freely to "spot" a network element,
  517.          e.g. state/city/street/building/floor/room/
  518.          desk/... */
  519.      ICO :: distinguishedNameSyntax
  520.       /* points to image object the physical object
  521.          is related to;
  522.             might have several values if physical object is
  523.             used for several applications at the same time */
  524.            }
  525.  
  526.    ImageCommunicationObject OBJECT CLASS
  527.     SUBCLASS of CommunicationObject
  528.     MAY CONTAIN{
  529.      type :: caseIgnoreStringSyntax,
  530.       /* expresses the view this object refers to, e.g.
  531.          view of provider/user/IP/OSI/...;
  532.             Note that this information can be covered by
  533.             the object class in some cases
  534.             (e.g. ipNetworkImage gives the IP view) */
  535.      imageOf :: distinguishedNameSyntax,
  536.       /* points to physical/image object the image
  537.          is related to;
  538.             might have several values if view applies to
  539.             several physical objects at the same time */
  540.     }
  541.  
  542. 6.2 Physical elements
  543.  
  544.    The following objects describe network elements without saying
  545.    anything about their usage.  All objects inherit properties of the
  546.    PhysicalCommunicationObject class.
  547.  
  548. 6.2.1 Network
  549.  
  550.    The network object supplies general descriptions which are common for
  551.    a set of nodes and circuits comprising one network.  This includes
  552.    information about the type of circuits (medium, broadcast or point-
  553.    to- point, etc.) and properties (speed etc.).
  554.  
  555.    network OBJECT CLASS
  556.     SUBCLASS of PhysicalCommunicationObject
  557.     MUST CONTAIN  {
  558.      networkName :: caseIgnoreStringSyntax }
  559.  
  560.  
  561.  
  562. Mansfield, Johannsen & Knopper                                 [Page 10]
  563.  
  564. RFC 1609        Charting Networks in the X.500 Directory      March 1994
  565.  
  566.  
  567.     MAY CONTAIN {
  568.      externalGateway :: distinguishedNameSyntax,
  569.       /* points to one or more nodes that connect
  570.          this network to neighbor networks;
  571.             whether a node actually is used as gateway
  572.             for one or the other protocol, is defined
  573.             in a related networkImageObject */
  574.      nwType :: caseIgnoreStringSyntax,
  575.       /* type of this network;
  576.          either "composite" (if consisting of subnetworks)
  577.          or type of a line:
  578.          bus, ring, star, mesh, point-to-point */
  579.      media :: caseIgnoreStringSyntax,
  580.       /* if network is not composite,
  581.          describes physical media:
  582.          copper, fiber optic, etc. */
  583.      speed :: numericStringSyntax,
  584.       /* nominal bandwidth, e.g. 64 kbps */
  585.      traffic :: numericStringSyntax
  586.       /* (average) use in percent of nominal bandwidth
  587.             [ this needs more specification later ] */
  588.      configurationDate ::  uTCTimeSyntax,
  589.       /* date when network was configured in current
  590.             shape */
  591.      configurationHistory :: caseIgnoreStringSyntax
  592.       /* list of configuration changes, like:
  593.             added/removed nodes, lines */
  594.      }
  595.  
  596. 6.2.2 Node
  597.  
  598.    The node object describes any kind of device that is part of the
  599.    network, such as simple nodes, printer, bridges.
  600.  
  601.    node OBJECT CLASS
  602.     SUBCLASS of PhysicalCommunicationObject
  603.     MUST CONTAIN{
  604.      nodeName :: caseIgnoreStringSyntax }
  605.     MAY CONTAIN {
  606.      machineType :: caseIgnoreStringSyntax,
  607.       /* e.g. main frame, work station, PC, printer;
  608.          might include manufacturer */
  609.      OS :: caseIgnoreStringSyntax,
  610.       /* e.g. VM, UNIX, DOS; might include release */
  611.     }
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Mansfield, Johannsen & Knopper                                 [Page 11]
  619.  
  620. RFC 1609        Charting Networks in the X.500 Directory      March 1994
  621.  
  622.  
  623. 6.2.3 NetworkInterface
  624.  
  625.    Each node object will have one or more networkInterface objects as
  626.    subordinates.  NetworkInterface objects provide information about
  627.    interfaces of the node and connectivity.
  628.  
  629.    networkInterface OBJECT CLASS
  630.     SUBCLASS of PhysicalCommunicationObject
  631.     MUST CONTAIN {
  632.      networkInterfaceName :: caseIgnoreStringSyntax
  633.       /* It is suggested that the networkInterface
  634.          name is derived from the name of the logical
  635.          device this networkInterface represents for
  636.          the operating system, e.g. le0, COM1 */
  637.      }
  638.     MAY CONTAIN {
  639.      networkInterfaceAddress  :: caseIgnoreStringSyntax,
  640.       /* this should contain a protocol-independent
  641.             interface address, e.g. Ethernet board number */
  642.      connectedNetwork :: distinguishedNameSyntax,
  643.       /* pointer to object of network which this networkInterface is
  644.          connected to */
  645.      }
  646.  
  647. 6.3 Logical Elements
  648.  
  649.    An abstract view of a physical element is called image in this
  650.    document.  The word image gets appended to the object type, leading
  651.    to the new objects networkImage, nodeImage and networkInterfaceImage.
  652.    Images will either build Directory trees of themselves or be stored
  653.    as part of the physical network tree (see section 5).
  654.  
  655.    Image objects inherit properties of the ImageCommunicationObject
  656.    class.
  657.  
  658.    Each image object has specific attributes which vary depending on the
  659.    point of view (IP, OSI, ...). Also, the user and provider of an image
  660.    will view an object differently; further a user of an object may also
  661.    be providing the services of the same object to another user.
  662.  
  663.    Therefore, in the following a complete and general list of attributes
  664.    cannot be given.  We recommend to define subclasses of Image classes
  665.    for each logical view. These subclasses inherit all attributes
  666.    defined with the object classes below and add more specific
  667.    attributes.  Examples for an IP-view are given in [1].
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Mansfield, Johannsen & Knopper                                 [Page 12]
  675.  
  676. RFC 1609        Charting Networks in the X.500 Directory      March 1994
  677.  
  678.  
  679. 6.3.1 Network
  680.  
  681.    There may be several network images for one and the same physical
  682.    network: one for each protocol, application, etc.
  683.  
  684.    networkImage OBJECT CLASS
  685.     SUBCLASS of ImageCommunicationObject
  686.     MAY CONTAIN {
  687.      externalGateway :: distinguishedNameSyntax,
  688.       /* points to one or more nodes that act
  689.          as gateway for the protocol application
  690.          this images refers to */
  691.      speed :: numericStringSyntax,
  692.       /* nominal bandwidth for the channel dedicated
  693.          to this protocol or application ,
  694.          e.g. 64 kbps */
  695.      traffic :: numericStringSyntax,
  696.       /* (average) use in percent of nominal bandwidth
  697.          [this needs more specification later ] */
  698.      charge  :: numericStringSyntax
  699.       /* amount of money that has to be paid to
  700.          service provider for usage;
  701.          [it is felt that this needs further definition:
  702.           e.g. monetary unit / time unit, monetary unit /
  703.           data unit ] */
  704.      }
  705.  
  706. 6.3.2 Node
  707.  
  708.    Name and functionality within the network might vary for a node from
  709.    protocol to protocol considered.  In particular, a node might act as
  710.    gateway for one protocol but not for the other. Routing policy is
  711.    stored in the case of policy gateways.
  712.  
  713.    nodeImage OBJECT CLASS
  714.     SUBCLASS of ImageCommunicationObject
  715.      /* no attributes common for all nodeImages have been
  716.         defined yet */
  717.  
  718. 6.3.3 NetworkInterface
  719.  
  720.    As with physical nodes, nodeImages have networkInterfaces
  721.    (networkInterfaceImages) which describe connectivity to other network
  722.    elements. NetworkInterfaceImages are only given if the protocol is
  723.    establishing connections via this networkInterface.
  724.  
  725.    networkInterfaceImage OBJECT CLASS
  726.     SUBCLASS of ImageCommunicationObject
  727.  
  728.  
  729.  
  730. Mansfield, Johannsen & Knopper                                 [Page 13]
  731.  
  732. RFC 1609        Charting Networks in the X.500 Directory      March 1994
  733.  
  734.  
  735.     MAY CONTAIN {
  736.      networkInterfaceAddress :: caseIgnoreStringSyntax,
  737.       /* the networkInterface address in the image
  738.          context, e.g. IP number, NSAP */
  739.      connectedNetwork   :: distinguishedNameSyntax
  740.       /* pointer to networkImageObject that describes
  741.          the network this networkInterface is attached
  742.          to in terms of the protocol or application the
  743.          image indicates */
  744.      }
  745.  
  746. 7. Security Considerations
  747.  
  748.    Security issues are not discussed in this memo.
  749.  
  750. 8. Authors' Addresses
  751.  
  752.    Glenn Mansfield
  753.    AIC Systems Laboratory
  754.    6-6-3 Minami Yoshinari
  755.    Aoba-ku, Sendai 989-32
  756.    Japan
  757.  
  758.    Phone: +81 22 279-3310
  759.    EMail: glenn@aic.co.jp
  760.  
  761.  
  762.    Thomas Johannsen
  763.    Dresden University of Technology
  764.    Institute of
  765.    Communication Technology
  766.    D-01062 Dresden
  767.    Germany
  768.  
  769.    Phone: +49 351 463-4621
  770.    EMail: Thomas.Johannsen@ifn.et.tu-dresden.de
  771.  
  772.  
  773.    Mark Knopper
  774.    Merit Network, Inc.
  775.    1071 Beal Avenue
  776.    Ann Arbor, MI 48109
  777.  
  778.    EMail: mak@merit.edu
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Mansfield, Johannsen & Knopper                                 [Page 14]
  787.  
  788. RFC 1609        Charting Networks in the X.500 Directory      March 1994
  789.  
  790.  
  791. 9. References
  792.  
  793.   [1]  Harrenstein, K., Stahl, M., and E. Feinler, "NICNAME/WHOIS", RFC
  794.        954, SRI, October 1985.
  795.  
  796.   [2]  Mockapetris, P., "Domain Names - Implementation and
  797.        Specification", STD 13, RFC 1035, USC/Information Sciences
  798.        Institute, November 1987.
  799.  
  800.   [3]  Johannsen, T., Mansfield, G., Kosters, M., and S. Sataluri,
  801.        "Representing IP information in the X.500 Directory", RFC 1609,
  802.        Dresden University, AIC Systems Laboratory, Network
  803.        Solutions,Inc., AT&T Bell Laboratories, March 1994.
  804.  
  805.   [4]  Johannsen, T., and G. Mansfield, "The Soft Pages Project", OSI-DS
  806.        WG document, OSI-DS-39, Dresden University, AIC Systems
  807.        Laboratory, February 1993.
  808.  
  809.   [5]  CCITT Blue Book, "Data Communication Networks: Directory",
  810.        Recommendations X.500-X.521, December 1988.
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Mansfield, Johannsen & Knopper                                 [Page 15]
  843.  
  844.