tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 1095


Pages: 67
Top     in Index     Prev     Next
 

Common Management Information Services and Protocol over TCP/IP (CMOT)

Part 1 of 3, p. 1 to 18
None       Next RFC Part

Obsoleted by:    1189


Top       ToC       Page 1 
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

Top      ToC       Page 2 
 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

Top      ToC       Page 3 
 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].

Top      ToC       Page 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

Top      ToC       Page 5 
   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

Top      ToC       Page 6 
   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.

Top      ToC       Page 7 
                        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.

Top      ToC       Page 8 
   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

Top      ToC       Page 9 
   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

Top      ToC       Page 10 
   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

Top      ToC       Page 11 
   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

Top      ToC       Page 12 
   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

Top      ToC       Page 13 
   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

Top      ToC       Page 14 
   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.

Top      ToC       Page 15 
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.

Top      ToC       Page 16 
                   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

Top      ToC       Page 17 
   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.

Top      ToC       Page 18 
   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)

Next RFC Part