In order to perform interoperable management activities, communicating OSs
must share a common view or understanding of the following information:
-
Supported Management Functions
-
Supported Managed Object Classes
-
Available Managed Object Instances
-
Authorized Capabilities
Understanding management functions (e.g., event management and state
management) includes an understanding of what options and which roles (e.g.,
manager or agent) are supported for each function. While trial and error is
one method of gaining this understanding the need for a more efficient
mechanism is appreciated.
It is necessary to understand which managed object classes are supported by
each OS. Since CMIP scoping is only capable of discovering instances of
managed object classes, a more comprehensive mechanism is needed to
understand the complete set of managed object classes supported including
those for which there is not presently an instance available. There may also
be relationships (e.g., possible superior-subordinate pairs for naming)
between
managed object classes. If so, the negotiation mechanism needs to support the
development of this understanding as well.
The actual instances of managed object classes that are available in a OS
forms the most significant base of understanding needed by communicating
OSs. CMIP scoping is a reasonable mechanism to provide most of this
understanding. As with managed object classes, managed object instances
may also be participating in relationships that need to be understood by
communicating OSs.
Beside understanding what functions and managed objects are supported, the
shared conceptual schema also includes an understanding of authorized
management capabilities (e.g., permission to modify configurations, adjust
tariffs, create or delete managed objects, run destructive tests).
The interoperable interface specifies the protocols that are used for
communication between OSs. OSs must implement this interface and perform
the role of either a managing process, an agent process, or both; OS design
is otherwise unconstrained. OSs wishing to communicate must agree (either
offline or online) on a shared conceptual schema. Where necessary, supplier-
specific information may be carried within the framework of standard
interactions. Finally, OS implementations evolve over time and must be tested
for conformance with the interoperable interface.