Network Working Group U. Warrier
Request for Comments: 1095 Unisys Corporation
L. Besaw
Hewlett-Packard
April 1989
The Common Management Information Services and Protocol over TCP/IP
(CMOT)
Table of Contents
Appendix A - The CMOT Group ....................................... 52
Appendix B - Management Information Summary ....................... 53
Appendix C - Sample Protocol Exchanges ............................ 60
This memo defines a network management architecture that uses the
International Organization for Standardization's (ISO) Common
Management Information Services/Common Management Information
Protocol (CMIS/CMIP) in a TCP/IP environment. This architecture
provides a means by which control and monitoring information can be
exchanged between a manager and a remote network element. In
particular, this memo defines the means for implementing the Draft
International Standard (DIS) version of CMIS/CMIP on top of Internet
transport protocols for the purpose of carrying management
information defined in the Internet-standard management information
base. DIS CMIS/CMIP is suitable for deployment in TCP/IP networks
while CMIS/CMIP moves toward becoming an International Standard.
Together with the relevant ISO standards and the companion RFCs that
describe the initial structure of management information and
management information base, these documents provide the basis for a
comprehensive architecture and system for managing TCP/IP-based
internets, and in particular the Internet.
The Internet Activities Board (IAB) has designated two different
network management protocols with the same status of "Draft Standard"
and "Recommended".
The two protocols are the Common Management Information Services and
Protocol over TCP/IP (CMOT) (this memo) and the Simple Network
Management Protocol (SNMP) [4].
Warrier & Besaw [Page 3]
RFC 1095 CMOT April 1989
The IAB intends each of these two protocols to receive the attention
of implementers and experimenters. The IAB seeks reports of
experience with these two protocols from system builders and users.
By this action, the IAB recommends that all IP and TCP
implementations be network manageable (e.g., implement the Internet
MIB [3], and that implementations that are network manageable are
expected to adopt and implement at least one of these two Internet
Draft Standards.
Distribution of this memo is unlimited.
As reported in RFC 1052, "IAB Recommendations for the Development of
Internet Network Management Standards" [1], the Internet Activities
Board (IAB) has directed the Internet Engineering Task Force (IETF)
to coordinate the work of three working groups in the area of network
management. First, the MIB working group was charged with the
specification and definition of elements to be included in the
Management Information Base (MIB). Second, the SNMP working group
was charged with defining the modifications to the Simple Network
Management Protocol (SNMP) necessary to accommodate the short-term
needs of the network vendor and operations communities. Third, the
Netman working group was directed to meet the longer-term needs of
the Internet community by developing a network management system
based on ISO CMIS/CMIP. Both the Netman working group and the SNMP
working group were directed to align their work with the output of
the MIB working group in order to ensure compatibility of management
information between the short-term and long-term approaches to the
management of TCP/IP-based internets. This will enable a smooth
transition from the short-term protocol (SNMP) to the long-term
protocol (CMIP).
The MIB working group has produced two memos. RFC 1065 [2] defines
the Structure of Management Information (SMI) that is necessary for
naming and defining managed objects in the MIB. RFC 1066 [3] defines
the list of managed objects contained in the initial TCP/IP MIB. The
SNMP working group has produced a memo [4] giving the protocol
specification for SNMP and providing the SNMP protocol-specific
interpretation of the Internet-standard MIB defined in RFC 1066.
This memo is the output of the Netman working group. As directed by
the IAB in RFC 1052, it addresses the need for a long-term network
management system based on ISO CMIS/CMIP. The network management
approach of using ISO protocols in a TCP/IP environment to manage
TCP/IP networks can be described as "CMIP Over TCP/IP" (CMOT). This
memo specifies the CMOT architecture and the protocol agreements
Warrier & Besaw [Page 4]
RFC 1095 CMOT April 1989
necessary to implement CMIP and accompanying ISO protocols over the
TCP and UDP transport protocols. In addition, this memo provides an
interpretation of RFC 1066 that makes it possible to use CMIP to
convey management information defined in the Internet-standard MIB.
There is widespread vendor support for the CMOT approach to network
management. This is amply shown by the Netman demonstration of
prototype CMOT implementations at the Interop '88 TCP/IP
Interoperability Conference. The demonstration also showed the
feasibility and power of the CMIS/CMIP framework for multivendor
network management. Now that CMIS/CMIP has been voted a Draft
International Standard (DIS), many vendors feel that the ISO standard
has become a stable basis for product development. The clear need to
standardize this development has led to the present profile of CMIP.
It is expected that this profile will not change while the ISO
standard moves from DIS status to International Standard (IS) status.
If, however, the standard does change unexpectedly, the Netman
working group will review such changes for appropriate action.
Another rationale for the CMOT approach is that it will facilitate
the early use of ISO network management standards in large
operational networks. This will make it possible for the Internet
community to make valuable recommendations to ISO in the language of
OSI management based on actual experience with the use and
implementation of these standards. There is continuing network
management standards development work in ISO where such contributions
would be valuable.
The CMOT architecture is based on the Open Systems Interconnection
(OSI) management framework and models developed by ISO. This memo
contains a set of protocol agreements for implementing a network
management system based on this architecture. The protocol agreement
sections of this memo must be read in conjunction with ISO and
Internet documents defining specific protocol standards. Documents
defining the following ISO standards are required for the
implementor: Abstract Syntax Notation One (ASN.1) [5, 6], Association
Control (ACSE) [7, 8], Remote Operations (ROSE) [9, 10], Common
Management Information Services (CMIS) [11], and Common Management
Information Protocol (CMIP) [12]. RFC 1085 [13] is required for the
specification of a lightweight presentation layer protocol used in
this profile. In addition, RFC 1065 [2] and RFC 1066 [3] are
required for a definition of the initial SMI and MIB to be used with
the CMOT management system.
This memo is divided into two main parts. The first part presents
concepts and models; the second part contains the protocol agreements
necessary for implementation of the CMOT network management system.
The first part of the memo is divided into three sections: section 3
Warrier & Besaw [Page 5]
RFC 1095 CMOT April 1989
contains tutorial information on the OSI management framework;
section 4 defines the basic CMOT approach; and section 5 discusses
the area of management information and specifies how the abstract
management information defined in the Internet-standard SMI and MIB
map into CMIP. The second part of this memo is divided into sections
for each of the protocols for which implementors' agreements are
needed: CMISE, ACSE, ROSE, and the lightweight presentation protocol.
The protocol profile defined in this part draws on the technical work
of the OSI Network Management Forum [14] and the Network Management
Special Interest Group (NMSIG) of the National Institute of Standards
and Technology (NIST) (formerly the National Bureau of Standards).
Wherever possible, an attempt has been made to remain consistent with
the protocol agreements reached by these groups.
Warrier & Besaw [Page 6]
RFC 1095 CMOT April 1989
Part I: Concepts and Models
The OSI management framework [15] presents the basic concepts and
models required for developing network management standards. OSI
management provides the ability to monitor and control network
resources, which are represented as "managed objects." The following
elements are essential for the description of a network management
architecture and the standardization of a network management system:
a model or set of models for understanding management; a common
structure of management information for registering, identifying, and
defining managed objects; detailed specifications of the managed
objects; and a set of services and related protocols for performing
remote management operations.
The basic concepts underlying OSI network management are quite simple
[16]. There reside application processes called "managers" on
managing systems (or management stations). There reside application
processes called "agents" on managed systems (or network elements
being managed). Network management occurs when managers and agents
conspire (via protocols and a shared conceptual schema) to exchange
monitoring and control information useful to the management of a
network and its components. The terms "manager" and "agent" are also
used in a loose and popular sense to refer to the managing and
managed system, respectively.
The shared conceptual schema mentioned above is a priori knowledge
about "managed objects" concerning which information is exchanged.
Managed objects are system and networking resources (e.g., a modem, a
protocol entity, an IP routing table, a TCP connection) that are
subject to management. Management activities are effected through the
manipulation of managed objects in the managed systems. Using the
management services and protocol, the manager can direct the agent to
perform an operation on a managed object for which it is responsible.
Such operations might be to return certain values associated with a
managed object (read a variable), to change certain values associated
with a managed object (set a variable), or perform an action (such as
self-test) on the managed object. In addition, the agent may also
forward notifications generated asynchronously by managed objects to
the manager (events or traps).
The terms "manager" and "agent" are used to denote the asymmetric
relationship between management application processes in which the
manager plays the superior role and the agent plays the subordinate.
Warrier & Besaw [Page 7]
RFC 1095 CMOT April 1989
However, the specification of the management protocol (CMIP) defines
a peer protocol relationship that makes no assumptions concerning
which end opens or closes a connection, or the direction of
management data transfer. The protocol mechanisms provided are fully
symmetric between the manager and the agent; CMIS operations can
originate at either the manager or agent, as far as the protocol is
concerned. This allows the possibility of symmetric as well as
asymmetric relationships between management processes. Most devices
will contain management applications that can only assume the agent
role. Applications on managing systems, however, may well be able to
play both roles at the same time. This makes possible "manager to
manager" communication and the ability of one manager to manage
another.
Network management may be modeled in different ways. Three models
are typically used to describe OSI management [17, 18]. An
organizational model describes ways in which management can be
administratively distributed. The functional model describes the
management functions and their relationships. The information model
provides guidelines for describing managed objects and their
associated management information.
The organizational model introduces the concept of a management
"domain." A domain is an administrative partition of a network or
internet for the purpose of network management. Domains may be
useful for reasons of scale, security, or administrative autonomy.
Each domain may have one or more managers monitoring and controlling
agents in that domain. In addition, both managers and agents may
belong to more than one management domain. Domains allow the
construction of both strict hierarchical and fully cooperative and
distributed network management systems.
The OSI Management Framework [15] defines five facilities or
functional areas to meet specific management needs. This has proved
to be a helpful way of partitioning the network management problem
from an application point of view. These facilities have come to be
known as the Specific Management Functional Areas (SMFAs): fault
management, configuration management, performance management,
accounting management, and security management. Fault management
provides the ability to detect, isolate, and correct network
problems. Configuration management enables network managers to
change the configuration of remote network elements. Performance
Warrier & Besaw [Page 8]
RFC 1095 CMOT April 1989
management provides the facilities to monitor and evaluate the
performance of the network. Accounting management makes it possible
to charge users for network resources used and to limit the use of
those resources. Finally, security management is concerned with
managing access control, authentication, encryption, key management,
and so on.
The OSI Management Framework considers all information relevant to
network management to reside in a Management Information Base (MIB),
which is a "conceptual repository of management information."
Information within a system that can be referenced by the management
protocol (CMIP) is considered to be part of the MIB. Conventions for
describing and uniquely identifying the MIB information allow
specific MIB information to be referenced and operated on by the
management protocol. These conventions are called the Structure of
Management Information (SMI). The information model is described
more fully in section 5.
The following ISO application services and protocols are necessary
for doing network management using the OSI framework: ACSE, ROSE, and
CMIS/CMIP. All three of these protocols are defined using ASN.1 [5].
The ASN.1 modules defining each of these protocols are found in the
relevant standards documents. The encoding rules for ASN.1 [6]
provide a machine-independent network representation for data.
A brief overview of the terminology associated with the OSI
application layer structure is presented here. A complete treatment
of the subject can be found in the OSI Application Layer Structure
document [22].
In the OSI environment, communication between "application processes"
is modeled by communication between application entities. An
"application entity" represents the communication functions of an
application process. There may be multiple sets of OSI communication
functions in an application process, so a single application process
may be represented by multiple application entities. However, each
application entity represents a single application process. An
application entity contains a set of communication capabilities
called "application service elements." An application service element
is a coherent set of integrated functions. These application service
elements may be used independently or in combination. Examples of
application service elements are X.400, FTAM, ACSE, ROSE, and CMISE.
When communication is required between two application entities, one
Warrier & Besaw [Page 9]
RFC 1095 CMOT April 1989
or more "application associations" are established between them.
Such an association can be viewed as a connection at the level of the
application layer. An "application context" defines the set of
application service elements which may be invoked by the user of an
application association. The application context may prescribe one
or more application service elements.
Generally, an "application layer protocol" is realized by the use of
the functionality of a number of application service elements. This
functionality is provided by the specification of a set of
application protocol data units (APDUs) and the procedures governing
their use. In general, the operation of an application layer
protocol may require the combination of APDUs from different
application service elements. The application entity makes direct
use of presentation context identifiers for the specification and
identification of APDUs.
The Association Control Service Element (ACSE) is used to establish
and release associations between application entities. Before any
management operations can be performed using CMIP, it is necessary
for the two application entities involved to form an association.
Either the manager or the agent can initiate association
establishment. ACSE allows the manager and agent to exchange
application entity titles for the purpose of identification and
application context names to establish an application context. As
stated above, an application context defines what service elements
(for instance, ROSE and CMISE) may be used over the association.
After the association is established, ACSE is not used again until
the association is released by the manager or agent.
The Remote Operation Service Element (ROSE) is the ISO equivalent of
remote procedure call. ROSE allows the invocation of an operation to
be performed on a remote system. The Remote Operation protocol
contains an invoke identifier for correlating requests and responses,
an operation code, and an argument field for parameters specific to
the operation. ROSE can only be invoked once an application
association has been established. CMIP uses the transaction-oriented
services provided by ROSE for all its requests and responses. CMIP
also uses the error response facilities provided by ROSE.
The Common Management Information Service Element (CMISE) is the
service element that provides the basic management services. The
Warrier & Besaw [Page 10]
RFC 1095 CMOT April 1989
CMISE is a user of both ROSE and ACSE. The CMISE provides both
confirmed and unconfirmed services for reporting events and
retrieving and manipulating management data. These services are used
by manager and agent application entities to exchange management
information. Table 1 provides a list of the CMISE services. In
addition, the CMISE also provides the ability to issue a series of
(multiple) linked replies in response to a single request.
+-----------------+-------------------------+
| Service | Type |
+-----------------+-------------------------+
| M-INITIALISE | confirmed |
| M-TERMINATE | confirmed |
| M-ABORT | non-confirmed |
| M-EVENT-REPORT | confirmed/non-confirmed |
| M-GET | confirmed |
| M-SET | confirmed/non-confirmed |
| M-ACTION | confirmed/non-confirmed |
| M-CREATE | confirmed |
| M-DELETE | confirmed |
+-----------------+-------------------------+
Table 1. CMISE Service Summary
CMIS services can be divided into two main classes: management
association services and information transfer services. Furthermore,
there are two types of information transfer services: management
notification services and management operation services. In addition
to the other CMIS services, the CMISE provides facilities that enable
multiple responses to confirmed operations to be linked to the
operation by the use of a linked identification parameter.
CMIS provides services for the establishment and release of
application associations. These services control the establishment
and normal and abnormal release of a management association. These
services are simply pass-throughs to ACSE.
The M-INITIALISE service is invoked by a CMISE-service-user to
establish an association with a remote CMISE-service-user for the
purpose of exchanging management information. A reply is expected.
(A CMISE-service-user is that part of an application process that
makes use of the CMISE.)
The M-TERMINATE service is invoked by a CMISE-service-user to release
Warrier & Besaw [Page 11]
RFC 1095 CMOT April 1989
an association with a remote CMISE-service-user in an orderly manner.
A reply is expected.
The M-ABORT service is invoked by a CMISE-service-user or a CMISE-
service-provider to release an association with a remote CMISE-
service-user in an abrupt manner.
The definition of notification and the consequent behavior of the
communicating entities is dependent upon the specification of the
managed object which generated the notification and is outside the
scope of CMIS. CMIS provides the following service to convey
management information applicable to notifications.
The M-EVENT-REPORT service is invoked by a CMISE-service-user to
report an event about a managed object to a remote CMISE-service-
user. The service may be requested in a confirmed or a non-confirmed
mode. In the confirmed mode, a reply is expected.
The definition of the operation and the consequent behavior of the
communicating entities is dependent upon the specification of the
managed object at which the operation is directed and is outside the
scope of CMIS. However, certain operations are used frequently
within the scope of management and CMIS provides the following
definitions of the common services that may be used to convey
management information applicable to the operations.
The M-GET service is invoked by a CMISE-service-user to request the
retrieval of management information from a remote CMISE-service-user.
The service may only be requested in a confirmed mode. A reply is
expected.
The M-SET service is invoked by a CMISE-service-user to request the
modification of management information by a remote CMISE-service-
user. The service may be requested in a confirmed or a non-confirmed
mode. In the confirmed mode, a reply is expected.
The M-ACTION service is invoked by a CMISE-service-user to request a
remote CMISE-service-user to perform an action. The service may be
requested in a confirmed or a non-confirmed mode. In the confirmed
mode, a reply is expected.
The M-CREATE service is invoked by a CMISE-service-user to request a
remote CMISE-service-user to create another instance of a managed
object. The service may only be requested in a confirmed mode. A
Warrier & Besaw [Page 12]
RFC 1095 CMOT April 1989
reply is expected.
The M-DELETE service is invoked by a CMISE-service-user to request a
remote CMISE-service-user to delete an instance of a managed object.
The service may only be requested in a confirmed mode. A reply is
expected.
The CMOT (CMIP Over TCP/IP) architecture is based on the OSI
management framework [15] and the models, services, and protocols
developed by ISO for network management. The CMOT architecture
demonstrates how the OSI management framework can be applied to a
TCP/IP environment and used to manage objects in a TCP/IP network.
The use of ISO protocols for the management of widely deployed TCP/IP
networks will facilitate the ultimate migration from TCP/IP to ISO
protocols. The concept of proxy management is introduced as a useful
extension to the architecture. Proxy management provides the ability
to manage network elements that either are not addressable by means
of an Internet address or use a network management protocol other
than CMIP.
The CMOT architecture specifies all the essential components of a
network management architecture. The OSI management framework and
models are used as the foundation for network management. A
protocol-dependent interpretation of the Internet SMI [2] is used for
defining management information. The Internet MIB [3] provides an
initial list of managed objects. Finally, a means is defined for
using ISO management services and protocols on top of TCP/IP
transport protocols. Management applications themselves are not
included within the scope of the CMOT architecture. What is
currently standardized in this architecture is the minimum required
for building an interoperable multivendor network management system.
Applications are explicitly left as a competitive issue for network
developers and providers.
The following sections indicate how the CMOT architecture applies the
OSI managements models and point out any limitations the CMOT
architecture has as it is currently defined in this memo.
It is beyond the scope of this memo to define the relations and
interactions between different management domains. The current CMOT
architecture concerns itself only with the operations and
characteristics of a single domain of management. The extension of
Warrier & Besaw [Page 13]
RFC 1095 CMOT April 1989
the mechanisms defined here to include multiple domains is left for
further study.
The CMOT architecture provides the foundation for carrying out
management in the five functional areas (fault, configuration,
performance, accounting, and security), but does not address
specifically how any of these types of management are accomplished.
It is anticipated that most functional requirements can be satisfied
by CMIS. The greatest impact of the functional requirements in the
various areas will likely be on the definition of managed objects.
There are two different SMI specifications that are important to the
CMOT architecture. The first is the SMI currently being defined by
ISO [19]. This SMI is important to the CMOT approach because the ISO
management protocol CMIP has been designed with the ISO model of
management information in mind. The second SMI of importance is the
that defined by the IETF MIB working group for use in defining the
Internet MIB [3]. This Internet SMI, which is loosely based on a
simplified version of the ISO SMI, is important because the managed
objects defined for TCP/IP networks to be used by CMOT are defined in
terms of it. Thus, in order to make the CMOT architecture complete,
it will be necessary to show how the Internet SMI maps into CMIP in
such a way as to enable it to convey the management information
defined in the Internet MIB. This is done in the section devoted to
management information (section 5).
The objective of the CMOT protocol architecture is to map the OSI
management protocol architecture into the TCP/IP environment. The
model presented here follows the OSI model at the application layer,
while using Internet protocols at the transport layer. The ISO
application protocols used for network management are ACSE, ROSE, and
CMIP. Instead of implementing these protocols on top of the ISO
presentation, session, and transport layer protocols, the protocol
data units (PDUs) for ACSE, ROSE, and CMIP are carried using the
Internet transport protocols UDP [20] and TCP [21]. This is made
possible by means of the lightweight presentation protocol defined in
RFC 1085 [13] that maps ROSE and ACSE onto TCP/UDP/IP. The use of
Internet transport protocols is transparent to network management
applications, since they are presented with real ISO services.
Warrier & Besaw [Page 14]
RFC 1095 CMOT April 1989
Given that it is desired to put ISO application protocols on top of
TCP/IP, how is this best accomplished? It is necessary somehow to
fill the "gap" between the ISO protocols (ACSE and ROSE) and the
Internet protocols (UDP and TCP). Two basic approaches were
considered.
One possible approach [23] is to extend the ISO portion of the
protocol stack down to the transport layer. The ISO Transport
Protocol Class 0 (TP 0) then uses TCP instead of an ISO network
protocol. Effectively, this treats TCP as a reliable network
connection analogous to X.25. This approach allows us to operate
"standard" ISO applications over TCP regardless of their service
requirements, since all ISO services are provided. In this case,
network management is just another such application. The major
drawback with this approach is that full ISO presentation, session,
and transport layers are expensive to implement (both in terms of
processing time and memory).
Another approach is presented in RFC 1085. Since the service
elements required for network management (ACSE, ROSE, CMISE) do not
require the use of full ISO presentation layer services, it is
possible to define a "streamlined" presentation layer that provides
only the services required. This lightweight presentation protocol
(LPP) allows the use of ISO presentation services over both TCP and
UDP. This approach eliminates the necessity of implementing ISO
presentation, session, and transport protocols for the sake of doing
ISO network management in a TCP/IP environment. This minimal
approach is justified because this non-ISO presentation protocol used
is very small and very simple. Thus, the LPP defined in RFC 1085
provides a compact and easy to implement solution to the problem.
The resulting CMOT protocol stack is shown in Figure 1.
Warrier & Besaw [Page 15]
RFC 1095 CMOT April 1989
Manager Agent
+-----------------------+ +-----------------------+
| | | |
| +----+ +----+ +-----+ | <-------> | +----+ +----+ +-----+ |
| |ACSE| |ROSE| |CMISE| | CMIP | |ACSE| |ROSE| |CMISE| |
| +----+ +----+ +-----+ | | +----+ +----+ +-----+ |
| | | |
+-----------------------+ +-----------------------+
| LPP | | LPP |
+-----------------------+ +-----------------------+
| TCP | UDP | | TCP | UDP |
+-----------------------+ +-----------------------+
| IP | | IP |
+-----------------------+ +-----------------------+
| Link | | Link |
+-----------------------+ +-----------------------+
| |
| |
| |
=========================================================
Network
=========================================================
Figure 1. The CMOT Protocol Architecture
It is important to note that the presentation services provided by
the LPP are "real" (but minimal) ISO presentation services [24].
This provides a clear migration path to "full ISO" in the future.
Such a migration would be accomplished by substituting ISO protocols
for the Internet protocols TCP, UDP, and IP [25], and replacing the
LPP with ISO presentation and session protocols. No changes will be
required in the ISO application layer protocols. For this reason,
investments in application development will be well preserved.
The quality of transport service needed for network management
applications is an issue that has caused much controversy, yet it has
never been resolved. There are two basic approaches: datagram-
oriented and connection-oriented. There are advantages and
disadvantages to both of these two approaches. While the datagram-
oriented approach is simple, requires minimal code space, and can
operate under conditions where connections may not be possible, the
connection-oriented approach offers data reliability and provides
guaranteed and consistent service to the driving application.
This memo does not take sides on this issue. Rather it passes such
Warrier & Besaw [Page 16]
RFC 1095 CMOT April 1989
resolution to the network management applications, which are
ultimately the point where the requirements from the underlying
service need to be determined. As such, the CMOT protocol
architecture provides both services. The presentation layer service
allows the application to select either high or low quality service
for the underlying transport. Depending on this choice, the LPP will
use either UDP (low quality) or TCP (high quality) to establish the
application association and carry the application data. It is
important, however, for the application to be aware of the quality of
service that it is using: low quality means low quality! The use of
an unreliable transport like UDP necessarily puts more burden on the
application.
Proxy is a term that originated in the legal community to indicate an
entity empowered to perform actions on behalf of another. In our
context, a proxy is a manager empowered to perform actions on behalf
of another manager. This may be necessary because the manager cannot
communicate directly with the managed devices either for security or
other administrative reasons or because of incompatible communication
mechanisms or protocols. In either case, the proxy assumes the agent
role with respect to the requesting manager and the manager role with
respect to the managed device.
Some network elements, such as modems or bridges, may not be able to
support CMIP and all the associated protocols. In addition, such
devices may not have Internet addresses. Such devices are called
"limited systems". It may be possible to manage these devices using
proprietary mechanisms or other standard protocols (such as the IEEE
802.1 management protocol for managing bridges). In cases where it
is desirable to integrate the management of such devices with the
overall CMOT management of an internet, it is necessary to use proxy
management. Some network elements that are not "limited systems" as
described above may still benefit from the use of proxy management.
If the management protocol supported by such a system is proprietary
or some standard protocol other than CMIP (such as SNMP), then CMOT
proxy management can be used to integrate the management of such
systems.
A proxy operates in the following manner. When a CMOT manager wants
to send a request to a managed device that it cannot communicate with
directly, it routes the request to the proxy. The proxy maps the
CMIP request into the information schema understood by the managed
device and sends the appropriate request to the managed device using
the native management protocol of the device. When the proxy
receives the response from the managed device, it uses CMIP to return
the information to the manager that made the original request.
Warrier & Besaw [Page 17]
RFC 1095 CMOT April 1989
The use of proxy management can be largely transparent to the
requesting manager, which appears to be exchanging information
directly with the selected device. The only thing that is known to
the manager is that additional "instance" information is required to
select a particular device managed by the proxy. Each proxy may
support many managed devices, using the "instance" information to
multiplex CMIP requests and responses among them. The mapping
between a specific instance and an actual managed device is a local
matter. (The use of the CMIP Object Instance field to select a
particular system to manage by proxy is explained below in section
5.3.2.2.)
A proxy may also serve as an "intermediate manager" in another less
transparent sense. The proxy manager may be requested to calculate
summary statistics on information gathered from many different
managed systems (e.g., the average number of PDUs transmitted or the
distribution of PDUs transmitted over time). The proxy may be
requested to log events transmitted by the managed systems under its
control and to send to the requesting manager only those events of
specific types. When this use of proxy management is made, the
conceptual schema for managed objects known to both the requesting
manager and proxy must include definitions of these aggregate managed
objects (i.e., objects that do not belong to any one managed system).
How the aggregate statistics would be calculated and logging
performed based on information from the different devices managed by
the proxy would be part of the definition of these aggregate managed
objects.
RFC 1085 specifies the use of a minimal (or "stub") directory
service. It specifies how the service name for an OSI application
entity is converted into an "application entity title." The
application entity title is then mapped into a presentation address.
The form of a service name, an application entity title, and a
presentation address can be found in RFC 1085.
The description of management information has two aspects. First, a
structure of management information (SMI) defines the logical
structure of management information and how it is identified and
described. Second, the management information base (MIB), which is
specified using the SMI, defines the actual objects to be managed.
The purpose of this section is to show how CMIP is used in the CMOT
architecture to convey information defined in the Internet MIB.
Warrier & Besaw [Page 18]
RFC 1095 CMOT April 1989
The SMI supplies the model for understanding management information,
as well as templates and ASN.1 macros that can be used for defining
actual management information. The following sections discuss the
ISO SMI, the Internet SMI, and a way of interpreting the Internet SMI
in terms of the ISO SMI so that CMIP can be used to carry management
information defined in terms of the Internet SMI.
The ISO SMI [19] is based on the abstraction of a "managed object"
and the various kinds of relationships objects can be involved in.
The following discussion does not purport to be a complete and
accurate description of the latest ISO SMI work. It is intended to
be a clear presentation of the basic ISO SMI concepts essential for
understanding the CMIP-specific interpretation of the Internet SMI
presented in section 5.3.
Management Information is modeled using object-oriented techniques.
All "things" in the network that are to be managed are represented in
terms of managed objects. A "managed object" is an abstraction (or
logical view) for the purposes of network management of a
"manageable" physical or logical resource of the network. In this
context, "manageable" means that a particular resource can be managed
by using CMIP. Examples of managed objects are protocol entities,
modems, and connections.
Each managed object belongs to a particular object class. An "object
class" represents a collection of managed objects with the same, or
similar, properties. A particular managed object existing in a
particular network is defined as an "object instance" of the object
class to which it belongs. Thus, an object instance represents an
actual realization of an object class (i.e., a managed object of a
particular class bound to specific values). An example of an object
class is "transport connection." In an actual network, there are a
number of managed objects (specific transport connections) that are
instances of this class. In summary, a managed object type, which is
called an "object class," is the collection of all actual and
potential instances of that type.
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.
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.
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.
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
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.
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.
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.
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.
Warrier & Besaw [Page 24]
RFC 1095 CMOT April 1989
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 RFC 1065). 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 RFC 1065). 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
RFC 1065 and used to define the Internet-standard MIB in RFC 1066.
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.
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.
Warrier & Besaw [Page 25]
RFC 1095 CMOT April 1989
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.
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 RFC 1065).
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
Warrier & Besaw [Page 26]
RFC 1095 CMOT April 1989
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
Warrier & Besaw [Page 27]
RFC 1095 CMOT April 1989
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.
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.
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.
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.
Warrier & Besaw [Page 28]
RFC 1095 CMOT April 1989
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).
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.
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.
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.
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
Warrier & Besaw [Page 30]
RFC 1095 CMOT April 1989
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.
Warrier & Besaw [Page 31]
RFC 1095 CMOT April 1989
Part II: Protocol Agreements
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.
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.
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
Warrier & Besaw [Page 33]
RFC 1095 CMOT April 1989
encoding rules used for ASN.1 are specified in [6]. Both definite-
length and indefinite-length encodings are expressly permitted.
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].
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.
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.
Warrier & Besaw [Page 34]
RFC 1095 CMOT April 1989
+---------------------------------+------------------------+------+
| 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.
Warrier & Besaw [Page 35]
RFC 1095 CMOT April 1989
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
Warrier & Besaw [Page 36]
RFC 1095 CMOT April 1989
it supports.
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.
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.
Warrier & Besaw [Page 37]
RFC 1095 CMOT April 1989
+------------------------------+---+---+---+---+---+---+---+---+---+---+
|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
Warrier & Besaw [Page 38]
RFC 1095 CMOT April 1989
with the protocol.
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.
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.
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.
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
Warrier & Besaw [Page 39]
RFC 1095 CMOT April 1989
lost and duplicate requests.
The object class field of all CMIP PDUs shall be limited to the
"globalForm" choice:
ObjectClass ::=
CHOICE {
globalForm [0] IMPLICIT OBJECT IDENTIFIER
}
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.
Warrier & Besaw [Page 40]
RFC 1095 CMOT April 1989
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.
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).
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.
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:
Warrier & Besaw [Page 41]
RFC 1095 CMOT April 1989
FilterItem ::=
CHOICE {
equality [0] AttributeValueAssertion,
greaterOrEqual [2] AttributeValueAssertion,
lessOrEqual [3] AttributeValueAssertion,
present [4] AttributeID
}
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").
Both choices for the CMIP EventTypeId field are allowed:
EventTypeId ::=
CHOICE {
globalId [6] IMPLICIT OBJECT IDENTIFIER,
localId [7] IMPLICIT INTEGER
}
Both choices for the CMIP ActionTypeId field are allowed:
ActionTypeId ::=
CHOICE {
globalId [2] IMPLICIT OBJECT IDENTIFIER,
localId [3] IMPLICIT INTEGER
}
Warrier & Besaw [Page 42]
RFC 1095 CMOT April 1989
The "globalId" form of ActionTypeId is required if scoping is used
(i.e., the value of the scope field is other than "baseObject").
The "eventTime" field of the m-EventReport Invoke PDU and the m-
EventConfirmedReport Invoke PDU must be present.
The "currentTime" field of the following PDUs must be present: the
m-EventReport Confirmed Result PDU, the m-Get Result PDU, the m-Set
Result PDU, the m-Action Confirmed Result PDU, the m-Create Result
PDU, the m-Delete Result PDU, the GetListError Error PDU, and the
SetListError Error PDU.
All CMIP time fields shall use the ASN.1 GeneralizedTime type defined
in [5] with 1 millisecond granularity.
If the system generating the PDU does not have the current time, yet
does have the time since last boot, then GeneralizedTime can be used
to encode this information. The time since last boot will be added
to the base time "0001 Jan 1 00:00:00.00" using the Gregorian
calendar algorithm. (In the Gregorian calendar, all years have 365
days except those divisible by 4 and not by 400, which have 366.) The
use of the year 1 as the base year will prevent any confusion with
current time.
If no meaningful time is available, then the year 0 shall be used in
GeneralizedTime to indicate this fact.
Both the "managedObjectClass" and "managedObjectInstance" fields must
be present in the following CMIP response PDUs: the m-EventReport
Confirmed Result PDU, the m-Get Result PDU, the m-Set Result PDU, the
m-Action Confirmed Result PDU, the m-Create Result PDU, the m-Delete
Result PDU, the GetListError Error PDU, and the SetListError Error
PDU. The "managedObjectInstance" field must be present in the
ProcessingFailure Error PDU. The "managedObjectClass" field must be
present in the NoSuchArgument Error PDU.
The Association Control Service Element (ACSE), which is necessary
Warrier & Besaw [Page 43]
RFC 1095 CMOT April 1989
for establishing and releasing application associations, is defined
in [7] and [8].
The ACSE service description is detailed in ISO 8649 [7]. All of the
defined ACSE services are mandatory:
o A-ASSOCIATE: This confirmed service is used to initiate an
application association between application entities.
o A-RELEASE: This confirmed service is used to release an
application association between application entities without
loss of information.
o A-ABORT: This unconfirmed service causes the abnormal release
of an association with a possible loss of information.
o A-P-ABORT: This provider-initiated service indicates the
abnormal release of an application association by the
underlying presentation service with a possible loss of
information.
Mappings of the ACSE services to presentation services and ACSE APDUs
are shown in Table 6, along with a section reference to ISO 8649 [7].
+-------------+------------+----------------------+-------------+
| ACSE | ISO 8649 | Related | Associated |
| Service | Reference | Presentation Service | APDUs |
+-------------+------------+----------------------+-------------+
| A-ASSOCIATE | 9.1 | P-CONNECT | AARQ, AARE |
| A-RELEASE | 9.2 | P-RELEASE | RLRQ, RLRE |
| A-ABORT | 9.3 | P-U-ABORT | ABRT |
| A-P-ABORT | 9.4 | P-P-ABORT | (none) |
+-------------+------------+----------------------+-------------+
Table 6. Mapping of ACSE Services
ACSE will make use of the following ISO presentation layer services:
P-CONNECT, P-RELEASE, P-U-ABORT, and P-P-ABORT. These presentation
services will be provided by the LPP [13].
Warrier & Besaw [Page 44]
RFC 1095 CMOT April 1989
The Application Context Name takes the form of an OBJECT IDENTIFIER.
The value of this OBJECT IDENTIFIER includes both the version of CMOT
being used for this association and the version number of the highest
version of the Internet-standard MIB supported by the manager or
agent. The application context name has the following generic form:
{ iso(1) org(3) dod(6) internet(1) mgmt(2) mib(n)
cmot(9) cmotVersion(1) version-number(v) }
where n = highest MIB version supported and
v = version of CMOT supported
For the version of CMOT defined in these agreements, "version-number"
has the value of one (1). This version of CMOT implies the versions
of the ISO protocols specified in this memo (see Figure 2).
The following CMIS M-INITIALISE parameters are all mapped onto the
ACSE User Information parameter: Functional Units, User Information,
and Access Control. (See section 7.1.4 for more information on the
CMIS M-INITIALISE parameters.) ACSE User Information is defined in
ISO 8650 as follows:
Association-information ::= SEQUENCE OF EXTERNAL
The ASN.1 defined type EXTERNAL, which is defined in section 35 of
ISO 8824 [5], requires both an OBJECT IDENTIFIER for identification
and an associated ASN.1 encoding.
The OBJECT IDENTIFIER and syntax associated with the ACSE Functional
Units EXTERNAL definition are found in [12]. The OBJECT IDENTIFIER is
defined as { iso(1) standard(0) ips-osi-mips(9596) cmip(2) version(1)
acse(0) functional-units(0) } and the syntax is a BIT STRING.
The EXTERNAL definition for User Information is left unspecified at
this time; it will be defined in a future memo.
If some form of access control is required, a simple unencrypted
Warrier & Besaw [Page 45]
RFC 1095 CMOT April 1989
password can be used. The EXTERNAL for this simple access control
will use the OBJECT IDENTIFIER { cmotAcseAccessControl } (Appendix A)
and the syntax OCTET STRING. A more sophisticated authentication
mechanism will be defined with another EXTERNAL definition in a
future memo.
The values and defaults of parameters to the ACSE primitives that are
given to the presentation service are specified in RFC 1085 [13].
For the Presentation Context Definition List parameter to the P-
CONNECT service [13, p. 10], the value of the Abstract Syntax Name
associated with the Presentation Context Identifier of value one (1)
shall be identical to the OBJECT IDENTIFIER used for the Application
Context Name (section 8.3.1).
The Quality of Service parameter shall have the value of either
"tcp-based" or "udp-based."
The Remote Operations Service Element (ROSE), which provides the
ability to invoke remote operations, is specified in ISO 9072-1 [9]
and 9072-2 [10]. ROSE can only be used once an association has been
established between two application entities. ROSE is used to
support CMISE; it is not intended to be used directly by management
application processes.
The ROSE service definition is detailed in ISO 9072-1 [9]. All of
the defined ROSE services are mandatory:
o RO-INVOKE: This unconfirmed service is used by an invoking
ROSE-user to cause the invocation of an operation to be
performed by an invoked ROSE-user.
o RO-RESULT: This unconfirmed service is used by an invoked
ROSE-user to reply to a previous RO-INVOKE indication in the
case of a successfully performed operation.
o RO-ERROR: This unconfirmed service is used by an invoked
ROSE-user to reply to a previous RO-INVOKE indication in the
case of an unsuccessfully performed operation.
o RO-REJECT-U: This unconfirmed service is used by a ROSE-user
to reject a request (RO-INVOKE indication) of the other
Warrier & Besaw [Page 46]
RFC 1095 CMOT April 1989
ROSE-user if it has detected a problem. It may also be used
by a ROSE-user to (optionally) reject a reply (RO-RESULT
indication, RO-ERROR indication) from the other ROSE-user.
o RO-REJECT-P: This provider-initiated service is used to advise
a ROSE-user of a problem detected by the ROSE-provider.
Mappings of ROSE services to ISO presentation services and ROSE APDUs
are shown in Table 7, along with a section reference to ISO 9072-1
[9].
+-------------+------------+----------------------+-------------+
| ROSE | ISO 9072-1 | Related | Associated |
| Service | Reference | Presentation Service | APDUs |
+-------------+------------+----------------------+-------------+
| RO-INVOKE | 10.1 | P-DATA | ROIV |
| RO-RESULT | 10.2 | P-DATA | RORS |
| RO-ERROR | 10.3 | P-DATA | ROER |
| RO-REJECT-U | 10.4 | P-DATA | RORJ |
| RO-REJECT-P | 10.5 | P-DATA | RORJ |
+-------------+------------+----------------------+-------------+
Table 7. Mapping of ROSE Services
ROSE will only make use of the presentation layer service P-DATA.
This service is provided by the LPP. The following restrictions are
a consequence of the use of the LPP: First, mappings to the Reliable
Transfer Service Element (RTSE) are not possible, since no RTSE is
present. Second, no data token is used with the presentation
services.
The protocol specification for ROSE shall follow ISO 9072-2 [10].
All four APDUs specified in the standard are mandatory. In addition,
the ability to support the correct origination and reception of the
linked-id protocol element is required if the multiple reply
functional unit has been selected (section 7.1.2).
The specification for the lightweight presentation protocol (LPP) is
contained in RFC 1085, "ISO Presentation Services on top of TCP/IP-
based internets" [13]. The services defined in that memo are the
minimal set of ISO presentation services required to support ACSE and
ROSE. The protocol specified to provide these services is a
replacement for the ISO presentation protocol.
Depending on the quality of service indicated in the P-CONNECT
request, the LPP will use either UDP (low quality) or TCP (high
quality) as the underlying transport protocol. UDP provides an
unreliable datagram service, while TCP provides a reliable
connection-oriented transport service.
Practically speaking, there are two ways to discover whether a remote
system supports the LPP over UDP or TCP. The first is to use some
undefined form of directory service. This might be nothing more than
a local table. The second way is simply to attempt to establish an
association with the remote application entity using the desired
quality of service. If the transport for that service is unavailable
on the remote system, then the local presentation-service-provided
will issue a negative P-CONNECT.CONFIRMATION primitive. This will be
interpreted by ACSE as a failure to establish an association with the
desired quality of service.
The following well-known UDP and TCP port numbers are defined:
cmot manager 163/tcp
cmot manager 163/udp
cmot agent 164/tcp
cmot agent 164/udp
When UDP is used, an implementation need not accept a lightweight
presentation PDU whose length exceeds 484. The purpose of this
Warrier & Besaw [Page 48]
RFC 1095 CMOT April 1989
restriction is to ensure that CMIP requests and responses can be
transmitted in a single unfragmented IP datagram.
This RFC is the work of many people. The following members of the
IETF Netman working group and other interested individuals made
important contributions:
Amatzia Ben-Artzi, 3Com
Asheem Chandna, AT&T Bell Laboratories
Ken Chapman, Digital Equipment Corporation
Anthony Chung, Sytek
George Cohn, Ungermann-Bass
Gabriele Cressman, Sun Microsystems
Pranati Kapadia, Hewlett-Packard
Lee LaBarre, The MITRE Corporation (chair)
Dave Mackie, 3Com
Keith McCloghrie, The Wollongong Group
Jim Robertson, 3Com
Milt Roselinsky, CMC
Marshall Rose, The Wollongong Group
John Scott, Data General
Lou Steinberg, IBM