rfc1609.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

                                      |             |
                           NetworkInterface   NetworkInterfaceImage

           Legends: * the object may recursively contain objects of
                    same class as children

           Figure 3: Part of the Directory Information Tree,
          showing relations of White Pages and network objects

6. 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.
   Similarly, an image may be attached to one or more physical objects.
   The types of images can grow along with the requirements.
   Relationship between elements (physical or logical) are expressed by
   attributes or the position in the Directory tree.







Mansfield, Johannsen & Knopper                                  [Page 8]

RFC 1609        Charting Networks in the X.500 Directory      March 1994


   Problems that are addressed in the schema:

   1. Avoiding data duplication
   2. Preserving administrative boundaries/controls.
   3. Simple representation (minimal number of pointers)
   4. Security: Though no special emphasis has been placed
      in this work we believe the X.500 access control policies
      policies will provide a reasonable secure framework for security
      and privacy.

   Problems that are not addressed:

   1. Caching policies, etc.: to be decided locally

6.1 Communication Object Classes

   The object classes introduced in section 4 are defined as follows:

   CommunicationObject OBJECT CLASS
    SUBCLASS of top
    MAY CONTAIN {
     description :: CaseIgnoreStringSyntax,
      /* can contain any information about the object,
         however, wherever an appropriate attribute
         exists, this should be used first to hold
         information */
     adminContact :: distinguishedNameSyntax,
      /* points to the person which is responsible for
         the administration of the instance this object
         describes;
         This refers to the instance only in the context
         of the concrete object class */
     technContact :: distinguishedNameSyntax,
      /* points to the person which is responsible for
         the technical maintenance of the instance this
         object describes;
         This refers to the instance only in the context
         of the concrete object class;
         Availability (e.g. hours of service) is not
         covered by this attribute. */
    }

   PhysicalCommunicationObject OBJECT CLASS
    SUBCLASS of CommunicationObject
    MAY CONTAIN{
     owner :: distinguishedNameSyntax,
      /* refers to organization or person owning the
        physical element;



Mansfield, Johannsen & Knopper                                  [Page 9]

RFC 1609        Charting Networks in the X.500 Directory      March 1994


        Note that more detailed information (like lease,
        rental, etc.) can be covered in a specific image
        (ownerImage) of this element */
     localityName :: CaseIgnoreStringSyntax
      /* where the object is located;
         can be used freely to "spot" a network element,
         e.g. state/city/street/building/floor/room/
         desk/... */
     ICO :: distinguishedNameSyntax
      /* points to image object the physical object
         is related to;
            might have several values if physical object is
            used for several applications at the same time */
           }

   ImageCommunicationObject OBJECT CLASS
    SUBCLASS of CommunicationObject
    MAY CONTAIN{
     type :: caseIgnoreStringSyntax,
      /* expresses the view this object refers to, e.g.
         view of provider/user/IP/OSI/...;
            Note that this information can be covered by
            the object class in some cases
            (e.g. ipNetworkImage gives the IP view) */
     imageOf :: distinguishedNameSyntax,
      /* points to physical/image object the image
         is related to;
            might have several values if view applies to
            several physical objects at the same time */
    }

6.2 Physical elements

   The following objects describe network elements without saying
   anything about their usage.  All objects inherit properties of the
   PhysicalCommunicationObject class.

6.2.1 Network

   The network object supplies general descriptions which are common for
   a set of nodes and circuits comprising one network.  This includes
   information about the type of circuits (medium, broadcast or point-
   to- point, etc.) and properties (speed etc.).

   network OBJECT CLASS
    SUBCLASS of PhysicalCommunicationObject
    MUST CONTAIN  {
     networkName :: caseIgnoreStringSyntax }



Mansfield, Johannsen & Knopper                                 [Page 10]

RFC 1609        Charting Networks in the X.500 Directory      March 1994


    MAY CONTAIN {
     externalGateway :: distinguishedNameSyntax,
      /* points to one or more nodes that connect
         this network to neighbor networks;
            whether a node actually is used as gateway
            for one or the other protocol, is defined
            in a related networkImageObject */
     nwType :: caseIgnoreStringSyntax,
      /* type of this network;
         either "composite" (if consisting of subnetworks)
         or type of a line:
         bus, ring, star, mesh, point-to-point */
     media :: caseIgnoreStringSyntax,
      /* if network is not composite,
         describes physical media:
         copper, fiber optic, etc. */
     speed :: numericStringSyntax,
      /* nominal bandwidth, e.g. 64 kbps */
     traffic :: numericStringSyntax
      /* (average) use in percent of nominal bandwidth
            [ this needs more specification later ] */
     configurationDate ::  uTCTimeSyntax,
      /* date when network was configured in current
            shape */
     configurationHistory :: caseIgnoreStringSyntax
      /* list of configuration changes, like:
            added/removed nodes, lines */
     }

6.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 */
    }






