rfc1609.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 844 行 · 第 1/3 页
TXT
844 行
RFC 1609 Charting Networks in the X.500 Directory March 1994
4.2 Representation in the X.500 Directory
To represent the various images of networks and its components along
with the real-image relationship among the various objects we
introduce the following classes of objects:
o Communication Object Class (CO): All objects defined
furtheron in this document belong to this class.
Common attributes for all communication objects are
defined in section 6.
o Physical Communication Object Class (PCO): A subclass
of CO-class, this class defines common properties for
all objects representing physical communication objects.
o Image Communication Object Class (ICO): A subclass of
CO-class, this class defines common properties for all
objects representing images of communication objects.
The above classes sort communication objects into physical or image
object. As is implied in the nomenclature a physical object will
have several attributes describing it physical properties - location,
weight, size, .... etc. An image object will have an Image-of
attribute. The Image-of attribute will point to a physical object or
to another image object.
Using this schema it is possible to represent the case of several
logical network systems (running different protocol stacks - IP, XNS,
SNA, OSI, ...) which coexist on the same physical network.
Information related to different types of networks, no matter what
the underlying communication protocol is, will reside in the
Directory in harmony. Also, their interrelation will be represented
and accessed in a fashion independent of the source/destination
network, namely, using the OSI X.500 protocol.
Schemes for physical networks and logical images of physical networks
are defined in section 6.
All objects are defined in section 6.
Mansfield, Johannsen & Knopper [Page 6]
RFC 1609 Charting Networks in the X.500 Directory March 1994
...............
: :
: IP OSI :
: +-+ +-+ :
: |A| |B| :
NetWork -----> : +-+ +-+ :
/ \ : | | :
/ \ : ============ :
/ \ : | :
/ \ : +-+ :
/ \ : |C| :
/ \ : +-+ :
OSI-image IP-image : IP + OSI :
| | +..............+
V V
........ ........
: : : :
IP : OSI : : IP : OSI
+-+ : +-+ : : +-+ : +-+
|A| : |B| : : |A| : |B|
+-+ : +-+ : : +-+ : +-+
....|...: | : : | :..|...
: ============ : : ============ :
: | : : | :
: +-+ : : +-+ :
: |C| : : |C| :
: +-+ : : +-+ :
: IP + OSI : : IP + OSI :
+..............+ +..............+
Figure 2: Several logical views of the same physical network
5. Position in the Directory Information Tree (DIT)
Information about networks usually 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 network object giving general descriptions of the network.
Subordinates of this network object are node objects for each node
element present in the network. Node objects hold networkInterface
objects as subordinates. 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.
Mansfield, Johannsen & Knopper [Page 7]
RFC 1609 Charting Networks in the X.500 Directory March 1994
This structure holds for physical and logical elements. Physical
elements are named network, node and networkInterface, and logical
elements are named networkImage, nodeImage and networkInterfaceImage.
_root_
/ \
/ \
/ \
country \
/ \
/ organization
/ / | \
/ / | \
/ / | \
/ / | \
/ organizationalUnit* | \
/ / \ \ | \
/ / \ \__|_________ \
/ / \ | \ \
Person Network*<====>NetworkImage*
| |
| |
Node NodeImage
| |
| |
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
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?