RFC 1095
Common Management Information Services and Protocol over TCP/IP (CMOT)
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 1. Status of this Memo ............................................ 3 2. Introduction ................................................... 4 Part I: Concepts and Models ....................................... 7 3. The OSI Management Framework ................................... 7 3.1. Architectural Overview ....................................... 7 3.2. Management Models ............................................ 8 3.2.1. The Organizational Model ................................... 8 3.2.2. The Functional Model ....................................... 8 3.2.3. The Information Model ...................................... 9 3.3. ISO Application Protocols .................................... 9 3.3.1. ACSE ....................................................... 10 3.3.2. ROSE ....................................................... 10 3.3.3. CMISE ...................................................... 10 3.3.3.1. Management Association Services .......................... 11 3.3.3.2. Management Notification Services ......................... 12 3.3.3.3. Management Operation Services ............................ 12 4. The CMOT Architecture .......................................... 13 4.1. Management Models ............................................ 13 4.1.1. The Organizational Model ................................... 13 4.1.2. The Functional Model ....................................... 14 4.1.3. The Information Model ...................................... 14 4.2. Protocol Architecture ........................................ 14 4.2.1 The Lightweight Presentation Layer .......................... 15 4.2.2 The Quality of Transport Service ............................ 16 4.3. Proxy Management ............................................. 17 4.4. Directory Service ............................................ 18 5. Management Information ......................................... 18 5.1. The Structure of Management Information ...................... 19 5.1.1. The ISO SMI ................................................ 19 5.1.1.1. Managed Objects and Attributes ........................... 19 5.1.1.2. Management Information Hierarchies ....................... 20 5.1.1.2.1 The Registration Hierarchy .............................. 20 5.1.1.2.2. The Containment Hierarchy .............................. 20 5.1.1.2.3. The Inheritance Hierarchy .............................. 22 5.1.2. The Internet SMI ........................................... 22 5.2. The Management Information Base .............................. 23
5.3. An Interpretation of the Internet SMI ........................ 24 5.3.1. Object Class and Attributes ................................ 25 5.3.1.1. Object Class ............................................. 25 5.3.1.2. Attribute Identifier ..................................... 26 5.3.2. Management Information Hierarchies ......................... 26 5.3.2.1. The Registration Hierarchy ............................... 26 5.3.2.2. The Containment Hierarchy ................................ 26 5.3.2.3. The Inheritance Hierarchy ................................ 28 5.4. Scoping, Filtering, and Synchronization ...................... 28 5.4.1. Scoping .................................................... 28 5.4.2. Filtering .................................................. 29 5.4.3. Synchronization ............................................ 29 5.4.4. Linked Replies ............................................. 29 5.5. Accessing Tables ............................................. 29 5.5.1. Accessing Whole Tables ..................................... 30 5.5.2. Accessing Table Entries .................................... 30 Part II: Protocol Agreements ...................................... 32 6. CMOT Protocol Overview ......................................... 32 6.1. The CMOT Protocol Suite ...................................... 32 6.2. Conformance Requirements ..................................... 33 6.3. Abstract Syntax Notation ..................................... 33 7. Common Management Information Service Element .................. 34 7.1. CMIS Services ................................................ 34 7.1.1. CMIS Services Overview ..................................... 34 7.1.2. Functional Units ........................................... 34 7.1.3. Functional Unit Groups ..................................... 36 7.1.4. M-INITIALISE Parameters .................................... 37 7.1.4.1. Functional Units ......................................... 37 7.1.4.2. User Information ......................................... 39 7.1.4.3. Access Control ........................................... 39 7.2. Supporting Services .......................................... 39 7.3. CMIP Agreements .............................................. 39 7.3.1. Invoke Identifier .......................................... 39 7.3.2. Object Class ............................................... 40 7.3.3. Object Instance ............................................ 40 7.3.4. Access Control ............................................. 41 7.3.5. Synchronization ............................................ 41 7.3.6. Scope ...................................................... 41 7.3.7. Filter ..................................................... 41 7.3.8. Attribute Identifier ....................................... 42 7.3.9. Event Type Identifier ...................................... 42 7.3.10. Action Type Identifier .................................... 42 7.3.11. Time Fields ............................................... 43 7.3.12. Response PDUs ............................................. 43 7.3.13. Error PDUs ................................................ 43 8. Association Control Service Element ............................ 43 8.1. ACSE Services ................................................ 44 8.2. Supporting Services .......................................... 44
8.3. ACSE Protocol ................................................ 45 8.3.1. Application Context Name ................................... 45 8.3.2. User Information ........................................... 45 8.3.3. Presentation Service Parameters ............................ 46 9. Remote Operations Service Element .............................. 46 9.1. ROSE Services ................................................ 46 9.2. Supporting Services .......................................... 47 9.3. ROSE Protocol ................................................ 47 9.3.1. Operation Class ............................................ 47 9.3.2. Priority ................................................... 48 10. Lightweight Presentation ...................................... 48 10.1. Lightweight Presentation Services ........................... 48 10.2. Supporting Services ......................................... 48 10.3. Lightweight Presentation Protocol ........................... 49 11. Acknowledgements .............................................. 49 12. References .................................................... 49 Appendix A - The CMOT Group ....................................... 52 Appendix B - Management Information Summary ....................... 53 Appendix C - Sample Protocol Exchanges ............................ 60 1. Status of this Memo 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].
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. 2. Introduction 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
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
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.
Part I: Concepts and Models
3. The OSI Management Framework
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.
3.1. Architectural Overview
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.
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. 3.2. Management Models 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. 3.2.1. The Organizational Model 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. 3.2.2. The Functional Model 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
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. 3.2.3. The Information Model 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. 3.3. ISO Application Protocols 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
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. 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
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
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
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
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.
4.2.1. The Lightweight Presentation Layer 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.
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.
4.2.2. The Quality of Transport Service
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
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. 4.3. Proxy Management 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.
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. 4.4. Directory Service 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.
(page 18 continued on part 2)
