📄 rfc1095.txt
字号:
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.
3.3.1. ACSE
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.
3.3.2. ROSE
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.
3.3.3. CMISE
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.
3.3.3.1. Management Association Services
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.
3.3.3.2. Management Notification Services
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.
3.3.3.3. Management Operation Services
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.
4. The CMOT Architecture
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.
4.1. Management Models
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.
4.1.1. The Organizational Model
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.
4.1.2. The Functional Model
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.
4.1.3. The Information Model
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).
4.2. Protocol Architecture
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.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -