rfc1095.txt

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

   Managed objects are fully defined by specifying the "attributes" or
   properties the object has, the CMIS operations that can be performed
   on the object (e.g., M-SET, M-CREATE) and any constraints on those
   operations, specific actions (e.g., self-test) that can be performed
   on the object, events that the object can generate, and information



Warrier & Besaw                                                [Page 19]

RFC 1095                          CMOT                        April 1989


   about various relationships the object may be involved in.  All of
   this information relevant to a managed object is typically provided
   by filling in an object template.

   Managed objects contain properties that are referred to as
   attributes.  Attributes are atomic items of information that can only
   be manipulated as a whole.  An example of an attribute is a counter
   providing a specific piece of information, such as the number of
   packets retransmitted.

   Each object class and attribute is assigned a unique identifier (an
   ASN.1 OBJECT IDENTIFIER) for purposes of naming by a registration
   authority.

5.1.1.2.  Management Information Hierarchies

   Managed objects participate in relationships with each other.  There
   are two relationships that are of particular importance for
   management information: the containment relationship and the
   inheritance relationship.  These relationships can be used to
   construct hierarchies of managed objects.  In addition, there is
   another hierarchy defined by the registration process for registering
   identifiers for object classes and attributes.

5.1.1.2.1.  The Registration Hierarchy

   The registration hierarchy is determined by the ASN.1 registration
   tree [5] for assigning OBJECT IDENTIFIERs.  An OBJECT IDENTIFIER is
   an administratively assigned name composed of a series of integers
   traversing a path from the root of the ASN.1 registration tree to the
   node or leaf to be identified.  For example, the sequence of integers
   { iso(1) standard(0) ips-osi-mips(9596) cmip(2) } (1.0.9596.2) can be
   used to uniquely identify the CMIP standard.  Each node of this tree
   has an associated registration authority that determines how numbers
   in the subtree defined by that node are allocated.  In the context of
   management, these OBJECT IDENTIFIERs are used for identifying object
   classes and attributes.  The registration hierarchy is not based on
   any particular relationship between managed objects or between
   managed objects and their attributes.  It is independent of both the
   inheritance and containment relationships described below.  Its
   purpose is simply to generate universally unique identifiers.

5.1.1.2.2.  The Containment Hierarchy

   The containment hierarchy is constructed by applying the relationship
   "is contained in" to objects and attributes.  Objects of one class
   may contain objects of the same or different class.  Objects may also
   contain attributes.  Attributes cannot contain objects or other



Warrier & Besaw                                                [Page 20]

RFC 1095                          CMOT                        April 1989


   attributes.  For example, objects of the class "transport entity" may
   contain objects of the class "transport connection"; an object of the
   class "management domain" may contain objects of the class "node." An
   object class that contains another object class is called the
   "superior" object class; an object class that is contained in another
   object class is called the "subordinate" object class.  The
   containment relationships that an object may participate in are part
   of the definition of the object class to which that managed object
   belongs.  All object classes (except the topmost) must have at least
   one possible superior in the containment tree.  The definition of a
   class may permit it to have more than one such superior.  However,
   individual instances of such a class are nevertheless contained in
   only one instance of a possible containing class.

   The containment hierarchy is important because it can be used for
   identifying instances of a managed object.  For example, assume there
   is an object class "domain" that contains an object class "node" that
   contains an object class "transport entity" that contains an object
   class "transport connection." A particular instance of a transport
   connection can be identified by the concatenation of "instance
   information" for each object class in the containment path: {
   domain="organization," node="herakles," transport entity=tp4,
   transport connection=<TSAP-AddressA, TSAP-AddressB> }.

   What constitutes appropriate "instance information" for each object
   class is part of the definition of that object class and is known as
   the "distinguished attribute(s)." A distinguished attribute is
   composed of an OBJECT IDENTIFIER naming the attribute and the value
   of the attribute.  For each object class, the distinguished
   attributes that differentiate instances of that class are
   collectively called the "relative distinguished name." A sequence of
   relative distinguished names (one for each class in the containment
   path) is the "distinguished name" of a managed object.  The example
   given above represents the distinguished name of a transport
   connection.  The containment hierarchy is sometimes referred to as
   the "naming tree", because it is used to "name" a particular instance
   of a managed object.

   The containment relationship also defines an existence dependency
   among its components; an object or attribute can "exist" only if the
   containing object also "exists." Deletion of an object may result in
   deletion of all objects and attributes contained within it.
   Alternately, depending on the definition of the managed object,
   deletion may be refused until all contained managed objects have been
   deleted.






Warrier & Besaw                                                [Page 21]

RFC 1095                          CMOT                        April 1989


5.1.1.2.3.  The Inheritance Hierarchy

   The inheritance hierarchy is constructed by applying the relationship
   "inherits properties of" to object classes.  An object class may
   inherit properties of another object class; refinement is obtained by
   adding additional properties.  In this relationship, the parent class
   is called the "superclass" and the inheriting class the "subclass."
   For example, the class "layer entity" may be a superclass of "network
   entity," which in turn is a superclass of "X.25 network entity."
   Attributes defined for "network entity" (e.g., the number of packets
   sent) are automatically defined for "X.25 network entity" without
   having to explicitly include them in the definition for the class
   "X.25 network entity." Thus, inheritance serves as a shorthand for
   defining object classes using object-oriented methodology.  Each
   class (except the topmost) has at least one superclass, but may have
   zero, one, or many subclasses.  Subclasses may in turn have further
   subclasses, to any degree.  A special object called "top" is the
   ultimate superclass.  It has no properties of its own.

   The inheritance hierarchy has no relevance to the naming of object
   instances.  It is useful only insofar as it leads to a manageable and
   extensible technique for the definition of object classes.