Mansfield, Johannsen & Knopper                                 [Page 11]

RFC 1609        Charting Networks in the X.500 Directory      March 1994


6.2.3 NetworkInterface

   Each node object will have one or more networkInterface objects as
   subordinates.  NetworkInterface objects provide information about
   interfaces of the node and connectivity.

   networkInterface OBJECT CLASS
    SUBCLASS of PhysicalCommunicationObject
    MUST CONTAIN {
     networkInterfaceName :: caseIgnoreStringSyntax
      /* It is suggested that the networkInterface
         name is derived from the name of the logical
         device this networkInterface represents for
         the operating system, e.g. le0, COM1 */
     }
    MAY CONTAIN {
     networkInterfaceAddress  :: caseIgnoreStringSyntax,
      /* this should contain a protocol-independent
            interface address, e.g. Ethernet board number */
     connectedNetwork :: distinguishedNameSyntax,
      /* pointer to object of network which this networkInterface is
         connected to */
     }

6.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 and networkInterfaceImage.
   Images will either build Directory trees of themselves or be stored
   as part of the physical network tree (see section 5).

   Image objects inherit properties of the ImageCommunicationObject
   class.

   Each image object has specific attributes which vary depending on the
   point of view (IP, OSI, ...). 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.

   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. These subclasses inherit all attributes
   defined with the object classes below and add more specific
   attributes.  Examples for an IP-view are given in [1].






Mansfield, Johannsen & Knopper                                 [Page 12]

RFC 1609        Charting Networks in the X.500 Directory      March 1994


6.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
    MAY CONTAIN {
     externalGateway :: distinguishedNameSyntax,
      /* points to one or more nodes that act
         as gateway for the protocol application
         this images refers to */
     speed :: numericStringSyntax,
      /* nominal bandwidth for the channel dedicated
         to this protocol or application ,
         e.g. 64 kbps */
     traffic :: numericStringSyntax,
      /* (average) use in percent of nominal bandwidth
         [this needs more specification later ] */
     charge  :: numericStringSyntax
      /* amount of money that has to be paid to
         service provider for usage;
         [it is felt that this needs further definition:
          e.g. monetary unit / time unit, monetary unit /
          data unit ] */
     }

6.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
     /* no attributes common for all nodeImages have been
        defined yet */

6.3.3 NetworkInterface

   As with physical nodes, nodeImages have networkInterfaces
   (networkInterfaceImages) which describe connectivity to other network
   elements. NetworkInterfaceImages are only given if the protocol is
   establishing connections via this networkInterface.

   networkInterfaceImage OBJECT CLASS
    SUBCLASS of ImageCommunicationObject



Mansfield, Johannsen & Knopper                                 [Page 13]

RFC 1609        Charting Networks in the X.500 Directory      March 1994


    MAY CONTAIN {
     networkInterfaceAddress :: caseIgnoreStringSyntax,
      /* the networkInterface address in the image
         context, e.g. IP number, NSAP */
     connectedNetwork   :: distinguishedNameSyntax
      /* pointer to networkImageObject that describes
         the network this networkInterface is attached
         to in terms of the protocol or application the
         image indicates */
     }

7. Security Considerations

   Security issues are not discussed in this memo.

8. Authors' Addresses

   Glenn Mansfield
   AIC Systems Laboratory
   6-6-3 Minami Yoshinari
   Aoba-ku, Sendai 989-32
   Japan

   Phone: [phone]
   EMail: [e-mail]


   Thomas Johannsen
   Dresden University of Technology
   Institute of
   Communication Technology
   D-01062 Dresden
   Germany

   Phone: [phone]
   EMail: [e-mail]


   Mark Knopper
   Merit Network, Inc.
   1071 Beal Avenue
   Ann Arbor, MI 48109

   EMail: [e-mail]







Mansfield, Johannsen & Knopper                                 [Page 14]

RFC 1609        Charting Networks in the X.500 Directory      March 1994


9. References

  [1]  Harrenstein, K., Stahl, M., and E. Feinler, "NICNAME/WHOIS", RFC
       954, SRI, October 1985.

  [2]  Mockapetris, P., "Domain Names - Implementation and
       Specification", STD 13, RFC 1035, USC/Information Sciences
       Institute, November 1987.

  [3]  Johannsen, T., Mansfield, G., Kosters, M., and S. Sataluri,
       "Representing IP information in the X.500 Directory", RFC 1609,
       Dresden University, AIC Systems Laboratory, Network
       Solutions,Inc., AT&T Bell Laboratories, March 1994.

  [4]  Johannsen, T., and G. Mansfield, "The Soft Pages Project", OSI-DS
       WG document, OSI-DS-39, Dresden University, AIC Systems
       Laboratory, February 1993.

  [5]  CCITT Blue Book, "Data Communication Networks: Directory",
       Recommendations X.500-X.521, December 1988.































Mansfield, Johannsen & Knopper                                 [Page 15]