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
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.
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"
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 RFC1066 [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
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
definition presented here could be extended in the future to show
what actions and events are associated with a managed object.) The
object class definition has the following fields:
OBJECT CLASS:
------------
A textual name, termed the OBJECT CLASS DESCRIPTOR, for the object
class, along with its corresponding OBJECT IDENTIFIER.
Definition:
A textual description of the object class.
Subclass Of:
The OBJECT CLASS DESCRIPTOR of the object class that is the
superclass of this object class. This field is used for indicating
the inheritance relationship.
Superiors:
A list of OBJECT CLASS DESCRIPTORs of the possible superior object
classes of this object class. This field is used for indicating
the containment relationship.
Names:
A list of OBJECT DESCRIPTORs identifying the OBJECT TYPES that are
the distinguished attributes of this object class. (The OBJECT-
TYPE macro is defined in RFC1065). Attributes listed here will
normally be present in the Attribute field of the object class
definition. This field is used for indicating what attributes
must be present in the relative distinguished name that indicates
an instance of this object class.
Attributes:
A list of OBJECT DESCRIPTORs identifying the OBJECT TYPES that are
attributes of this object class. (The OBJECT-TYPE macro is defined
in RFC1065). This field is used for indicating the attributes
that are contained in this object class.
This object class definition satisfies our objectives for
interpreting the Internet SMI for use by CMIP. The Attributes
field shows what attributes are contained in this object class;
this makes the necessary distinction between object classes and
attributes required by CMIP. Instead of referencing an
"attribute" def inition (as is done in the ISO SMI), the
Attributes field references the "object type" definition found in
RFC1065 and used to define the Internet-standard MIB in RFC1066.
The name, syntax, and access information required for attributes
is contained in the "object type" definition. Two things are
required for specifying an instance of a managed object: a
containment relationship determining a sequence of object classes
and a means for specifying the distinguished attributes for an
object class. The Superiors field makes the containment
relationship explicit; it is no longer merely a function of the
registration tree. The Names field makes it possible to indicate
the distinguished attributes for an object class required for
giving instance information. Thus, the object class definition
makes it possible to specify an object instance using CMIP.
5.3.1. Object Class and Attributes
The mapping of management information to the CMIS parameters Managed
Object Class and Attribute Identifier List now becomes apparent.
5.3.1.1. Object Class
The CMIS Managed Object Class parameter is the OBJECT IDENTIFIER
assigned to the particular object class. For example, the Managed
Object Class for the object class "ip" (as defined in Appendix B) is
{ mib 4 } = 1.3.6.1.2.1.4.
5.3.1.2. Attribute Identifier
The CMIS Attribute Identifier List parameter is a list of Attribute
Identifiers. An Attribute Identifier can be either global or local.
If it is global, then it is the OBJECT IDENTIFIER assigned to the
attribute (i.e., "object type") that is being indicated. For
example, the global Attribute Identifier for the attribute
"ipForwarding" (as defined in [3]) is
{ ip 1 } = 1.3.6.1.2.1.4.1.
If the Attribute Identifier is local, it is an integer that is the
last component in the OBJECT IDENTIFIER identifying the object. For
ipForwarding, the local Attribute Identifier is 1. In the case where
the local identifier is used, the leading components of the OBJECT
IDENTIFIER for the attribute must be the OBJECT IDENTIFIER of the
containing object class. This is true for the interpreted Internet
MIB defined in Appendix B, but may not be true generally. The local
identifier is intended to be interpreted relative to the Managed
Object Class field of the CMIP PDU. When a local Attribute
Identifier is encountered in a CMIP PDU, the global form of the
identifier is formed by prepending the OBJECT IDENTIFIER in the
Managed Object Class field to the local identifier. This is valid
only when scoping is not used (i.e., scoping is "baseObject"). If
scoping is used, then the global form of the Attribute Identifier
must be used instead of the local form.
5.3.2. Management Information Hierarchies
The following sections show how the three management information
hierarchies are to be understood for the interpreted Internet SMI.
5.3.2.1. The Registration Hierarchy
The registration hierarchy is the global object registration tree
described in [2]. It is used merely for assigning identifiers for
object classes and attributes (i.e., "object types" in RFC1065).
5.3.2.2. The Containment Hierarchy
As described above, the containment hierarchy is used to specify an
object instance. The Names field of the object class definition
contains the distinguished attributes for the object class. The
OBJECT IDENTIFIER naming the "attribute" together with its value is
called an attribute value assertion. A set of attribute value
assertions (one for each distinguished attribute) is the relative
distinguished name associated with that object class. The sequence
of relative distinguished names for each of the object classes in the
containment hierarchy to which a managed object belongs is the
distinguished name of the object. An object instance is fully
specified by a distinguished name.
Let us take a concrete example from Appendix B. How would we
represent an instance of an entry in the IP routing table? We begin
by examining the object class in question (ipRouteEntry) and use the
Superiors field to find the superior class in the containment
hierarchy (ipRoutingTable). This process continues until we
construct the following containment path of object classes: system,
ip, ipRoutingTable, ipRouteEntry. Now for each of these object
classes, we inspect the Names field to find the distinguished
attribute for that object class. If no Names field is present (as is
the case for "ip" and "ipRoutingTable"), then no instance information
is required at that level. Both "system" and "ipRouteEntry" have
Name fields to show what information is expected at that level. With
this information, we can construct the following distinguished name
specifying an instance of an IP routing table entry:
baseManagedObjectInstance {
distinguishedName {
relativeDistinguishedName { -- system
attributeValueAssertion {
attributeType { cmotSystemID }
attributeValue "gateway1.acme.com"
}
},
relativeDistinguishedName { -- ipRouteEntry
attributeValueAssertion {
attributeType { ipRouteDest }
attributeValue 10.0.0.51
}
}
}
}
If the system instance information is not present, then it is assumed
to be the system with which the management association is established
(i.e., the system receiving the request).
Note that the object instance tree can contain components of the
distinguished name that are outside the managed system (node). This
enables referencing of objects across management domains (there could
be an object class "domain") and across a collection of nodes. In a
network where several intermediate managers may be involved in a
request, each intermediate manager can use the "system" portion of
the name to determine where to send a request or result. This
technique of naming treats each intermediate managing system as a
proxy manager. The proxy manager resolves the address of the next
node in the chain and may use a different protocol to transfer the
request or result. Thus, the "system" instance information can be
used to name devices being managed by proxy.
5.3.2.3. The Inheritance Hierarchy
The Internet SMI does not use the inheritance relationship. The
"Subclass Of" field is present in the object class definition to show
how the inheritance relationship would be represented and to allow
for future extensibility. It is not used for any of the object
classes defined in Appendix B.
5.4. Scoping, Filtering, and Synchronization
Within some services, CMIS provides additional capabilities that are
related to the SMI. These are the scoping, filtering,
synchronization, and linked-reply facilities. The presence of these
facilities are indicated by the Multiple Object Selection Functional
Unit defined in CMIS [11].
These facilities provide the manager with the ability to operate on a
collection of managed objects, rather than a single object. The
selection of multiple objects occurs in two phases: scoping and
filtering. Scoping is used to identify the managed objects to which
a filter is to be applied. Then filtering is used to select a subset
of managed objects that satisfy certain conditions. If scoping is
not used, only the "base" managed object indicated by the CMIS
Managed Object Class parameter is implied. An example of the use of
scoping and filtering for selecting a particular managed object (a
table entry) is given in one of the sample protocol exchanges found
in Appendix C.
5.4.1. Scoping
Scoping is meant to be understood in terms of the containment
hierarchy. A position at a certain level of the containment tree is
defined by the CMIS Managed Object Class parameter. The CMIS Scope
parameter is then interpreted relative to this "base" managed object
(defined by both object class and object instance). The Scope
parameter can be used to select the base object alone, all managed
objects in the entire subtree (of the containment tree) below the
base object, or all managed objects in the "n"th level (n = 1, 2,
3,...) below the base object.
5.4.2. Filtering
Within the objects selected as a result of the scope parameter, it is
possible to further refine the selection of managed objects through
the use of filtering. Filtering provides the ability to select a
subset of these objects based on conditions applied to attributes
(e.g., IP routing table entries with the "ipRouteAge > 100") and
logical operations (and, or, not).
5.4.3. Synchronization
When multiple managed objects have been selected using scoping and
filtering, the question of synchronization across object instances
(such as multiple IP routing table entries) arises. The two possible
choices are "best effort" and "atomic." If "best effort"
synchronization is selected, the failure to apply an operation (e.g.,
M-SET) to one instance of an object does not affect the effort to
apply this operation to other instances of the object. If "atomic"
synchronization is selected, then the operation is either performed
on all object instances selected or none. The default
synchronization is best effort.
5.4.4. Linked Replies
If the reply to a single request for a set of managed objects results
in more than one managed object being returned, all of these managed
objects cannot be returned together in a single CMIP response PDU.
The reason for this is that the structure of the CMIP response PDU
only has a single field for containing object instance information.
Since each managed object has its own instance information, each
managed object must be returned in a separate CMIP PDU. In such a
case, the CMIP Linked Reply PDU is used. The Linked Reply PDU
provides a means of associating each of the multiple replies with the
original request that generated them. Thus, a single CMIP Get
Request PDU that uses scoping and filtering would result in zero or
more CMIP Linked Reply PDUs being returned before a final CMIP Get
Result PDU.
A linked reply can also be used to segment a CMIP response pertaining
to a single managed object. This would only be necessary if UDP is
being used as the underlying transport and it is not possible to
return all the information requested about the managed object in a
single response PDU subject to the size limitations described in
section 10.2.
5.5. Accessing Tables
This section explains how to use the interpreted Internet SMI and MIB
to access tables.
5.5.1. Accessing Whole Tables
A whole table is accessed by specifying the object class of the
table, indicating a scoping level of one, and not providing an
attribute identifier list. The CMIS standard [11] specifies that if
the attribute identifier parameter is not present, then all attribute
identifiers are assumed. The following CMIS parameters would be used
to return the entire TCP connection table:
Object Class: { tcpConnTable }
Object Instance: "empty" (unless proxy management is used)
Scope: oneLevel(1)
Filter: not present
Attribute Identifier List: not present
By scoping one level below "tcpConnTable," all managed objects of the
class "tcpConnEntry" are selected. (The object class "tcpConnEntry"
is the only object class one level below the object class
"tcpConnTable" in the containment hierarchy.) The absence of an
attribute identifier list signals that all attributes of the managed
object are to be returned (i.e., all fields of the TCP connection
table entry).
In reply to this request, each entry of the table will be returned in
a separate CMIP PDU (either a Linked Reply PDU or a Get Result PDU).
Each reply CMIP PDU will specify the Object Class "tcpConnEntry" and
the appropriate Object Instance information for that entry, as well
as an Attribute List giving the values of each of the fields of the
table entry.
5.5.2. Accessing Table Entries
An entire table entry is accessed by specifying the object class of
the table entry, providing a distinguished name specifying the
instance of the table entry, and not providing an attribute
identifier list. As seen above, the absence of the attribute
identifier list parameter indicates that all attributes are assumed.
The absence of a scope parameter indicates that the base managed
object class is intended. The following CMIS parameters would be
used to return the entire IP routing table entry for which the field
"ipRouteDest" has the value 10.0.0.51:
Object Class: { ipRouteEntry }
Object Instance: { ipRouteDest, 10.0.0.51 }
Scope: not present
Filter: not present
Attribute Identifier List: not present
The result is returned in a single CMIP Get Result PDU with an
attribute list consisting of all of the attributes (i.e., fields) of
the table entry and their corresponding values.
If the object class field refers to a table entry and no instance
information is provided to select a particular entry, then a
"noSuchObjectInstance" CMIP error should be returned.
Part II: Protocol Agreements
6. CMOT Protocol Overview
This part of the document is a specification of the protocols of the
CMOT architecture. Contained herein are the agreements required to
implement interoperable network management systems using these
protocols. The protocol suite defined by these implementors'
agreements will facilitate communication between equipment of
different vendors, suppliers, and networks. This will allow the
emergence of powerful multivendor network management based on ISO
models and protocols.
The choice of a set of protocol standards together with further
agreements needed to implement those standards is commonly referred
to as a "profile." The selection policy for the CMOT profile is to
use existing standards from the international standards community
(ISO and CCITT) and the Internet community. Existing ISO standards
and draft standards in the area of OSI network management form the
basis of this CMOT profile. Other ISO application layer standards
(ROSE and ACSE) are used to support the ISO management protocol
(CMIP). To ensure interoperability, certain choices and restrictions
are made here concerning various options and parameters provided by
these standards. Internet standards are used to provide the
underlying network transport. These agreements provide a precise
statement of the implementation choices made for implementing ISO
network management standards in TCP/IP-based internets.
In addition to the Netman working group, there are at least two other
bodies actively engaged in defining profiles for interoperable OSI
network management: the National Institute of Science and Technology
(NIST) Network Management Special Interest Group (NMSIG) and the OSI
Network Management Forum. Both of these groups are similar to the
Netman working group in that they are each defining profiles for
using ISO standards for network management. Both differ in that they
are specifying the use of underlying ISO protocols, while the Netman
working group is concerned with using OSI management in TCP/IP
networks. In the interest of greater future compatibility, the
Netman working group has attempted to make the CMOT profile conform
as closely as possible to the ongoing work of these two bodies.
6.1. The CMOT Protocol Suite
The following seven protocols compose the CMOT protocol suite: ISO
ACSE, ISO DIS ROSE, ISO DIS CMIP, the lightweight presentation
protocol (LPP), UDP, TCP, and IP. The relation of these protocols to
each other is briefly summarized in Figure 2.
+----------------------------------------------+
| Management Application Processes |
+----------------------------------------------+
+-------------------+
| CMISE |
| ISO DIS 9595/9596 |
+-------------------+
+------------------+ +--------------------+
| ACSE | | ROSE |
| ISO IS 8649/8650 | | ISO DIS 9072-1/2 |
+------------------+ +--------------------+
+-----------------------------------------------+
| Lightweight Presentation Protocol (LPP) |
| RFC1085 |
+-----------------------------------------------+
+------------------+ +--------------------+
| TCP | | UDP |
| RFC793 | | RFC768 |
+------------------+ +--------------------+
+-----------------------------------------------+
| IP |
| RFC791 |
+-----------------------------------------------+
Figure 2. The CMOT Protocol Suite
6.2. Conformance Requirements
A CMOT-conformant system must implement the following protocols:
ACSE, ROSE, CMIP, LPP, and IP. A conformant system must support the
use of the LPP over either UDP or TCP. The use of the LPP over both
UDP and TCP on the same system may be supported. A conformant system
need not support all CMIS operations. A conformant system must,
however, support at least one of the functional unit groups
(indicating a set of supported services) defined in section 7.1.3.
The service and protocol selections are described in greater detail
in the following sections.
6.3. Abstract Syntax Notation
The abstract syntax notation for all of the application service
elements of the CMOT protocol suite is Abstract Syntax Notation One
(ASN.1) [5]. The LPP is also defined using ASN.1. The basic
encoding rules used for ASN.1 are specified in [6]. Both definite-
length and indefinite-length encodings are expressly permitted.
7. Common Management Information Service Element
The Common Management Information Service Element (CMISE) is
specified in two ISO documents. The service definition for the
Common Management Information Service (CMIS) is given in ISO DIS
9595-2 [11]. The protocol specification for the Common Management
Information Protocol (CMIP) is found in ISO DIS 9596-2 [12].
7.1. CMIS Services
7.1.1. CMIS Services Overview
All of the CMIS services listed in Table 1 are allowed with the CMOT
approach: M-INITIALISE, M-TERMINATE, M-ABORT, M-EVENT-REPORT, M-GET,
M-SET, M-ACTION, M-CREATE, and M-DELETE. The specific services
supported by a system will be determined by the functional unit group
or groups to which a system belongs.
7.1.2. Functional Units
The CMIS services supported are designated in terms of functional
units [11]. Each functional unit corresponds to the invoker or
performer aspect of a particular service. (The terms "invoker" and
"performer" are taken from ROSE and refer to the caller of and
responder to a remote operation, respectively.) The "stand alone"
functional units associated with each of the management services are
given in Table 2 as functional units 0-17. The number following the
name of each functional unit in the table is defined by CMIP [12] to
identify that particular functional unit. The functional units are
used by the CMISE-service-user at the time of association
establishment to indicate which services it is willing to support.
+---------------------------------+------------------------+------+
| Functional Unit | Service Primitives | Mode |
+---------------------------------+------------------------+------+
| conf. event report invoker(0) | M-EVENT-REPORT Req/Conf| C |
| conf. event report performer(1) | M-EVENT-REPORT Ind/Rsp | C |
| event report invoker(2) | M-EVENT-REPORT Req | U |
| event report performer(3) | M-EVENT-REPORT Ind | U |
| confirmed get invoker(4) | M-GET Req/Conf | N/A |
| confirmed get performer(5) | M-GET Ind/Rsp | N/A |
| confirmed set invoker(6) | M-SET Req/Conf | C |
| confirmed set performer(7) | M-SET Ind/Rsp | C |
| set invoker(8) | M-SET Req | U |
| set performer(9) | M-SET Ind | U |
| confirmed action invoker(10) | M-ACTION Req/Conf | C |
| confirmed action performer(11) | M-ACTION Ind/Rsp | C |
| action invoker(12) | M-ACTION Req | U |
| action performer(13) | M-ACTION Ind | U |
| confirmed create invoker(14) | M-CREATE Req/Conf | N/A |
| confirmed create performer(15) | M-CREATE Ind/Rsp | N/A |
| confirmed delete invoker(16) | M-DELETE Req/Conf | N/A |
| confirmed delete performer(17) | M-DELETE Ind/Rsp | N/A |
| multiple reply(18) | Linked Identification | N/A |
| multiple object selection(19) | Scope, Filter, Sync. | N/A |
| extended service(20) | Extended Presentation | N/A |
+---------------------------------+------------------------+------+
C = confirmed, U = non-confirmed, N/A = not applicable
Table 2. Functional Units
In addition to the stand alone functional units, there are three
additional functional units. If any of these additional functional
units are selected, then at least one of the stand alone functional
units must be selected. The multiple reply functional unit makes
available the use of the linked identification parameter in the
selected stand alone functional units. This makes possible the use
of linked reply (multiple CMIP PDU responses to a single request).
The multiple object selection functional unit makes available the use
of the scope, filter, and synchronization parameters in the selected
stand alone functional units. If the multiple object selection
functional unit is selected, then the multiple reply functional unit
must also be selected. The extended services functional unit makes
available presentation layer services in addition to the P-DATA
service. Selecting this functional unit has no effect in the context
of CMOT, since the lightweight presentation layer provides only
minimal ISO presentation services.
7.1.3. Functional Unit Groups
In order to assist in the reduction of code size and complexity for
different types of devices, a number of "functional unit groups" have
been defined. Each of these groups indicates a set of services
defined for either a manager or an agent. The "negotiation"
concerning which functional unit groups are supported is done by
means of the Functional Units parameter of the M-INITIALISE service
(see section 7.1.4.1). There are five functional unit groups for
managers: Event Monitor, Monitoring Manager, Simple Manager,
Controlling Manager, and Full Manager. Each functional unit group is
a superset of the preceding group. There are five functional unit
groups for agents: Event Sender, Monitored Agent, Simple Agent,
Controlled Agent, and Full Agent. Again, each functional unit group
is a superset of the preceding group. The operations supported for
each functional unit group are summarized in Table 3.
+--------------------+------+-----+-----+-------+------+-----+------+
| |Event | Get | Set |Create/|Action|Mult.|Mult. |
|Functional Unit |Report| | |Delete | |Reply|Object|
|Groups | | | | | | |Select|
+--------------------+------+-----+-----+-------+------+-----+------+
| 1. Event Monitor | U | no | no | no | no | no | no |
| 2. Event Sender | U | no | no | no | no | no | no |
| 3. Monitoring Mgr. | U | yes | no | no | no | no | no |
| 4. Monitored Agent | U | yes | no | no | no | no | no |
| 5. Simple Manager | U | yes | C | no | no | yes | no* |
| 6. Simple Agent | U | yes | C | no | no | yes | no* |
| 7. Controlling Mgr.| U | yes | U/C | yes | no | yes | yes |
| 8. Controlled Agent| U | yes | U/C | yes | no | yes | yes |
| 9. Full Manager | U/C | yes | U/C | yes | U/C | yes | yes |
|10. Full Agent | U/C | yes | U/C | yes | U/C | yes | yes |
+--------------------+------+-----+-----+-------+------+-----+------+
C = confirmed, U = non-confirmed
* Simple Managers and Agents must support "oneLevel" scoping for all
and only those cases where it is required to access a whole table
and may support synchronization other than "best effort"; no support
for filtering is required.
Table 3. Functional Unit Groups
A conformant system must support at least one of these functional
unit groups. A system may support both a manager group and an agent
group. A system only needs to implement the services and service
primitives required for the groups that it supports. In addition, a
system may support services that are not required by any group that
it supports.
7.1.4. M-INITIALISE Parameters
The M-INITIALISE service is provided by the ACSE A-ASSOCIATE service.
The parameters for the M-INITIALISE service are defined in [11] and
summarized in Table 4.
+-------------------+-----------+-----------+
| Parameter Name | Req/Ind | Rsp/Conf |
+-------------------+-----------+-----------+
| Functional Units | Mandatory | Mandatory |
| User Information | Optional | Optional |
| Access Control | Optional | Optional |
+-------------------+-----------+-----------+
Table 4. M-INITIALISE Parameters
Notice that the further agreement has been made that the Functional
Units parameter is mandatory at all times. The M-INITIALISE
parameters are conveyed as ACSE user information in the ACSE request
PDU.
7.1.4.1. Functional Units
The exchange of functional units between the initiating CMISE-
service-user and the responding CMISE-service-user is required. This
allows the CMIS-service-users to inform each other which functional
units are supported. CMIP [12] defines a 21-bit BIT STRING to
communicate which functional units are supported. A functional unit
is supported if the corresponding bit in this bit string is one. The
correspondence between functional units and functional unit groups is
given in Table 5. The left column gives the functional unit
corresponding to a particular bit position. The numbers along the top
of the table indicate the functional unit group (the numbers of the
functional unit groups are given in Table 3). The various columns
indicate the value of each bit for a particular functional unit
group.
+------------------------------+---+---+---+---+---+---+---+---+---+---+
|Functional Unit | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10|
+------------------------------+---+---+---+---+---+---+---+---+---+---+
|conf. event report invoker(0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
|conf. event report perf.(1) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
|event report invoker(2) | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
|event report performer(3) | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
|confirmed get invoker(4) | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
|confirmed get performer(5) | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
|confirmed set invoker(6) | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
|confirmed set performer(7) | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 |
|set invoker(8) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
|set performer(9) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
|confirmed action invoker(10) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
|confirmed action performer(11)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
|action invoker(12) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
|action performer(13) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
|confirmed create invoker(14) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
|confirmed create performer(15)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
|confirmed delete invoker(16) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
|confirmed delete performer(17)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
|multiple reply(18) | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 |
|multiple object selection(19) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |
|extended service(20) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+------------------------------+---+---+---+---+---+---+---+---+---+---+
| | M | A | M | A | M | A | M | A | M | A |
+------------------------------+---+---+---+---+---+---+---+---+---+---+
1 = supported, 0 = not supported, M = manager, A = agent
Table 5. Functional Unit Group Values
The "negotiation" using functional units proceeds as follows. The
initiating CMISE-service-user (manager or agent) sends the functional
units representing the functional unit group to which it belongs.
The responding CMISE-service-user sends the functional units
representing the functional unit group to which it belongs. (If an
application process belongs to both a manager and an agent functional
unit group, then both functional unit groups are indicated using the
same functional unit bit string.) If the functional unit groups
supported by the two application entities do not allow meaningful
communication, then either entity may refuse the association.
Meaningful communication is defined as the ability of the entity to
invoke or perform at least one CMIS operation supported by the other
entity (i.e., some "complementary" set of functional units exists).
After an association has been established, a system must provide the
proper response for functional units that it has indicated it can
support and should gracefully refuse other requests in accordance
with the protocol.
7.1.4.2. User Information
The User Information parameter is optional. No entity is required to
send this parameter, but all entities are expected to tolerate
receipt of it.
One possible use of the User Information parameter is to convey
information describing MIB extensions supported by the manager or
agent. This can be viewed as a further way of refining the
application context. The mechanism for doing this is not defined at
this time.
7.1.4.3. Access Control
The CMIS M-INITIALISE Access Control parameter is optional. Access
control is supported on a per association basis using ACSE. It is
recommended (but not required) that the access control parameter be
used for each A-ASSOCIATE request (via M-INITIALISE).
Access control is also possible on a per request basis with the CMIS
Access Control parameter. This parameter might be used to implement
security similar to the community access rights mechanism provided by
SNMP [4]. It is expected that the Access Control parameter will be
used to implement the standard TCP/IP authentication mechanism once
this has been defined.
7.2. Supporting Services
The M-INITIALISE, M-TERMINATE, and M-ABORT services assume the use of
ACSE. The following ACSE services are required: A-ASSOCIATE, A-
RELEASE, A-ABORT, and A-P-ABORT. The rest of the CMIP protocol uses
the RO-INVOKE, RO-RESULT, RO-ERROR, and RO-REJECT services of ROSE.
7.3. CMIP Agreements
The following sections contain specific CMIP agreements in addition
to those specified in the CMIP standard [12].
7.3.1. Invoke Identifier
It is required that there be a unique invoke identifier (present in
the ROSE PDU) for successive invocations on the same association.
The invoke identifier is provided by the invoking CMISE-service-user.
Invoke identifiers should increase monotonically during the lifetime
of an association. Semantically, the invoke identifier is a Counter
as defined in [2]. Unique identifiers will allow the detection of
lost and duplicate requests.
7.3.2. Object Class
The object class field of all CMIP PDUs shall be limited to the
"globalForm" choice:
ObjectClass ::=
CHOICE {
globalForm [0] IMPLICIT OBJECT IDENTIFIER
}
7.3.3. Object Instance
The object instance field of all CMIP PDUs is limited to the
"distinguishedName" choice:
ObjectInstance ::=
CHOICE {
distinguishedName [2] IMPLICIT DistinguishedName
}
The definition for DistinguishedName is imported from CCITT X.500 and
ISO DIS 9594-2 [26]:
DistinguishedName ::= RDNSequence
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::= SET OF AttributeValueAssertion
The definition for AttributeValueAssertion is contained in CMIP [12]:
AttributeValueAssertion ::= SEQUENCE { AttributeId, AttributeValue }
AttributeId ::=
CHOICE {
globalId [0] IMPLICIT OBJECT IDENTIFIER
localId [1] IMPLICIT INTEGER
}
AttributeValue ::= ANY DEFINED BY attributeId
Those attributes to be used as the distinguished attributes of a
managed object are defined at the time of registration of the object
class and are identified in the NAMES clause of the OBJECT-CLASS
macro.
When there is no instance information to convey about a managed
object, then the following "empty" object instance shall be used: The
"distinguishedName" choice of ObjectInstance shall be an RDNSequence
consisting of a SEQUENCE of one RelativeDistinguishedName. That
RelativeDistinguishedName shall be an empty SET of
AttributeValueAssertions.
7.3.4. Access Control
The access control parameter is optional. The receipt of this
parameter must be tolerated (i.e., gracefully accepted), but a
receiving entity is free to ignore this information. The Access
Control field is defined in [12] as EXTERNAL. Until a more
sophisticated access control mechanism is defined, simple
authentication can be accomplished by using an unencrypted password
in the access control field. The definition of this EXTERNAL is the
same as that for the ACSE Access Control field (section 8.3.2).
7.3.5. Synchronization
Support for "best effort" synchronization is required. Atomic
synchronization may also be supported, but is not required.
7.3.6. Scope
Scoping is supported if the multiple object selection functional unit
is selected. If scoping is supported, all values of the scope field
shall be supported.
7.3.7. Filter
Filtering is supported if the multiple object selection functional
unit is selected. If filtering is supported, it is not required that
all features of filtering be supported. The following are the
minimal filtering requirements for any system that supports
filtering. In the CMIP field CMISFilter, at least two instances of
the binary operators ("and," "or") must be supported. Support for
additional instances of these operators is not required. Double
"not" need not be supported. In FilterItem, the arithmetic
operations ("equality", "greaterOrEqual," "lessOrEqual") must be
supported. The "present" choice of FilterItem must also be
supported. It is not required to support string operations (namely,
the "substrings" choice of the FilterItem type). Thus, the minimal
requirements for filtering yield this restricted definition of
FilterItem:
FilterItem ::=
CHOICE {
equality [0] AttributeValueAssertion,
greaterOrEqual [2] AttributeValueAssertion,
lessOrEqual [3] AttributeValueAssertion,
present [4] AttributeID
}
7.3.8. Attribute Identifier
Both choices for the CMIP AttributeId field are allowed:
AttributeId ::=
CHOICE {
globalId [0] IMPLICIT OBJECT IDENTIFIER,
localId [1] IMPLICIT INTEGER
}
The "globalId" form of AttributeId is required if scoping is used
(i.e., the value of the scope field is other than "baseObject").
7.3.9. Event Type Identifier
Both choices for the CMIP EventTypeId field are allowed:
EventTypeId ::=
CHOICE {
globalId [6] IMPLICIT OBJECT IDENTIFIER,
localId [7] IMPLICIT INTEGER
}
7.3.10. Action Type Identifier
Both choices for the CMIP ActionTypeId field are allowed:
ActionTypeId ::=