5.1.2.  The Internet SMI

   The Internet SMI [2] is designed to be a protocol-independent SMI
   that can be used with both SNMP and CMIP.  For this reason, it is
   necessary for any management protocol that uses this SMI to show how
   it is to be interpreted in a protocol-specific manner.  This is done
   for CMIP in this memo.

   The Internet SMI indicates both how to identify managed objects and
   how to define them.  The Internet SMI defines a registration subtree
   rooted at { iso(1) org(3) dod(6) internet(1) } for the sake of
   registering OBJECT IDENTIFIERs to be used for uniquely identifying
   managed objects.  The current Internet SMI specifies the format for
   defining objects in terms of an "object type" template and an
   associated OBJECT-TYPE ASN.1 macro.  An object type definition
   contains five fields: a textual name, along with its corresponding
   OBJECT IDENTIFIER; an ASN.1 syntax; a definition of the semantics of
   the object type; an access (read-only, read-write, write-only, or
   not-accessible); and a status (mandatory, optional, or obsolete).
   The current Internet SMI does not provide any mechanism for defining
   actions or events associated with a managed object.

   In describing management information, the current Internet SMI does
   not use the notions of "object class" and "attribute" found in the
   ISO SMI.  Only the concepts of "object type" and "object instance"



Warrier & Besaw                                                [Page 22]

RFC 1095                          CMOT                        April 1989


   are used.  The Internet SMI shows how to define object types; it
   leaves the specification of object instances as a protocol-specific
   matter.  The current Internet structure of management information is
   simpler and less rich than the corresponding ISO structure. The ISO
   SMI makes a distinction between simple "attributes," which can be
   viewed as "leaf objects" that are the lowest elements of the
   containment hierarchy, and composite "managed objects" that belong to
   an "object class" and have a structure associated with them (that is,
   can contain attributes).  The Internet SMI does not draw this
   distinction; both simple and composite "objects" are defined as
   "object types." What structure is associated with objects in the
   Internet SMI is defined through the deliberate attempt to structure
   the lower part of the Internet registration tree according to
   containment principles.  (Objects that are considered "attributes" of
   other containing objects are defined directly below them in the
   object registration tree.) This results in a certain lack of
   flexibility, since the registration hierarchy is implicitly used to
   define the containment hierarchy.  This means that the Internet SMI
   does not contain a mechanism for defining containment relationships
   that do not happen to coincide with the registration hierarchy.  In
   interpreting the Internet SMI for use with CMIP, it is necessary to
   overcome this limitation.

5.2.  The Management Information Base

   The Management Information Base (MIB) is a "conceptual repository of
   management information." It is an abstract view of all the objects in
   the network that can be managed.  Note that the MIB is conceptual in
   that it does not carry any implications whatsoever about the physical
   storage (main memory, files, databases, etc.) of management
   information.  The SMI provides the guidelines for defining objects
   contained in the MIB.

   The CMOT approach will use the Internet MIB based on the Internet SMI
   described above.  The first version of the Internet MIB, which is the
   product of the IETF MIB working group, is defined in RFC 1066 [3].
   It contains objects divided into eight groups: system, interfaces,
   address translation, IP, ICMP, TCP, UDP, and EGP.  In addition, the
   Internet SMI provides for future versions of the Internet MIB and a
   means for otherwise extending the MIB through the registration of
   managed objects under "private" and "experimental" branches of the
   object registration tree.  Appendix B provides a protocol-specific
   interpretation of the first version of the TCP/IP MIB defined in [3]
   so that it can be used with CMOT.  This interpretation is based on a
   straightforward mapping of the current Internet SMI to the ISO SMI
   (section 5.3).

   The initial version of the Internet MIB concentrates on defining



Warrier & Besaw                                                [Page 23]

RFC 1095                          CMOT                        April 1989


   objects associated with various Internet protocols.  It is expected
   that future versions of the Internet MIB and various extensions will
   provide a much richer set of objects to manage, including management
   information about a variety of network devices and systems.  Thus, an
   expanded MIB will allow wide-ranging and powerful management using
   the CMOT approach.

5.3.  An Interpretation of the Internet SMI

   In order to use CMIP to convey information defined in terms of the
   Internet SMI, it is necessary to show how object instances are
   specified and to provide the necessary structure for differentiating
   object class and attributes.  These objectives are both met by
   separating the containment hierarchy used for naming objects from the
   registration hierarchy and by imposing an "object class" structure on
   the Internet SMI.  Using the technique of imposing an object class
   structure does not replace or redefine the object definitions in the
   Internet MIB; it merely provides a necessary gloss or commentary on a
   MIB defined in terms of the Internet SMI.  For example, Appendix B
   references the "object type" definitions found in [3], but imposes
   additional structure on them.

   This object class definition derives from a simplified version of the
   OBJECT-CLASS macro defined in the ISO SMI [19].  The more complex
   definition is not needed for present purposes.  (The object class