GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1095

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

Warrier & Besaw [Page 1] RFC 1095 CMOT April 1989

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

Warrier & Besaw [Page 2] RFC 1095 CMOT April 1989

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].

Warrier & Besaw [Page 3] RFC 1095 CMOT April 1989

 The IAB intends each of these two protocols to receive the attention
 of implementers and experimenters.  The IAB seeks reports of
 experience with these two protocols from system builders and users.
 By this action, the IAB recommends that all IP and TCP
 implementations be network manageable (e.g., implement the Internet
 MIB [3], and that implementations that are network manageable are
 expected to adopt and implement at least one of these two Internet
 Draft Standards.
 Distribution of this memo is unlimited.

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

Warrier & Besaw [Page 4] RFC 1095 CMOT April 1989

 necessary to implement CMIP and accompanying ISO protocols over the
 TCP and UDP transport protocols.  In addition, this memo provides an
 interpretation of RFC 1066 that makes it possible to use CMIP to
 convey management information defined in the Internet-standard MIB.
 There is widespread vendor support for the CMOT approach to network
 management.  This is amply shown by the Netman demonstration of
 prototype CMOT implementations at the Interop '88 TCP/IP
 Interoperability Conference.  The demonstration also showed the
 feasibility and power of the CMIS/CMIP framework for multivendor
 network management.  Now that CMIS/CMIP has been voted a Draft
 International Standard (DIS), many vendors feel that the ISO standard
 has become a stable basis for product development.  The clear need to
 standardize this development has led to the present profile of CMIP.
 It is expected that this profile will not change while the ISO
 standard moves from DIS status to International Standard (IS) status.
 If, however, the standard does change unexpectedly, the Netman
 working group will review such changes for appropriate action.
 Another rationale for the CMOT approach is that it will facilitate
 the early use of ISO network management standards in large
 operational networks.  This will make it possible for the Internet
 community to make valuable recommendations to ISO in the language of
 OSI management based on actual experience with the use and
 implementation of these standards.  There is continuing network
 management standards development work in ISO where such contributions
 would be valuable.
 The CMOT architecture is based on the Open Systems Interconnection
 (OSI) management framework and models developed by ISO.  This memo
 contains a set of protocol agreements for implementing a network
 management system based on this architecture. The protocol agreement
 sections of this memo must be read in conjunction with ISO and
 Internet documents defining specific protocol standards.  Documents
 defining the following ISO standards are required for the
 implementor: Abstract Syntax Notation One (ASN.1) [5, 6], Association
 Control (ACSE) [7, 8], Remote Operations (ROSE) [9, 10], Common
 Management Information Services (CMIS) [11], and Common Management
 Information Protocol (CMIP) [12].  RFC 1085 [13] is required for the
 specification of a lightweight presentation layer protocol used in
 this profile.  In addition, RFC 1065 [2] and RFC 1066 [3] are
 required for a definition of the initial SMI and MIB to be used with
 the CMOT management system.
 This memo is divided into two main parts.  The first part presents
 concepts and models; the second part contains the protocol agreements
 necessary for implementation of the CMOT network management system.
 The first part of the memo is divided into three sections: section 3

Warrier & Besaw [Page 5] RFC 1095 CMOT April 1989

 contains tutorial information on the OSI management framework;
 section 4 defines the basic CMOT approach; and section 5 discusses
 the area of management information and specifies how the abstract
 management information defined in the Internet-standard SMI and MIB
 map into CMIP.  The second part of this memo is divided into sections
 for each of the protocols for which implementors' agreements are
 needed: CMISE, ACSE, ROSE, and the lightweight presentation protocol.
 The protocol profile defined in this part draws on the technical work
 of the OSI Network Management Forum [14] and the Network Management
 Special Interest Group (NMSIG) of the National Institute of Standards
 and Technology (NIST) (formerly the National Bureau of Standards).
 Wherever possible, an attempt has been made to remain consistent with
 the protocol agreements reached by these groups.

Warrier & Besaw [Page 6] RFC 1095 CMOT April 1989

                      Part I: Concepts and Models

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.

Warrier & Besaw [Page 7] RFC 1095 CMOT April 1989

 However, the specification of the management protocol (CMIP) defines
 a peer protocol relationship that makes no assumptions concerning
 which end opens or closes a connection, or the direction of
 management data transfer.  The protocol mechanisms provided are fully
 symmetric between the manager and the agent; CMIS operations can
 originate at either the manager or agent, as far as the protocol is
 concerned.  This allows the possibility of symmetric as well as
 asymmetric relationships between management processes.  Most devices
 will contain management applications that can only assume the agent
 role.  Applications on managing systems, however, may well be able to
 play both roles at the same time.  This makes possible "manager to
 manager" communication and the ability of one manager to manage
 another.

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

Warrier & Besaw [Page 8] RFC 1095 CMOT April 1989

 management provides the facilities to monitor and evaluate the
 performance of the network.  Accounting management makes it possible
 to charge users for network resources used and to limit the use of
 those resources.  Finally, security management is concerned with
 managing access control, authentication, encryption, key management,
 and so on.

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

Warrier & Besaw [Page 9] RFC 1095 CMOT April 1989

 or more "application associations" are established between them.
 Such an association can be viewed as a connection at the level of the
 application layer.  An "application context" defines the set of
 application service elements which may be invoked by the user of an
 application association.  The application context may prescribe one
 or more application service elements.
 Generally, an "application layer protocol" is realized by the use of
 the functionality of a number of application service elements.  This
 functionality is provided by the specification of a set of
 application protocol data units (APDUs) and the procedures governing
 their use.  In general, the operation of an application layer
 protocol may require the combination of APDUs from different
 application service elements.  The application entity makes direct
 use of presentation context identifiers for the specification and
 identification of APDUs.

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.

Warrier & Besaw [Page 14] RFC 1095 CMOT April 1989

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.

Warrier & Besaw [Page 15] RFC 1095 CMOT April 1989

                 Manager                              Agent
         +-----------------------+           +-----------------------+
         |                       |           |                       |
         | +----+ +----+ +-----+ | <-------> | +----+ +----+ +-----+ |
         | |ACSE| |ROSE| |CMISE| |    CMIP   | |ACSE| |ROSE| |CMISE| |
         | +----+ +----+ +-----+ |           | +----+ +----+ +-----+ |
         |                       |           |                       |
         +-----------------------+           +-----------------------+
         |         LPP           |           |         LPP           |
         +-----------------------+           +-----------------------+
         |   TCP    |    UDP     |           |   TCP    |   UDP      |
         +-----------------------+           +-----------------------+
         |         IP            |           |         IP            |
         +-----------------------+           +-----------------------+
         |         Link          |           |         Link          |
         +-----------------------+           +-----------------------+
                    |                                   |
                    |                                   |
                    |                                   |
         =========================================================
                                Network
         =========================================================
                   Figure 1.  The CMOT Protocol Architecture
 It is important to note that the presentation services provided by
 the LPP are "real" (but minimal) ISO presentation services [24].
 This provides a clear migration path to "full ISO" in the future.
 Such a migration would be accomplished by substituting ISO protocols
 for the Internet protocols TCP, UDP, and IP [25], and replacing the
 LPP with ISO presentation and session protocols.  No changes will be
 required in the ISO application layer protocols.  For this reason,
 investments in application development will be well preserved.

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

Warrier & Besaw [Page 16] RFC 1095 CMOT April 1989

 resolution to the network management applications, which are
 ultimately the point where the requirements from the underlying
 service need to be determined.  As such, the CMOT protocol
 architecture provides both services.  The presentation layer service
 allows the application to select either high or low quality service
 for the underlying transport.  Depending on this choice, the LPP will
 use either UDP (low quality) or TCP (high quality) to establish the
 application association and carry the application data.  It is
 important, however, for the application to be aware of the quality of
 service that it is using: low quality means low quality!  The use of
 an unreliable transport like UDP necessarily puts more burden on the
 application.

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.

Warrier & Besaw [Page 17] RFC 1095 CMOT April 1989

 The use of proxy management can be largely transparent to the
 requesting manager, which appears to be exchanging information
 directly with the selected device.  The only thing that is known to
 the manager is that additional "instance" information is required to
 select a particular device managed by the proxy.  Each proxy may
 support many managed devices, using the "instance" information to
 multiplex CMIP requests and responses among them.  The mapping
 between a specific instance and an actual managed device is a local
 matter.  (The use of the CMIP Object Instance field to select a
 particular system to manage by proxy is explained below in section
 5.3.2.2.)
 A proxy may also serve as an "intermediate manager" in another less
 transparent sense.  The proxy manager may be requested to calculate
 summary statistics on information gathered from many different
 managed systems (e.g., the average number of PDUs transmitted or the
 distribution of PDUs transmitted over time).  The proxy may be
 requested to log events transmitted by the managed systems under its
 control and to send to the requesting manager only those events of
 specific types.  When this use of proxy management is made, the
 conceptual schema for managed objects known to both the requesting
 manager and proxy must include definitions of these aggregate managed
 objects (i.e., objects that do not belong to any one managed system).
 How the aggregate statistics would be calculated and logging
 performed based on information from the different devices managed by
 the proxy would be part of the definition of these aggregate managed
 objects.

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.

5. Management Information

 The description of management information has two aspects.  First, a
 structure of management information (SMI) defines the logical
 structure of management information and how it is identified and
 described.  Second, the management information base (MIB), which is
 specified using the SMI, defines the actual objects to be managed.
 The purpose of this section is to show how CMIP is used in the CMOT
 architecture to convey information defined in the Internet MIB.

Warrier & Besaw [Page 18] RFC 1095 CMOT April 1989

5.1. The Structure of Management Information

 The SMI supplies the model for understanding management information,
 as well as templates and ASN.1 macros that can be used for defining
 actual management information.  The following sections discuss the
 ISO SMI, the Internet SMI, and a way of interpreting the Internet SMI
 in terms of the ISO SMI so that CMIP can be used to carry management
 information defined in terms of the Internet SMI.

5.1.1. The ISO SMI

 The ISO SMI [19] is based on the abstraction of a "managed object"
 and the various kinds of relationships objects can be involved in.
 The following discussion does not purport to be a complete and
 accurate description of the latest ISO SMI work.  It is intended to
 be a clear presentation of the basic ISO SMI concepts essential for
 understanding the CMIP-specific interpretation of the Internet SMI
 presented in section 5.3.

5.1.1.1. Managed Objects and Attributes

 Management Information is modeled using object-oriented techniques.
 All "things" in the network that are to be managed are represented in
 terms of managed objects.  A "managed object" is an abstraction (or
 logical view) for the purposes of network management of a
 "manageable" physical or logical resource of the network.  In this
 context, "manageable" means that a particular resource can be managed
 by using CMIP.  Examples of managed objects are protocol entities,
 modems, and connections.
 Each managed object belongs to a particular object class.  An "object
 class" represents a collection of managed objects with the same, or
 similar, properties.  A particular managed object existing in a
 particular network is defined as an "object instance" of the object
 class to which it belongs.  Thus, an object instance represents an
 actual realization of an object class (i.e., a managed object of a
 particular class bound to specific values).  An example of an object
 class is "transport connection." In an actual network, there are a
 number of managed objects (specific transport connections) that are
 instances of this class.  In summary, a managed object type, which is
 called an "object class," is the collection of all actual and
 potential instances of that type.
 Managed objects are fully defined by specifying the "attributes" or
 properties the object has, the CMIS operations that can be performed
 on the object (e.g., M-SET, M-CREATE) and any constraints on those
 operations, specific actions (e.g., self-test) that can be performed
 on the object, events that the object can generate, and information

Warrier & Besaw [Page 19] RFC 1095 CMOT April 1989

 about various relationships the object may be involved in.  All of
 this information relevant to a managed object is typically provided
 by filling in an object template.
 Managed objects contain properties that are referred to as
 attributes.  Attributes are atomic items of information that can only
 be manipulated as a whole.  An example of an attribute is a counter
 providing a specific piece of information, such as the number of
 packets retransmitted.
 Each object class and attribute is assigned a unique identifier (an
 ASN.1 OBJECT IDENTIFIER) for purposes of naming by a registration
 authority.

5.1.1.2. Management Information Hierarchies

 Managed objects participate in relationships with each other.  There
 are two relationships that are of particular importance for
 management information: the containment relationship and the
 inheritance relationship.  These relationships can be used to
 construct hierarchies of managed objects.  In addition, there is
 another hierarchy defined by the registration process for registering
 identifiers for object classes and attributes.

5.1.1.2.1. The Registration Hierarchy

 The registration hierarchy is determined by the ASN.1 registration
 tree [5] for assigning OBJECT IDENTIFIERs.  An OBJECT IDENTIFIER is
 an administratively assigned name composed of a series of integers
 traversing a path from the root of the ASN.1 registration tree to the
 node or leaf to be identified.  For example, the sequence of integers
 { iso(1) standard(0) ips-osi-mips(9596) cmip(2) } (1.0.9596.2) can be
 used to uniquely identify the CMIP standard.  Each node of this tree
 has an associated registration authority that determines how numbers
 in the subtree defined by that node are allocated.  In the context of
 management, these OBJECT IDENTIFIERs are used for identifying object
 classes and attributes.  The registration hierarchy is not based on
 any particular relationship between managed objects or between
 managed objects and their attributes.  It is independent of both the
 inheritance and containment relationships described below.  Its
 purpose is simply to generate universally unique identifiers.

5.1.1.2.2. The Containment Hierarchy

 The containment hierarchy is constructed by applying the relationship
 "is contained in" to objects and attributes.  Objects of one class
 may contain objects of the same or different class.  Objects may also
 contain attributes.  Attributes cannot contain objects or other

Warrier & Besaw [Page 20] RFC 1095 CMOT April 1989

 attributes.  For example, objects of the class "transport entity" may
 contain objects of the class "transport connection"; an object of the
 class "management domain" may contain objects of the class "node." An
 object class that contains another object class is called the
 "superior" object class; an object class that is contained in another
 object class is called the "subordinate" object class.  The
 containment relationships that an object may participate in are part
 of the definition of the object class to which that managed object
 belongs.  All object classes (except the topmost) must have at least
 one possible superior in the containment tree.  The definition of a
 class may permit it to have more than one such superior.  However,
 individual instances of such a class are nevertheless contained in
 only one instance of a possible containing class.
 The containment hierarchy is important because it can be used for
 identifying instances of a managed object.  For example, assume there
 is an object class "domain" that contains an object class "node" that
 contains an object class "transport entity" that contains an object
 class "transport connection." A particular instance of a transport
 connection can be identified by the concatenation of "instance
 information" for each object class in the containment path: {
 domain="organization," node="herakles," transport entity=tp4,
 transport connection=<TSAP-AddressA, TSAP-AddressB> }.
 What constitutes appropriate "instance information" for each object
 class is part of the definition of that object class and is known as
 the "distinguished attribute(s)." A distinguished attribute is
 composed of an OBJECT IDENTIFIER naming the attribute and the value
 of the attribute.  For each object class, the distinguished
 attributes that differentiate instances of that class are
 collectively called the "relative distinguished name." A sequence of
 relative distinguished names (one for each class in the containment
 path) is the "distinguished name" of a managed object.  The example
 given above represents the distinguished name of a transport
 connection.  The containment hierarchy is sometimes referred to as
 the "naming tree", because it is used to "name" a particular instance
 of a managed object.
 The containment relationship also defines an existence dependency
 among its components; an object or attribute can "exist" only if the
 containing object also "exists." Deletion of an object may result in
 deletion of all objects and attributes contained within it.
 Alternately, depending on the definition of the managed object,
 deletion may be refused until all contained managed objects have been
 deleted.

Warrier & Besaw [Page 21] RFC 1095 CMOT April 1989

5.1.1.2.3. The Inheritance Hierarchy

 The inheritance hierarchy is constructed by applying the relationship
 "inherits properties of" to object classes.  An object class may
 inherit properties of another object class; refinement is obtained by
 adding additional properties.  In this relationship, the parent class
 is called the "superclass" and the inheriting class the "subclass."
 For example, the class "layer entity" may be a superclass of "network
 entity," which in turn is a superclass of "X.25 network entity."
 Attributes defined for "network entity" (e.g., the number of packets
 sent) are automatically defined for "X.25 network entity" without
 having to explicitly include them in the definition for the class
 "X.25 network entity." Thus, inheritance serves as a shorthand for
 defining object classes using object-oriented methodology.  Each
 class (except the topmost) has at least one superclass, but may have
 zero, one, or many subclasses.  Subclasses may in turn have further
 subclasses, to any degree.  A special object called "top" is the
 ultimate superclass.  It has no properties of its own.
 The inheritance hierarchy has no relevance to the naming of object
 instances.  It is useful only insofar as it leads to a manageable and
 extensible technique for the definition of object classes.

5.1.2. The Internet SMI

 The Internet SMI [2] is designed to be a protocol-independent SMI
 that can be used with both SNMP and CMIP.  For this reason, it is
 necessary for any management protocol that uses this SMI to show how
 it is to be interpreted in a protocol-specific manner.  This is done
 for CMIP in this memo.
 The Internet SMI indicates both how to identify managed objects and
 how to define them.  The Internet SMI defines a registration subtree
 rooted at { iso(1) org(3) dod(6) internet(1) } for the sake of
 registering OBJECT IDENTIFIERs to be used for uniquely identifying
 managed objects.  The current Internet SMI specifies the format for
 defining objects in terms of an "object type" template and an
 associated OBJECT-TYPE ASN.1 macro.  An object type definition
 contains five fields: a textual name, along with its corresponding
 OBJECT IDENTIFIER; an ASN.1 syntax; a definition of the semantics of
 the object type; an access (read-only, read-write, write-only, or
 not-accessible); and a status (mandatory, optional, or obsolete).
 The current Internet SMI does not provide any mechanism for defining
 actions or events associated with a managed object.
 In describing management information, the current Internet SMI does
 not use the notions of "object class" and "attribute" found in the
 ISO SMI.  Only the concepts of "object type" and "object instance"

Warrier & Besaw [Page 22] RFC 1095 CMOT April 1989

 are used.  The Internet SMI shows how to define object types; it
 leaves the specification of object instances as a protocol-specific
 matter.  The current Internet structure of management information is
 simpler and less rich than the corresponding ISO structure. The ISO
 SMI makes a distinction between simple "attributes," which can be
 viewed as "leaf objects" that are the lowest elements of the
 containment hierarchy, and composite "managed objects" that belong to
 an "object class" and have a structure associated with them (that is,
 can contain attributes).  The Internet SMI does not draw this
 distinction; both simple and composite "objects" are defined as
 "object types." What structure is associated with objects in the
 Internet SMI is defined through the deliberate attempt to structure
 the lower part of the Internet registration tree according to
 containment principles.  (Objects that are considered "attributes" of
 other containing objects are defined directly below them in the
 object registration tree.) This results in a certain lack of
 flexibility, since the registration hierarchy is implicitly used to
 define the containment hierarchy.  This means that the Internet SMI
 does not contain a mechanism for defining containment relationships
 that do not happen to coincide with the registration hierarchy.  In
 interpreting the Internet SMI for use with CMIP, it is necessary to
 overcome this limitation.

5.2. The Management Information Base

 The Management Information Base (MIB) is a "conceptual repository of
 management information." It is an abstract view of all the objects in
 the network that can be managed.  Note that the MIB is conceptual in
 that it does not carry any implications whatsoever about the physical
 storage (main memory, files, databases, etc.) of management
 information.  The SMI provides the guidelines for defining objects
 contained in the MIB.
 The CMOT approach will use the Internet MIB based on the Internet SMI
 described above.  The first version of the Internet MIB, which is the
 product of the IETF MIB working group, is defined in RFC 1066 [3].
 It contains objects divided into eight groups: system, interfaces,
 address translation, IP, ICMP, TCP, UDP, and EGP.  In addition, the
 Internet SMI provides for future versions of the Internet MIB and a
 means for otherwise extending the MIB through the registration of
 managed objects under "private" and "experimental" branches of the
 object registration tree.  Appendix B provides a protocol-specific
 interpretation of the first version of the TCP/IP MIB defined in [3]
 so that it can be used with CMOT.  This interpretation is based on a
 straightforward mapping of the current Internet SMI to the ISO SMI
 (section 5.3).
 The initial version of the Internet MIB concentrates on defining

Warrier & Besaw [Page 23] RFC 1095 CMOT April 1989

 objects associated with various Internet protocols.  It is expected
 that future versions of the Internet MIB and various extensions will
 provide a much richer set of objects to manage, including management
 information about a variety of network devices and systems.  Thus, an
 expanded MIB will allow wide-ranging and powerful management using
 the CMOT approach.

5.3. An Interpretation of the Internet SMI

 In order to use CMIP to convey information defined in terms of the
 Internet SMI, it is necessary to show how object instances are
 specified and to provide the necessary structure for differentiating
 object class and attributes.  These objectives are both met by
 separating the containment hierarchy used for naming objects from the
 registration hierarchy and by imposing an "object class" structure on
 the Internet SMI.  Using the technique of imposing an object class
 structure does not replace or redefine the object definitions in the
 Internet MIB; it merely provides a necessary gloss or commentary on a
 MIB defined in terms of the Internet SMI.  For example, Appendix B
 references the "object type" definitions found in [3], but imposes
 additional structure on them.
 This object class definition derives from a simplified version of the
 OBJECT-CLASS macro defined in the ISO SMI [19].  The more complex
 definition is not needed for present purposes.  (The object class
 definition presented here could be extended in the future to show
 what actions and events are associated with a managed object.) The
 object class definition has the following fields:
 OBJECT CLASS:
 ------------
    A textual name, termed the OBJECT CLASS DESCRIPTOR, for the object
    class, along with its corresponding OBJECT IDENTIFIER.
 Definition:
    A textual description of the object class.
 Subclass Of:
    The OBJECT CLASS DESCRIPTOR of the object class that is the
    superclass of this object class. This field is used for indicating
    the inheritance relationship.
 Superiors:
    A list of OBJECT CLASS DESCRIPTORs of the possible superior object
    classes of this object class. This field is used for indicating
    the containment relationship.

Warrier & Besaw [Page 24] RFC 1095 CMOT April 1989

 Names:
    A list of OBJECT DESCRIPTORs identifying the OBJECT TYPES that are
    the distinguished attributes of this object class. (The OBJECT-
    TYPE macro is defined in RFC 1065). Attributes listed here will
    normally be present in the Attribute field of the object class
    definition.  This field is used for indicating what attributes
    must be present in the relative distinguished name that indicates
    an instance of this object class.
 Attributes:
    A list of OBJECT DESCRIPTORs identifying the OBJECT TYPES that are
    attributes of this object class. (The OBJECT-TYPE macro is defined
    in RFC 1065). This field is used for indicating the attributes
    that are contained in this object class.
    This object class definition satisfies our objectives for
    interpreting the Internet SMI for use by CMIP.  The Attributes
    field shows what attributes are contained in this object class;
    this makes the necessary distinction between object classes and
    attributes required by CMIP.  Instead of referencing an
    "attribute" def inition (as is done in the ISO SMI), the
    Attributes field references the "object type" definition found in
    RFC 1065 and used to define the Internet-standard MIB in RFC 1066.
    The name, syntax, and access information required for attributes
    is contained in the "object type" definition.  Two things are
    required for specifying an instance of a managed object: a
    containment relationship determining a sequence of object classes
    and a means for specifying the distinguished attributes for an
    object class.  The Superiors field makes the containment
    relationship explicit; it is no longer merely a function of the
    registration tree.  The Names field makes it possible to indicate
    the distinguished attributes for an object class required for
    giving instance information.  Thus, the object class definition
    makes it possible to specify an object instance using CMIP.

5.3.1. Object Class and Attributes

 The mapping of management information to the CMIS parameters Managed
 Object Class and Attribute Identifier List now becomes apparent.

5.3.1.1. Object Class

 The CMIS Managed Object Class parameter is the OBJECT IDENTIFIER
 assigned to the particular object class.  For example, the Managed
 Object Class for the object class "ip" (as defined in Appendix B) is
      { mib 4 } = 1.3.6.1.2.1.4.

Warrier & Besaw [Page 25] RFC 1095 CMOT April 1989

5.3.1.2. Attribute Identifier

 The CMIS Attribute Identifier List parameter is a list of Attribute
 Identifiers.  An Attribute Identifier can be either global or local.
 If it is global, then it is the OBJECT IDENTIFIER assigned to the
 attribute (i.e., "object type") that is being indicated.  For
 example, the global Attribute Identifier for the attribute
 "ipForwarding" (as defined in [3]) is
      { ip 1 } = 1.3.6.1.2.1.4.1.
 If the Attribute Identifier is local, it is an integer that is the
 last component in the OBJECT IDENTIFIER identifying the object.  For
 ipForwarding, the local Attribute Identifier is 1.  In the case where
 the local identifier is used, the leading components of the OBJECT
 IDENTIFIER for the attribute must be the OBJECT IDENTIFIER of the
 containing object class.  This is true for the interpreted Internet
 MIB defined in Appendix B, but may not be true generally.  The local
 identifier is intended to be interpreted relative to the Managed
 Object Class field of the CMIP PDU.  When a local Attribute
 Identifier is encountered in a CMIP PDU, the global form of the
 identifier is formed by prepending the OBJECT IDENTIFIER in the
 Managed Object Class field to the local identifier.  This is valid
 only when scoping is not used (i.e., scoping is "baseObject").  If
 scoping is used, then the global form of the Attribute Identifier
 must be used instead of the local form.

5.3.2. Management Information Hierarchies

 The following sections show how the three management information
 hierarchies are to be understood for the interpreted Internet SMI.

5.3.2.1. The Registration Hierarchy

 The registration hierarchy is the global object registration tree
 described in [2].  It is used merely for assigning identifiers for
 object classes and attributes (i.e., "object types" in RFC 1065).

5.3.2.2. The Containment Hierarchy

 As described above, the containment hierarchy is used to specify an
 object instance.  The Names field of the object class definition
 contains the distinguished attributes for the object class.  The
 OBJECT IDENTIFIER naming the "attribute" together with its value is
 called an attribute value assertion.  A set of attribute value
 assertions (one for each distinguished attribute) is the relative
 distinguished name associated with that object class.  The sequence
 of relative distinguished names for each of the object classes in the

Warrier & Besaw [Page 26] RFC 1095 CMOT April 1989

 containment hierarchy to which a managed object belongs is the
 distinguished name of the object.  An object instance is fully
 specified by a distinguished name.
 Let us take a concrete example from Appendix B.  How would we
 represent an instance of an entry in the IP routing table?  We begin
 by examining the object class in question (ipRouteEntry) and use the
 Superiors field to find the superior class in the containment
 hierarchy (ipRoutingTable).  This process continues until we
 construct the following containment path of object classes: system,
 ip, ipRoutingTable, ipRouteEntry.  Now for each of these object
 classes, we inspect the Names field to find the distinguished
 attribute for that object class.  If no Names field is present (as is
 the case for "ip" and "ipRoutingTable"), then no instance information
 is required at that level.  Both "system" and "ipRouteEntry" have
 Name fields to show what information is expected at that level.  With
 this information, we can construct the following distinguished name
 specifying an instance of an IP routing table entry:
                baseManagedObjectInstance {
                   distinguishedName {
                      relativeDistinguishedName {    -- system
                         attributeValueAssertion {
                            attributeType { cmotSystemID }
                            attributeValue "gateway1.acme.com"
                         }
                      },
                      relativeDistinguishedName {    -- ipRouteEntry
                         attributeValueAssertion {
                            attributeType { ipRouteDest }
                            attributeValue 10.0.0.51
                         }
                      }
                   }
                }
 If the system instance information is not present, then it is assumed
 to be the system with which the management association is established
 (i.e., the system receiving the request).
 Note that the object instance tree can contain components of the
 distinguished name that are outside the managed system (node).  This
 enables referencing of objects across management domains (there could
 be an object class "domain") and across a collection of nodes.  In a
 network where several intermediate managers may be involved in a
 request, each intermediate manager can use the "system" portion of

Warrier & Besaw [Page 27] RFC 1095 CMOT April 1989

 the name to determine where to send a request or result.  This
 technique of naming treats each intermediate managing system as a
 proxy manager.  The proxy manager resolves the address of the next
 node in the chain and may use a different protocol to transfer the
 request or result.  Thus, the "system" instance information can be
 used to name devices being managed by proxy.

5.3.2.3. The Inheritance Hierarchy

 The Internet SMI does not use the inheritance relationship. The
 "Subclass Of" field is present in the object class definition to show
 how the inheritance relationship would be represented and to allow
 for future extensibility.  It is not used for any of the object
 classes defined in Appendix B.

5.4. Scoping, Filtering, and Synchronization

 Within some services, CMIS provides additional capabilities that are
 related to the SMI.  These are the scoping, filtering,
 synchronization, and linked-reply facilities.  The presence of these
 facilities are indicated by the Multiple Object Selection Functional
 Unit defined in CMIS [11].
 These facilities provide the manager with the ability to operate on a
 collection of managed objects, rather than a single object.  The
 selection of multiple objects occurs in two phases: scoping and
 filtering.  Scoping is used to identify the managed objects to which
 a filter is to be applied.  Then filtering is used to select a subset
 of managed objects that satisfy certain conditions.  If scoping is
 not used, only the "base" managed object indicated by the CMIS
 Managed Object Class parameter is implied.  An example of the use of
 scoping and filtering for selecting a particular managed object (a
 table entry) is given in one of the sample protocol exchanges found
 in Appendix C.

5.4.1. Scoping

 Scoping is meant to be understood in terms of the containment
 hierarchy.  A position at a certain level of the containment tree is
 defined by the CMIS Managed Object Class parameter.  The CMIS Scope
 parameter is then interpreted relative to this "base" managed object
 (defined by both object class and object instance).  The Scope
 parameter can be used to select the base object alone, all managed
 objects in the entire subtree (of the containment tree) below the
 base object, or all managed objects in the "n"th level (n = 1, 2,
 3,...) below the base object.

Warrier & Besaw [Page 28] RFC 1095 CMOT April 1989

5.4.2. Filtering

 Within the objects selected as a result of the scope parameter, it is
 possible to further refine the selection of managed objects through
 the use of filtering.  Filtering provides the ability to select a
 subset of these objects based on conditions applied to attributes
 (e.g., IP routing table entries with the "ipRouteAge > 100") and
 logical operations (and, or, not).

5.4.3. Synchronization

 When multiple managed objects have been selected using scoping and
 filtering, the question of synchronization across object instances
 (such as multiple IP routing table entries) arises.  The two possible
 choices are "best effort" and "atomic." If "best effort"
 synchronization is selected, the failure to apply an operation (e.g.,
 M-SET) to one instance of an object does not affect the effort to
 apply this operation to other instances of the object.  If "atomic"
 synchronization is selected, then the operation is either performed
 on all object instances selected or none.  The default
 synchronization is best effort.

5.4.4. Linked Replies

 If the reply to a single request for a set of managed objects results
 in more than one managed object being returned, all of these managed
 objects cannot be returned together in a single CMIP response PDU.
 The reason for this is that the structure of the CMIP response PDU
 only has a single field for containing object instance information.
 Since each managed object has its own instance information, each
 managed object must be returned in a separate CMIP PDU.  In such a
 case, the CMIP Linked Reply PDU is used.  The Linked Reply PDU
 provides a means of associating each of the multiple replies with the
 original request that generated them.  Thus, a single CMIP Get
 Request PDU that uses scoping and filtering would result in zero or
 more CMIP Linked Reply PDUs being returned before a final CMIP Get
 Result PDU.
 A linked reply can also be used to segment a CMIP response pertaining
 to a single managed object.  This would only be necessary if UDP is
 being used as the underlying transport and it is not possible to
 return all the information requested about the managed object in a
 single response PDU subject to the size limitations described in
 section 10.2.

5.5. Accessing Tables

 This section explains how to use the interpreted Internet SMI and MIB

Warrier & Besaw [Page 29] RFC 1095 CMOT April 1989

 to access tables.

5.5.1. Accessing Whole Tables

 A whole table is accessed by specifying the object class of the
 table, indicating a scoping level of one, and not providing an
 attribute identifier list. The CMIS standard [11] specifies that if
 the attribute identifier parameter is not present, then all attribute
 identifiers are assumed.  The following CMIS parameters would be used
 to return the entire TCP connection table:
      Object Class: { tcpConnTable }
      Object Instance: "empty" (unless proxy management is used)
      Scope: oneLevel(1)
      Filter: not present
      Attribute Identifier List: not present
 By scoping one level below "tcpConnTable," all managed objects of the
 class "tcpConnEntry" are selected.  (The object class "tcpConnEntry"
 is the only object class one level below the object class
 "tcpConnTable" in the containment hierarchy.) The absence of an
 attribute identifier list signals that all attributes of the managed
 object are to be returned (i.e., all fields of the TCP connection
 table entry).
 In reply to this request, each entry of the table will be returned in
 a separate CMIP PDU (either a Linked Reply PDU or a Get Result PDU).
 Each reply CMIP PDU will specify the Object Class "tcpConnEntry" and
 the appropriate Object Instance information for that entry, as well
 as an Attribute List giving the values of each of the fields of the
 table entry.

5.5.2. Accessing Table Entries

 An entire table entry is accessed by specifying the object class of
 the table entry, providing a distinguished name specifying the
 instance of the table entry, and not providing an attribute
 identifier list. As seen above, the absence of the attribute
 identifier list parameter indicates that all attributes are assumed.
 The absence of a scope parameter indicates that the base managed
 object class is intended.  The following CMIS parameters would be
 used to return the entire IP routing table entry for which the field
 "ipRouteDest" has the value 10.0.0.51:
      Object Class: { ipRouteEntry }
      Object Instance: { ipRouteDest, 10.0.0.51 }
      Scope: not present
      Filter: not present

Warrier & Besaw [Page 30] RFC 1095 CMOT April 1989

      Attribute Identifier List: not present
 The result is returned in a single CMIP Get Result PDU with an
 attribute list consisting of all of the attributes (i.e., fields) of
 the table entry and their corresponding values.
 If the object class field refers to a table entry and no instance
 information is provided to select a particular entry, then a
 "noSuchObjectInstance" CMIP error should be returned.

Warrier & Besaw [Page 31] RFC 1095 CMOT April 1989

                     Part II: Protocol Agreements

6. CMOT Protocol Overview

 This part of the document is a specification of the protocols of the
 CMOT architecture. Contained herein are the agreements required to
 implement interoperable network management systems using these
 protocols.  The protocol suite defined by these implementors'
 agreements will facilitate communication between equipment of
 different vendors, suppliers, and networks.  This will allow the
 emergence of powerful multivendor network management based on ISO
 models and protocols.
 The choice of a set of protocol standards together with further
 agreements needed to implement those standards is commonly referred
 to as a "profile." The selection policy for the CMOT profile is to
 use existing standards from the international standards community
 (ISO and CCITT) and the Internet community.  Existing ISO standards
 and draft standards in the area of OSI network management form the
 basis of this CMOT profile.  Other ISO application layer standards
 (ROSE and ACSE) are used to support the ISO management protocol
 (CMIP).  To ensure interoperability, certain choices and restrictions
 are made here concerning various options and parameters provided by
 these standards.   Internet standards are used to provide the
 underlying network transport.  These agreements provide a precise
 statement of the implementation choices made for implementing ISO
 network management standards in TCP/IP-based internets.
 In addition to the Netman working group, there are at least two other
 bodies actively engaged in defining profiles for interoperable OSI
 network management: the National Institute of Science and Technology
 (NIST) Network Management Special Interest Group (NMSIG) and the OSI
 Network Management Forum.  Both of these groups are similar to the
 Netman working group in that they are each defining profiles for
 using ISO standards for network management.  Both differ in that they
 are specifying the use of underlying ISO protocols, while the Netman
 working group is concerned with using OSI management in TCP/IP
 networks.  In the interest of greater future compatibility, the
 Netman working group has attempted to make the CMOT profile conform
 as closely as possible to the ongoing work of these two bodies.

6.1. The CMOT Protocol Suite

 The following seven protocols compose the CMOT protocol suite: ISO
 ACSE, ISO DIS ROSE, ISO DIS CMIP, the lightweight presentation
 protocol (LPP), UDP, TCP, and IP.  The relation of these protocols to
 each other is briefly summarized in Figure 2.

Warrier & Besaw [Page 32] RFC 1095 CMOT April 1989

               +----------------------------------------------+
               |       Management Application Processes       |
               +----------------------------------------------+
                           +-------------------+
                           |       CMISE       |
                           | ISO DIS 9595/9596 |
                           +-------------------+
               +------------------+       +--------------------+
               |        ACSE      |       |        ROSE        |
               | ISO IS 8649/8650 |       | ISO DIS 9072-1/2   |
               +------------------+       +--------------------+
               +-----------------------------------------------+
               |     Lightweight Presentation Protocol (LPP)   |
               |                   RFC 1085                    |
               +-----------------------------------------------+
               +------------------+       +--------------------+
               |       TCP        |       |        UDP         |
               |     RFC 793      |       |      RFC 768       |
               +------------------+       +--------------------+
               +-----------------------------------------------+
               |                     IP                        |
               |                   RFC 791                     |
               +-----------------------------------------------+
                    Figure 2.  The CMOT Protocol Suite

6.2. Conformance Requirements

 A CMOT-conformant system must implement the following protocols:
 ACSE, ROSE, CMIP, LPP, and IP.  A conformant system must support the
 use of the LPP over either UDP or TCP.  The use of the LPP over both
 UDP and TCP on the same system may be supported.  A conformant system
 need not support all CMIS operations.  A conformant system must,
 however, support at least one of the functional unit groups
 (indicating a set of supported services) defined in section 7.1.3.
 The service and protocol selections are described in greater detail
 in the following sections.

6.3. Abstract Syntax Notation

 The abstract syntax notation for all of the application service
 elements of the CMOT protocol suite is Abstract Syntax Notation One
 (ASN.1) [5].  The LPP is also defined using ASN.1.  The basic

Warrier & Besaw [Page 33] RFC 1095 CMOT April 1989

 encoding rules used for ASN.1 are specified in [6].  Both definite-
 length and indefinite-length encodings are expressly permitted.

7. Common Management Information Service Element

 The Common Management Information Service Element (CMISE) is
 specified in two ISO documents.  The service definition for the
 Common Management Information Service (CMIS) is given in ISO DIS
 9595-2 [11].  The protocol specification for the Common Management
 Information Protocol (CMIP) is found in ISO DIS 9596-2 [12].

7.1. CMIS Services

7.1.1. CMIS Services Overview

 All of the CMIS services listed in Table 1 are allowed with the CMOT
 approach: M-INITIALISE, M-TERMINATE, M-ABORT, M-EVENT-REPORT, M-GET,
 M-SET, M-ACTION, M-CREATE, and M-DELETE.  The specific services
 supported by a system will be determined by the functional unit group
 or groups to which a system belongs.

7.1.2. Functional Units

 The CMIS services supported are designated in terms of functional
 units [11].  Each functional unit corresponds to the invoker or
 performer aspect of a particular service.  (The terms "invoker" and
 "performer" are taken from ROSE and refer to the caller of and
 responder to a remote operation, respectively.) The "stand alone"
 functional units associated with each of the management services are
 given in Table 2 as functional units 0-17.  The number following the
 name of each functional unit in the table is defined by CMIP [12] to
 identify that particular functional unit.  The functional units are
 used by the CMISE-service-user at the time of association
 establishment to indicate which services it is willing to support.

Warrier & Besaw [Page 34] RFC 1095 CMOT April 1989

 +---------------------------------+------------------------+------+
 | Functional Unit                 | Service Primitives     | Mode |
 +---------------------------------+------------------------+------+
 | conf. event report invoker(0)   | M-EVENT-REPORT Req/Conf| C    |
 | conf. event report performer(1) | M-EVENT-REPORT Ind/Rsp | C    |
 | event report invoker(2)         | M-EVENT-REPORT Req     | U    |
 | event report performer(3)       | M-EVENT-REPORT Ind     | U    |
 | confirmed get invoker(4)        | M-GET Req/Conf         | N/A  |
 | confirmed get performer(5)      | M-GET Ind/Rsp          | N/A  |
 | confirmed set invoker(6)        | M-SET Req/Conf         | C    |
 | confirmed set performer(7)      | M-SET Ind/Rsp          | C    |
 | set invoker(8)                  | M-SET Req              | U    |
 | set performer(9)                | M-SET Ind              | U    |
 | confirmed action invoker(10)    | M-ACTION Req/Conf      | C    |
 | confirmed action performer(11)  | M-ACTION Ind/Rsp       | C    |
 | action invoker(12)              | M-ACTION Req           | U    |
 | action performer(13)            | M-ACTION Ind           | U    |
 | confirmed create invoker(14)    | M-CREATE Req/Conf      | N/A  |
 | confirmed create performer(15)  | M-CREATE Ind/Rsp       | N/A  |
 | confirmed delete invoker(16)    | M-DELETE Req/Conf      | N/A  |
 | confirmed delete performer(17)  | M-DELETE Ind/Rsp       | N/A  |
 | multiple reply(18)              | Linked Identification  | N/A  |
 | multiple object selection(19)   | Scope, Filter, Sync.   | N/A  |
 | extended service(20)            | Extended Presentation  | N/A  |
 +---------------------------------+------------------------+------+
  C = confirmed, U = non-confirmed, N/A = not applicable
                        Table 2.  Functional Units
 In addition to the stand alone functional units, there are three
 additional functional units.  If any of these additional functional
 units are selected, then at least one of the stand alone functional
 units must be selected.  The multiple reply functional unit makes
 available the use of the linked identification parameter in the
 selected stand alone functional units.  This makes possible the use
 of linked reply (multiple CMIP PDU responses to a single request).
 The multiple object selection functional unit makes available the use
 of the scope, filter, and synchronization parameters in the selected
 stand alone functional units.  If the multiple object selection
 functional unit is selected, then the multiple reply functional unit
 must also be selected.  The extended services functional unit makes
 available presentation layer services in addition to the P-DATA
 service.  Selecting this functional unit has no effect in the context
 of CMOT, since the lightweight presentation layer provides only
 minimal ISO presentation services.

Warrier & Besaw [Page 35] RFC 1095 CMOT April 1989

7.1.3. Functional Unit Groups

 In order to assist in the reduction of code size and complexity for
 different types of devices, a number of "functional unit groups" have
 been defined.  Each of these groups indicates a set of services
 defined for either a manager or an agent.  The "negotiation"
 concerning which functional unit groups are supported is done by
 means of the Functional Units parameter of the M-INITIALISE service
 (see section 7.1.4.1).  There are five functional unit groups for
 managers: Event Monitor, Monitoring Manager, Simple Manager,
 Controlling Manager, and Full Manager.  Each functional unit group is
 a superset of the preceding group.  There are five functional unit
 groups for agents: Event Sender, Monitored Agent, Simple Agent,
 Controlled Agent, and Full Agent.  Again, each functional unit group
 is a superset of the preceding group.  The operations supported for
 each functional unit group are summarized in Table 3.
 +--------------------+------+-----+-----+-------+------+-----+------+
 |                    |Event | Get | Set |Create/|Action|Mult.|Mult. |
 |Functional Unit     |Report|     |     |Delete |      |Reply|Object|
 |Groups              |      |     |     |       |      |     |Select|
 +--------------------+------+-----+-----+-------+------+-----+------+
 | 1. Event Monitor   | U    | no  | no  | no    | no   | no  | no   |
 | 2. Event Sender    | U    | no  | no  | no    | no   | no  | no   |
 | 3. Monitoring Mgr. | U    | yes | no  | no    | no   | no  | no   |
 | 4. Monitored Agent | U    | yes | no  | no    | no   | no  | no   |
 | 5. Simple Manager  | U    | yes | C   | no    | no   | yes | no*  |
 | 6. Simple Agent    | U    | yes | C   | no    | no   | yes | no*  |
 | 7. Controlling Mgr.| U    | yes | U/C | yes   | no   | yes | yes  |
 | 8. Controlled Agent| U    | yes | U/C | yes   | no   | yes | yes  |
 | 9. Full Manager    | U/C  | yes | U/C | yes   | U/C  | yes | yes  |
 |10. Full Agent      | U/C  | yes | U/C | yes   | U/C  | yes | yes  |
 +--------------------+------+-----+-----+-------+------+-----+------+
  C = confirmed, U = non-confirmed
  * Simple Managers and Agents must support "oneLevel" scoping for all
    and only those cases where it is required to access a whole table
    and may support synchronization other than "best effort"; no support
    for filtering is required.
                     Table 3.  Functional Unit Groups
 A conformant system must support at least one of these functional
 unit groups.  A system may support both a manager group and an agent
 group.  A system only needs to implement the services and service
 primitives required for the groups that it supports.  In addition, a
 system may support services that are not required by any group that

Warrier & Besaw [Page 36] RFC 1095 CMOT April 1989

 it supports.

7.1.4. M-INITIALISE Parameters

 The M-INITIALISE service is provided by the ACSE A-ASSOCIATE service.
 The parameters for the M-INITIALISE service are defined in [11] and
 summarized in Table 4.
               +-------------------+-----------+-----------+
               | Parameter Name    | Req/Ind   | Rsp/Conf  |
               +-------------------+-----------+-----------+
               | Functional Units  | Mandatory | Mandatory |
               | User Information  | Optional  | Optional  |
               | Access Control    | Optional  | Optional  |
               +-------------------+-----------+-----------+
                     Table 4. M-INITIALISE Parameters
 Notice that the further agreement has been made that the Functional
 Units parameter is mandatory at all times.  The M-INITIALISE
 parameters are conveyed as ACSE user information in the ACSE request
 PDU.

7.1.4.1. Functional Units

 The exchange of functional units between the initiating CMISE-
 service-user and the responding CMISE-service-user is required.  This
 allows the CMIS-service-users to inform each other which functional
 units are supported.  CMIP [12] defines a 21-bit BIT STRING to
 communicate which functional units are supported.  A functional unit
 is supported if the corresponding bit in this bit string is one.  The
 correspondence between functional units and functional unit groups is
 given in Table 5.  The left column gives the functional unit
 corresponding to a particular bit position. The numbers along the top
 of the table indicate the functional unit group (the numbers of the
 functional unit groups are given in Table 3).  The various columns
 indicate the value of each bit for a particular functional unit
 group.

Warrier & Besaw [Page 37] RFC 1095 CMOT April 1989

+——————————+—+—+—+—+—+—+—+—+—+—+

Functional Unit 1 2 3 4 5 6 7 8 9 10

+——————————+—+—+—+—+—+—+—+—+—+—+

conf. event report invoker(0) 0 0 0 0 0 0 0 0 0 1
conf. event report perf.(1) 0 0 0 0 0 0 0 0 1 0
event report invoker(2) 0 1 0 1 0 1 0 1 0 1
event report performer(3) 1 0 1 0 1 0 1 0 1 0
confirmed get invoker(4) 0 0 1 0 1 0 1 0 1 0
confirmed get performer(5) 0 0 0 1 0 1 0 1 0 1
confirmed set invoker(6) 0 0 0 0 1 0 1 0 1 0
confirmed set performer(7) 0 0 0 0 0 1 0 1 0 1
set invoker(8) 0 0 0 0 0 0 1 0 1 0
set performer(9) 0 0 0 0 0 0 0 1 0 1
confirmed action invoker(10) 0 0 0 0 0 0 0 0 1 0
confirmed action performer(11) 0 0 0 0 0 0 0 0 0 1
action invoker(12) 0 0 0 0 0 0 0 0 1 0
action performer(13) 0 0 0 0 0 0 0 0 0 1
confirmed create invoker(14) 0 0 0 0 0 0 1 0 1 0
confirmed create performer(15) 0 0 0 0 0 0 0 1 0 1
confirmed delete invoker(16) 0 0 0 0 0 0 1 0 1 0
confirmed delete performer(17) 0 0 0 0 0 0 0 1 0 1
multiple reply(18) 0 0 0 0 1 1 1 1 1 1
multiple object selection(19) 0 0 0 0 0 0 1 1 1 1
extended service(20) 0 0 0 0 0 0 0 0 0 0

+——————————+—+—+—+—+—+—+—+—+—+—+

M A M A M A M A M A

+——————————+—+—+—+—+—+—+—+—+—+—+

      1 = supported, 0 = not supported, M = manager, A = agent
                   Table 5.  Functional Unit Group Values
 The "negotiation" using functional units proceeds as follows.  The
 initiating CMISE-service-user (manager or agent) sends the functional
 units representing the functional unit group to which it belongs.
 The responding CMISE-service-user sends the functional units
 representing the functional unit group to which it belongs.  (If an
 application process belongs to both a manager and an agent functional
 unit group, then both functional unit groups are indicated using the
 same functional unit bit string.) If the functional unit groups
 supported by the two application entities do not allow meaningful
 communication, then either entity may refuse the association.
 Meaningful communication is defined as the ability of the entity to
 invoke or perform at least one CMIS operation supported by the other
 entity (i.e., some "complementary" set of functional units exists).
 After an association has been established, a system must provide the
 proper response for functional units that it has indicated it can
 support and should gracefully refuse other requests in accordance

Warrier & Besaw [Page 38] RFC 1095 CMOT April 1989

 with the protocol.

7.1.4.2. User Information

 The User Information parameter is optional.  No entity is required to
 send this parameter, but all entities are expected to tolerate
 receipt of it.
 One possible use of the User Information parameter is to convey
 information describing MIB extensions supported by the manager or
 agent.  This can be viewed as a further way of refining the
 application context.  The mechanism for doing this is not defined at
 this time.

7.1.4.3. Access Control

 The CMIS M-INITIALISE Access Control parameter is optional.  Access
 control is supported on a per association basis using ACSE.  It is
 recommended (but not required) that the access control parameter be
 used for each A-ASSOCIATE request (via M-INITIALISE).
 Access control is also possible on a per request basis with the CMIS
 Access Control parameter. This parameter might be used to implement
 security similar to the community access rights mechanism provided by
 SNMP [4].  It is expected that the Access Control parameter will be
 used to implement the standard TCP/IP authentication mechanism once
 this has been defined.

7.2. Supporting Services

 The M-INITIALISE, M-TERMINATE, and M-ABORT services assume the use of
 ACSE.  The following ACSE services are required: A-ASSOCIATE, A-
 RELEASE, A-ABORT, and A-P-ABORT.  The rest of the CMIP protocol uses
 the RO-INVOKE, RO-RESULT, RO-ERROR, and RO-REJECT services of ROSE.

7.3. CMIP Agreements

 The following sections contain specific CMIP agreements in addition
 to those specified in the CMIP standard [12].

7.3.1. Invoke Identifier

 It is required that there be a unique invoke identifier (present in
 the ROSE PDU) for successive invocations on the same association.
 The invoke identifier is provided by the invoking CMISE-service-user.
 Invoke identifiers should increase monotonically during the lifetime
 of an association.  Semantically, the invoke identifier is a Counter
 as defined in [2].  Unique identifiers will allow the detection of

Warrier & Besaw [Page 39] RFC 1095 CMOT April 1989

 lost and duplicate requests.

7.3.2. Object Class

 The object class field of all CMIP PDUs shall be limited to the
 "globalForm" choice:
         ObjectClass ::=
              CHOICE {
                   globalForm    [0] IMPLICIT OBJECT IDENTIFIER
              }

7.3.3. Object Instance

 The object instance field of all CMIP PDUs is limited to the
 "distinguishedName" choice:
         ObjectInstance ::=
              CHOICE {
                   distinguishedName  [2] IMPLICIT DistinguishedName
              }
 The definition for DistinguishedName is imported from CCITT X.500 and
 ISO DIS 9594-2 [26]:
 DistinguishedName ::= RDNSequence
 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
 RelativeDistinguishedName ::= SET OF AttributeValueAssertion
 The definition for AttributeValueAssertion is contained in CMIP [12]:
 AttributeValueAssertion ::= SEQUENCE { AttributeId, AttributeValue }
 AttributeId ::=
      CHOICE {
            globalId   [0] IMPLICIT OBJECT IDENTIFIER
            localId    [1] IMPLICIT INTEGER
      }
 AttributeValue ::= ANY DEFINED BY attributeId
 Those attributes to be used as the distinguished attributes of a
 managed object are defined at the time of registration of the object
 class and are identified in the NAMES clause of the OBJECT-CLASS
 macro.

Warrier & Besaw [Page 40] RFC 1095 CMOT April 1989

 When there is no instance information to convey about a managed
 object, then the following "empty" object instance shall be used: The
 "distinguishedName" choice of ObjectInstance shall be an RDNSequence
 consisting of a SEQUENCE of one RelativeDistinguishedName. That
 RelativeDistinguishedName shall be an empty SET of
 AttributeValueAssertions.

7.3.4. Access Control

 The access control parameter is optional.  The receipt of this
 parameter must be tolerated (i.e., gracefully accepted), but a
 receiving entity is free to ignore this information.  The Access
 Control field is defined in [12] as EXTERNAL.  Until a more
 sophisticated access control mechanism is defined, simple
 authentication can be accomplished by using an unencrypted password
 in the access control field.  The definition of this EXTERNAL is the
 same as that for the ACSE Access Control field (section 8.3.2).

7.3.5. Synchronization

 Support for "best effort" synchronization is required.  Atomic
 synchronization may also be supported, but is not required.

7.3.6. Scope

 Scoping is supported if the multiple object selection functional unit
 is selected.  If scoping is supported, all values of the scope field
 shall be supported.

7.3.7. Filter

 Filtering is supported if the multiple object selection functional
 unit is selected.  If filtering is supported, it is not required that
 all features of filtering be supported.  The following are the
 minimal filtering requirements for any system that supports
 filtering.  In the CMIP field CMISFilter, at least two instances of
 the binary operators ("and," "or") must be supported.  Support for
 additional instances of these operators is not required.  Double
 "not" need not be supported.  In FilterItem, the arithmetic
 operations ("equality", "greaterOrEqual," "lessOrEqual") must be
 supported.  The "present" choice of FilterItem must also be
 supported.  It is not required to support string operations (namely,
 the "substrings" choice of the FilterItem type).  Thus, the minimal
 requirements for filtering yield this restricted definition of
 FilterItem:

Warrier & Besaw [Page 41] RFC 1095 CMOT April 1989

            FilterItem ::=
                 CHOICE {
                      equality       [0] AttributeValueAssertion,
                      greaterOrEqual [2] AttributeValueAssertion,
                      lessOrEqual    [3] AttributeValueAssertion,
                      present        [4] AttributeID
                 }

7.3.8. Attribute Identifier

 Both choices for the CMIP AttributeId field are allowed:
            AttributeId ::=
                 CHOICE {
                      globalId  [0] IMPLICIT OBJECT IDENTIFIER,
                      localId   [1] IMPLICIT INTEGER
                 }
 The "globalId" form of AttributeId is required if scoping is used
 (i.e., the value of the scope field is other than "baseObject").

7.3.9. Event Type Identifier

 Both choices for the CMIP EventTypeId field are allowed:
            EventTypeId ::=
                 CHOICE {
                      globalId  [6] IMPLICIT OBJECT IDENTIFIER,
                      localId   [7] IMPLICIT INTEGER
                 }

7.3.10. Action Type Identifier

 Both choices for the CMIP ActionTypeId field are allowed:
            ActionTypeId ::=
                 CHOICE {
                      globalId  [2] IMPLICIT OBJECT IDENTIFIER,
                      localId   [3] IMPLICIT INTEGER
                 }

Warrier & Besaw [Page 42] RFC 1095 CMOT April 1989

 The "globalId" form of ActionTypeId is required if scoping is used
 (i.e., the value of the scope field is other than "baseObject").

7.3.11. Time Fields

 The "eventTime" field of the m-EventReport Invoke PDU and the m-
 EventConfirmedReport Invoke PDU must be present.
 The "currentTime" field of the following PDUs must be present: the
 m-EventReport Confirmed Result PDU, the m-Get Result PDU, the m-Set
 Result PDU, the m-Action Confirmed Result PDU, the m-Create Result
 PDU, the m-Delete Result PDU, the GetListError Error PDU, and the
 SetListError Error PDU.
 All CMIP time fields shall use the ASN.1 GeneralizedTime type defined
 in [5] with 1 millisecond granularity.
 If the system generating the PDU does not have the current time, yet
 does have the time since last boot, then GeneralizedTime can be used
 to encode this information.  The time since last boot will be added
 to the base time "0001 Jan 1 00:00:00.00" using the Gregorian
 calendar algorithm.  (In the Gregorian calendar, all years have 365
 days except those divisible by 4 and not by 400, which have 366.) The
 use of the year 1 as the base year will prevent any confusion with
 current time.
 If no meaningful time is available, then the year 0 shall be used in
 GeneralizedTime to indicate this fact.

7.3.12. Response PDUs

 Both the "managedObjectClass" and "managedObjectInstance" fields must
 be present in the following CMIP response PDUs: the m-EventReport
 Confirmed Result PDU, the m-Get Result PDU, the m-Set Result PDU, the
 m-Action Confirmed Result PDU, the m-Create Result PDU, the m-Delete
 Result PDU, the GetListError Error PDU, and the SetListError Error
 PDU.  The "managedObjectInstance" field must be present in the
 ProcessingFailure Error PDU.  The "managedObjectClass" field must be
 present in the NoSuchArgument Error PDU.

7.3.13. Error PDUs

 The "globalId" form of AttributeId is required for the
 NoSuchAttributeId Error PDU and the InvalidAttributeValue Error PDU.

8. Association Control Service Element

 The Association Control Service Element (ACSE), which is necessary

Warrier & Besaw [Page 43] RFC 1095 CMOT April 1989

 for establishing and releasing application associations, is defined
 in [7] and [8].

8.1. ACSE Services

 The ACSE service description is detailed in ISO 8649 [7].  All of the
 defined ACSE services are mandatory:
     o  A-ASSOCIATE: This confirmed service is used to initiate an
        application association between application entities.
     o  A-RELEASE: This confirmed service is used to release an
        application association between application entities without
        loss of information.
     o  A-ABORT: This unconfirmed service causes the abnormal release
        of an association with a possible loss of information.
     o  A-P-ABORT: This provider-initiated service indicates the
        abnormal release of an application association by the
        underlying presentation service with a possible loss of
        information.
 Mappings of the ACSE services to presentation services and ACSE APDUs
 are shown in Table 6, along with a section reference to ISO 8649 [7].
    +-------------+------------+----------------------+-------------+
    |    ACSE     |  ISO 8649  |        Related       |  Associated |
    |   Service   |  Reference | Presentation Service |    APDUs    |
    +-------------+------------+----------------------+-------------+
    | A-ASSOCIATE |     9.1    |       P-CONNECT      | AARQ, AARE  |
    | A-RELEASE   |     9.2    |       P-RELEASE      | RLRQ, RLRE  |
    | A-ABORT     |     9.3    |       P-U-ABORT      | ABRT        |
    | A-P-ABORT   |     9.4    |       P-P-ABORT      | (none)      |
    +-------------+------------+----------------------+-------------+
                   Table 6.  Mapping of ACSE Services

8.2. Supporting Services

 ACSE will make use of the following ISO presentation layer services:
 P-CONNECT, P-RELEASE, P-U-ABORT, and P-P-ABORT.  These presentation
 services will be provided by the LPP [13].

Warrier & Besaw [Page 44] RFC 1095 CMOT April 1989

8.3. ACSE Protocol

 The ACSE protocol specification is found in ISO 8650 [8]. All five
 ACSE APDUs specified in the standard are mandatory.

8.3.1. Application Context Name

 The Application Context Name takes the form of an OBJECT IDENTIFIER.
 The value of this OBJECT IDENTIFIER includes both the version of CMOT
 being used for this association and the version number of the highest
 version of the Internet-standard MIB supported by the manager or
  agent.  The application context name has the following generic form:
               { iso(1) org(3) dod(6) internet(1) mgmt(2) mib(n)
                 cmot(9) cmotVersion(1) version-number(v) }
               where n = highest MIB version supported and
                     v = version of CMOT supported
 For the version of CMOT defined in these agreements, "version-number"
 has the value of one (1). This version of CMOT implies the versions
 of the ISO protocols specified in this memo (see Figure 2).

8.3.2. User Information

 The following CMIS M-INITIALISE parameters are all mapped onto the
 ACSE User Information parameter: Functional Units, User Information,
 and Access Control.  (See section 7.1.4 for more information on the
 CMIS M-INITIALISE parameters.) ACSE User Information is defined in
 ISO 8650 as follows:
            Association-information ::= SEQUENCE OF EXTERNAL
 The ASN.1 defined type EXTERNAL, which is defined in section 35 of
 ISO 8824 [5], requires both an OBJECT IDENTIFIER for identification
 and an associated ASN.1 encoding.
 The OBJECT IDENTIFIER and syntax associated with the ACSE Functional
 Units EXTERNAL definition are found in [12]. The OBJECT IDENTIFIER is
 defined as { iso(1) standard(0) ips-osi-mips(9596) cmip(2) version(1)
 acse(0) functional-units(0) } and the syntax is a BIT STRING.
 The EXTERNAL definition for User Information is left unspecified at
 this time; it will be defined in a future memo.
 If some form of access control is required, a simple unencrypted

Warrier & Besaw [Page 45] RFC 1095 CMOT April 1989

 password can be used.  The EXTERNAL for this simple access control
 will use the OBJECT IDENTIFIER { cmotAcseAccessControl } (Appendix A)
 and the syntax OCTET STRING. A more sophisticated authentication
 mechanism will be defined with another EXTERNAL definition in a
 future memo.

8.3.3. Presentation Service Parameters

 The values and defaults of parameters to the ACSE primitives that are
 given to the presentation service are specified in RFC 1085 [13].
 For the Presentation Context Definition List parameter to the P-
 CONNECT service [13, p. 10], the value of the Abstract Syntax Name
 associated with the Presentation Context Identifier of value one (1)
 shall be identical to the OBJECT IDENTIFIER used for the Application
 Context Name (section 8.3.1).
 The Quality of Service parameter shall have the value of either
 "tcp-based" or "udp-based."

9. Remote Operations Service Element

 The Remote Operations Service Element (ROSE), which provides the
 ability to invoke remote operations, is specified in ISO 9072-1 [9]
 and 9072-2 [10].  ROSE can only be used once an association has been
 established between two application entities.  ROSE is used to
 support CMISE; it is not intended to be used directly by management
 application processes.

9.1. ROSE Services

 The ROSE service definition is detailed in ISO 9072-1 [9].  All of
 the defined ROSE services are mandatory:
     o  RO-INVOKE: This unconfirmed service is used by an invoking
        ROSE-user to cause the invocation of an operation to be
        performed by an invoked ROSE-user.
     o  RO-RESULT: This unconfirmed service is used by an invoked
        ROSE-user to reply to a previous RO-INVOKE indication in the
        case of a successfully performed operation.
     o  RO-ERROR: This unconfirmed service is used by an invoked
        ROSE-user to reply to a previous RO-INVOKE indication in the
        case of an unsuccessfully performed operation.
     o  RO-REJECT-U: This unconfirmed service is used by a ROSE-user
        to reject a request (RO-INVOKE indication) of the other

Warrier & Besaw [Page 46] RFC 1095 CMOT April 1989

        ROSE-user if it has detected a problem.  It may also be used
        by a ROSE-user to (optionally) reject a reply (RO-RESULT
        indication, RO-ERROR indication) from the other ROSE-user.
     o  RO-REJECT-P: This provider-initiated service is used to advise
        a ROSE-user of a problem detected by the ROSE-provider.
 Mappings of ROSE services to ISO presentation services and ROSE APDUs
 are shown in Table 7, along with a section reference to ISO 9072-1
 [9].
    +-------------+------------+----------------------+-------------+
    |    ROSE     | ISO 9072-1 |        Related       |  Associated |
    |   Service   | Reference  | Presentation Service |    APDUs    |
    +-------------+------------+----------------------+-------------+
    | RO-INVOKE   |    10.1    |        P-DATA        |    ROIV     |
    | RO-RESULT   |    10.2    |        P-DATA        |    RORS     |
    | RO-ERROR    |    10.3    |        P-DATA        |    ROER     |
    | RO-REJECT-U |    10.4    |        P-DATA        |    RORJ     |
    | RO-REJECT-P |    10.5    |        P-DATA        |    RORJ     |
    +-------------+------------+----------------------+-------------+
 Table 7.  Mapping of ROSE Services

9.2. Supporting Services

 ROSE will only make use of the presentation layer service P-DATA.
 This service is provided by the LPP.  The following restrictions are
 a consequence of the use of the LPP: First, mappings to the Reliable
 Transfer Service Element (RTSE) are not possible, since no RTSE is
 present.  Second, no data token is used with the presentation
 services.

9.3. ROSE Protocol

 The protocol specification for ROSE shall follow ISO 9072-2 [10].
 All four APDUs specified in the standard are mandatory.  In addition,
 the ability to support the correct origination and reception of the
 linked-id protocol element is required if the multiple reply
 functional unit has been selected (section 7.1.2).

9.3.1. Operation Class

 Since no turn management is required by ROSE, the Operation Class
 parameter may be ignored.

Warrier & Besaw [Page 47] RFC 1095 CMOT April 1989

9.3.2. Priority

 ROSE will deliver each APDU in a "first in, first out" manner.  Since
 no turn management is required by ROSE, the Priority parameter may be
 ignored.

10. Lightweight Presentation

 The specification for the lightweight presentation protocol (LPP) is
 contained in RFC 1085, "ISO Presentation Services on top of TCP/IP-
 based internets" [13].  The services defined in that memo are the
 minimal set of ISO presentation services required to support ACSE and
 ROSE.  The protocol specified to provide these services is a
 replacement for the ISO presentation protocol.

10.1. Lightweight Presentation Services

 All of the ISO presentation services provided by the LPP are
 mandatory: P-CONNECT, P-RELEASE, P-U-ABORT, P-P-ABORT, and P-DATA.

10.2. Supporting Services

 Depending on the quality of service indicated in the P-CONNECT
 request, the LPP will use either UDP (low quality) or TCP (high
 quality) as the underlying transport protocol.  UDP provides an
 unreliable datagram service, while TCP provides a reliable
 connection-oriented transport service.
 Practically speaking, there are two ways to discover whether a remote
 system supports the LPP over UDP or TCP.  The first is to use some
 undefined form of directory service. This might be nothing more than
 a local table.  The second way is simply to attempt to establish an
 association with the remote application entity using the desired
 quality of service.  If the transport for that service is unavailable
 on the remote system, then the local presentation-service-provided
 will issue a negative P-CONNECT.CONFIRMATION primitive.  This will be
 interpreted by ACSE as a failure to establish an association with the
 desired quality of service.
 The following well-known UDP and TCP port numbers are defined:
           cmot manager     163/tcp
           cmot manager     163/udp
           cmot agent       164/tcp
           cmot agent       164/udp
 When UDP is used, an implementation need not accept a lightweight
 presentation PDU whose length exceeds 484.  The purpose of this

Warrier & Besaw [Page 48] RFC 1095 CMOT April 1989

 restriction is to ensure that CMIP requests and responses can be
 transmitted in a single unfragmented IP datagram.

10.3. Lightweight Presentation Protocol

 No further agreements are needed for the lightweight presentation
 protocol defined in RFC 1085.

11. Acknowledgements

 This RFC is the work of many people.  The following members of the
 IETF Netman working group and other interested individuals made
 important contributions:
           Amatzia Ben-Artzi, 3Com
           Asheem Chandna, AT&T Bell Laboratories
           Ken Chapman, Digital Equipment Corporation
           Anthony Chung, Sytek
           George Cohn, Ungermann-Bass
           Gabriele Cressman, Sun Microsystems
           Pranati Kapadia, Hewlett-Packard
           Lee LaBarre, The MITRE Corporation (chair)
           Dave Mackie, 3Com
           Keith McCloghrie, The Wollongong Group
           Jim Robertson, 3Com
           Milt Roselinsky, CMC
           Marshall Rose, The Wollongong Group
           John Scott, Data General
           Lou Steinberg, IBM

12. References

   [1]  Cerf, V., "IAB Recommendations for the Development of Internet
        Network Management Standards", RFC 1052, April 1988.
   [2]  Rose, M., and K. McCloghrie, "Structure and Identification of
        Management Information for TCP/IP-based internets", RFC 1065,
        August 1988.
   [3]  McCloghrie, K., and M. Rose, "Management Information Base for
        Network Management of TCP/IP-based internets", RFC 1066,
        August 1988.
   [4]  Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A Simple
        Network Management Protocol (SNMP)", RFC 1098, (Obsoletes
        RFC 1067), April 1989.
   [5]  ISO 8824: "Information processing systems - Open Systems

Warrier & Besaw [Page 49] RFC 1095 CMOT April 1989

        Interconnection, Specification of Abstract Syntax Notation One
        (ASN.1)", Geneva, March 1988.
   [6]  ISO 8825: "Information processing systems - Open Systems
        Interconnection, Specification of Basic Encoding Rules for
        Abstract Notation One (ASN.1)", Geneva, March 1988.
   [7]  ISO 8649: "Information processing systems - Open Systems
        Interconnection, Service Definition for Association Control
        Service Element".
   [8]  ISO 8650: "Information processing systems - Open Systems
        Interconnection, Protocol Specification for Association
        Control Service Element".
   [9]  CCITT Recommendation X.219, Working Document for ISO 9072-1:
        "Information processing systems - Text Communication, Remote
        Operations: Model, Notation and Service Definition",
        Gloucester, November 1987.
   [10]  CCITT Recommendation X.229, Working Document for ISO 9072-2:
         "Information processing systems - Text Communication, Remote
         Operations: Protocol Specification", Gloucester,
         November 1987.
   [11]  ISO DIS 9595-2: "Information processing systems - Open
         Systems Interconnection, Management Information Service
         Definition - Part 2: Common Management Information
         Service", 22 December 1988.
   [12]  ISO DIS 9596-2: "Information Processing Systems - Open
         Systems Interconnection, Management Information Protocol
         Specification - Part 2: Common Management Information
         Protocol", 22 December 1988.
   [13]  Rose, M., "ISO Presentation Services on top of TCP/IP-based
         internets", RFC 1085, December 1988.
   [14]  OSI Network Management Forum, "Forum Interoperable Interface
         Protocols", September 1988.
   [15]  ISO DIS 7498-4: "Information processing systems - Open
         Systems Interconnection, Basic Reference Model - Part 4:
         OSI Management Framework".
   [16]  ISO/IEC JTC1/SC21/WG4 N571: "Information processing systems -
         Open Systems Interconnection, Systems Management: Overview",
         London, July 1988.

Warrier & Besaw [Page 50] RFC 1095 CMOT April 1989

   [17]  Klerer, S. Mark, "The OSI Management Architecture: An
         Overview", IEEE Network Magazine, March 1988.
   [18]  Ben-Artzi, A., "Network Management for TCP/IP Networks: An
         Overview", Internet Engineering Task Force working note,
         April 1988.
   [19]  ISO/IEC JTC1/SC21/WG4 N3324: "Information processing
         systems - Open Systems Interconnection, Management
         Information Services - Structure of Management
         Information - Part I: Management Information Model",
         Sydney, December 1988.
   [20]  Postel, J., "User Datagram Protocol", RFC 768, August 1980.
   [21]  Postel, J., "Transmission Control Protocol", RFC 793,
         September 1981.
   [22]  ISO DP 9534: "Information processing systems - Open Systems
         Interconnection, Application Layer Structure", 10 March 1987.
   [23]  Rose, M., "ISO Transport Services on top of the TCP",
         RFC 1006, May 1987.
   [24]  ISO 8822: "Information processing systems - Open Systems
         Interconnection, Connection Oriented Presentation Service
         Definition", June 1987.
   [25]  Postel, J., "Internet Protocol", RFC 791, September 1981.
   [26]  CCITT Draft Recommendation X.500, ISO DIS 9594/1-8: "The
         Directory", Geneva, March 1988.

Warrier & Besaw [Page 51] RFC 1095 CMOT April 1989

Appendix A - The CMOT Group

 CMOT DEFINITIONS ::= BEGIN
 IMPORTS OBJECT-TYPE FROM RFC1065-SMI;
 IMPORTS mib FROM RFC1066-MIB;
   cmot  OBJECT IDENTIFIER ::= { mib 9 }
  1. - The following assignments are made for the purpose of
  2. - identification within CMOT and do not refer to MIB objects.
   cmotVersion              OBJECT IDENTIFIER ::= { cmot 1 }
   cmotAcseInfo             OBJECT IDENTIFIER ::= { cmot 2 }
   cmotAcseAccessControl    OBJECT IDENTIFIER ::= { cmotAcseInfo 1 }
  1. - The following definition is made for use in referencing a
  2. - managed system (for the purpose of proxy management) in the
  3. - CMIP Object Instance field. It does not represent a MIB
  4. - object.
   cmotSystemID OBJECT-TYPE
           SYNTAX  CmotSystemID
           ACCESS  not-accessible
           STATUS  optional
           ::= { cmot 3 }
   CmotSystemID ::= CHOICE {
           arbitrary     [0] IMPLICIT OCTET STRING,
           proxyIndex    [1] IMPLICIT INTEGER,
           inetAddr      [2] IMPLICIT IpAddress,
           domainName    [3] IMPLICIT OCTET STRING,
           mac802Addr    [4] IMPLICIT OCTET STRING,
           x121Addr      [5] IMPLICIT OCTET STRING,
           nsap          [6] IMPLICIT OCTET STRING,
           netbiosName   [7] IMPLICIT OCTET STRING,
           snaName       [8] IMPLICIT OCTET STRING,
           adminId       [9] IMPLICIT OBJECT IDENTIFIER
   }
  1. - All addresses should be conveyed in network-byte order.
 END

Warrier & Besaw [Page 52] RFC 1095 CMOT April 1989

Appendix B - Management Information Summary

 RFC1066-MIB-INTERPRETATION
        { iso org(3) dod(6) internet(1) mgmt(2) 1 }
            DEFINITIONS ::= BEGIN
            IMPORTS mgmt, OBJECT-TYPE FROM RFC1065-SMI;
              mib        OBJECT IDENTIFIER ::= { mgmt 1 }
              system     OBJECT IDENTIFIER ::= { mib 1 }
              interfaces OBJECT IDENTIFIER ::= { mib 2 }
              at         OBJECT IDENTIFIER ::= { mib 3 }
              ip         OBJECT IDENTIFIER ::= { mib 4 }
              icmp       OBJECT IDENTIFIER ::= { mib 5 }
              tcp        OBJECT IDENTIFIER ::= { mib 6 }
              udp        OBJECT IDENTIFIER ::= { mib 7 }
              egp        OBJECT IDENTIFIER ::= { mib 8 }
  1. - definition of object class
       OBJECT-CLASS MACRO  ::=
       BEGIN
         TYPE NOTATION  ::= SubClassOf Superiors Names Attributes
         VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER)
         SubClassOf     ::= "SUBCLASS OF" value(OBJECT-CLASS)
                                          | empty
         Superiors      ::= "SUPERIORS" "{" SuperiorList "}"
                                          | empty
         Names          ::= "NAMES" "{" AttributeList "}"
                                          | empty
         Attributes     ::= "CONTAINS" "{" AttributeList "}"
                                          | empty
         SuperiorList   ::= Superior | Superior "," SuperiorList
         Superior       ::= value(OBJECT-CLASS)
         AttributeList  ::= Attribute | Attribute "," AttributeList
         Attribute      ::= value(OBJECT-TYPE)
       END
  1. - the System group

Warrier & Besaw [Page 53] RFC 1095 CMOT April 1989

       system OBJECT-CLASS
               NAMES  { cmotSystemID }   -- Appendix A
               CONTAINS  {
                       sysDescr,
                       sysObjectID,
                       sysUpTime
               }
               ::= { mib 1 }
  1. - the Interfaces group
       interfaces OBJECT-CLASS
               SUPERIORS  { system }
               CONTAINS  { ifNumber }
               ::= { mib 2 }
       ifTable OBJECT-CLASS
               SUPERIORS  { interfaces }
               ::= { interfaces 2 }
       ifEntry OBJECT-CLASS
               SUPERIORS  { ifTable }
               NAMES { ifIndex }
               CONTAINS  {
                       ifIndex,
                       ifDescr,
                       ifType,
                       ifMtu,
                       ifSpeed,
                       ifPhysAddress,
                       ifAdminStatus,
                       ifOperStatus,
                       ifLastChange,
                       ifInOctets,
                       ifInUcastPkts,
                       ifInNUcastPkts,
                       ifInDiscards,
                       ifInErrors,
                       ifInUnknownProtos,
                       ifOutOctets,
                       ifOutUcastPkts,
                       ifOutNUcastPkts,
                       ifOutDiscards,
                       ifOutErrors,
                       ifOutQLen
               }
               ::= { ifTable 1 }

Warrier & Besaw [Page 54] RFC 1095 CMOT April 1989

  1. - the Address Translation group
       at OBJECT-CLASS
               SUPERIORS  { system }
               ::= { mib 3 }
       atTable OBJECT-CLASS
               SUPERIORS  { at }
               ::= { at 1 }
       atEntry OBJECT-CLASS
               SUPERIORS  { atTable }
               NAMES  {
                       atIfIndex,
                       atNetAddress
               }
               CONTAINS  {
                       atIfIndex,
                       atPhysAddress,
                       atNetAddress
               }
               ::= { atTable 1 }
  1. - the IP group
       ip OBJECT-CLASS
               SUPERIORS  { system }
               CONTAINS  {
                       ipForwarding,
                       ipDefaultTTL,
                       ipInReceives,
                       ipInHdrErrors,
                       ipInAddrErrors,
                       ipForwDatagrams,
                       ipInUnknownProtos,
                       ipInDiscards,
                       ipInDelivers,
                       ipOutRequests,
                       ipOutDiscards,
                       ipOutNoRoutes,
                       ipReasmTimeout,
                       ipReasmReqds,
                       ipReasmOKs,
                       ipReasmFails,
                       ipFragOKs,
                       ipFragFails,
                       ipFragCreates
               }

Warrier & Besaw [Page 55] RFC 1095 CMOT April 1989

               ::= { mib 4 }
  1. - the IP Interface table
       ipAddrTable OBJECT-CLASS
               SUPERIORS  { ip }
               ::= { ip 20 }
       ipAddrEntry OBJECT-CLASS
               SUPERIORS  { ipAddrTable }
               NAMES  { ipAdEntAddr }
               CONTAINS  {
                       ipAdEntAddr,
                       ipAdEntIfIndex,
                       ipAdEntNetMask,
                       ipAdEntBcastAddr
               }
               ::= { ipAddrTable 1 }
  1. - the IP Routing table
       ipRoutingTable OBJECT-CLASS
               SUPERIORS  { ip }
               ::= { ip 21 }
       ipRouteEntry OBJECT-CLASS
               SUPERIORS  { ipRoutingTable }
               NAMES  { ipRouteDest }
               CONTAINS  {
                       ipRouteDest,
                       ipRouteIfIndex,
                       ipRouteMetric1,
                       ipRouteMetric2,
                       ipRouteMetric3,
                       ipRouteMetric4,
                       ipRouteNextHop,
                       ipRouteType,
                       ipRouteProto,
                       ipRouteAge
               }
               ::= { ipRoutingTable 1 }
  1. - the ICMP group
       icmp OBJECT-CLASS
               SUPERIORS  { system }
               CONTAINS  {
                       icmpInMsgs,

Warrier & Besaw [Page 56] RFC 1095 CMOT April 1989

                       icmpInErrors,
                       icmpInDestUnreachs,
                       icmpInTimeExcds,
                       icmpInParmProbs,
                       icmpInSrcQuenchs,
                       icmpInRedirects,
                       icmpInEchos,
                       icmpInEchoReps,
                       icmpInTimestamps,
                       icmpInTimestampReps,
                       icmpInAddrMasks,
                       icmpInAddrMaskReps,
                       icmpOutMsgs,
                       icmpOutErrors,
                       icmpOutDestUnreachs,
                       icmpOutTimeExcds,
                       icmpOutParmProbs,
                       icmpOutSrcQuenchs,
                       icmpOutRedirects,
                       icmpOutEchos,
                       icmpOutEchoReps,
                       icmpOutTimestamps,
                       icmpOutTimestampReps,
                       icmpOutAddrMasks,
                       icmpOutAddrMaskReps
               }
               ::= { mib 5 }
  1. - the TCP group
       tcp OBJECT-CLASS
               SUPERIORS  { system }
               CONTAINS  {
                       tcpRtoAlgorithm,
                       tcpRtoMin,
                       tcpRtoMax,
                       tcpMaxConn,
                       tcpActiveOpens,
                       tcpPassiveOpens,
                       tcpAttemptFails,
                       tcpEstabResets,
                       tcpCurrEstab,
                       tcpInSegs,
                       tcpOutSegs,
                       tcpRetransSegs
               }
               ::= { mib 6 }

Warrier & Besaw [Page 57] RFC 1095 CMOT April 1989

  1. - the TCP connections table
       tcpConnTable OBJECT-CLASS
               SUPERIORS  { tcp }
               ::= { tcp 13 }
       tcpConnEntry OBJECT-CLASS
               SUPERIORS  { tcpConnTable }
               NAMES  {
                       tcpConnLocalAddress,
                       tcpConnLocalPort,
                       tcpConnRemAddress,
                       tcpConnRemPort
               }
               CONTAINS  {
                       tcpConnState,
                       tcpConnLocalAddress,
                       tcpConnLocalPort,
                       tcpConnRemAddress,
                       tcpConnRemPort
               }
               ::= { tcpConnTable 1 }
  1. - the UDP group
      udp OBJECT-CLASS
               SUPERIORS  { system }
               CONTAINS  {
                       udpInDatagrams,
                       udpNoPorts,
                       udpInErrors,
                       udpOutDatagrams
               }
               ::= { mib 7 }
  1. - the EGP group
        egp OBJECT-CLASS
               SUPERIORS  { system }
               CONTAINS  {
                       egpInMsgs,
                       egpInErrors,
                       egpOutMsgs,
                       egpOutErrors
               }
               ::= { mib 8 }

Warrier & Besaw [Page 58] RFC 1095 CMOT April 1989

  1. - the EGP Neighbor table
        egpNeighTable OBJECT-CLASS
               SUPERIORS  { egp }
               ::= { egp 5 }
       egpNeighEntry OBJECT-CLASS
               SUPERIORS  { egpNeighTable }
               NAMES  { egpNeighAddr }
               CONTAINS  {
                       egpNeighState,
                       egpNeighAddr
               }
               ::= { egpNeighTable 1 }
       END

Warrier & Besaw [Page 59] RFC 1095 CMOT April 1989

Appendix C - Sample Protocol Exchanges

 The following are sample protocol exchanges between a manager and an
 agent.  The manager establishes an association with the agent,
 requests the number of IP address and header errors, requests the
 type of route corresponding to the destination address 10.0.0.51,
 requests the TCP connection with the well-known port for FTP, and
 then releases the association.  All of these samples show the
 lightweight presentation protocol being used over TCP.
  1. -
  2. - the manager sends an ACSE association request carried in a
  3. - presentation connect request PDU
  4. -
 {
    connectRequest {                             -- LPP
       version version-1,
       reference {
          callingSSUserReference "sri-nic.arpa",
          commonReference "880821222531Z"
       },
       asn 1.3.6.1.2.1.9.1.1,
       user-data {                               -- ACSE
          protocol-version version1,
          application-context-name 1.3.6.1.2.1.9.1.1,
          user-information {
             functionalUnits {
                direct-reference 1.0.9596.2.1.0.0,
                encoding {
                   single-ASN1-type '010110101010101010110B'
                                                       -- Full Manager
                }
             }
          }
       }
    }
 }
  1. -
  2. - the agent sends an ACSE association response carried in a
  3. - presentation connect response PDU
  4. -
 {
    connectResponse {                           -- LPP
       user-data {

Warrier & Besaw [Page 60] RFC 1095 CMOT April 1989

          user-information {                    -- ACSE
             functionalUnits {
                direct-reference 1.0.9596.2.1.0.0,
                encoding {
                   single-ASN1-type '101001010101010101110B'
                                                         -- Full Agent
                }
             }
          }
       }
    }
 }
  1. -
  2. - the manager sends a get request to read the values of
  3. - ipInHdrErrors and ipInAddrErrors
  4. -
 {
    userData {                                   -- LPP
       ro-Invoke {                               -- ROSE
          invokeID 10,
          operation-value m-Get(3),
          argument {                             -- CMIP
             baseManagedObjectClass {
                globalForm ip { 1.3.6.1.2.1.4 }
             },
             baseManagedObjectInstance {
                distinguishedName {
                   relativeDistinguishedName {}
                }
             },
             attributeIdList {
                attributeId {
                   localID 4                     -- ipInHdrErrors
                },
                attributeId {
                   localID 5                     -- ipInAddrErrors
                }
             }
          }
       }
    }
 }

Warrier & Besaw [Page 61] RFC 1095 CMOT April 1989

  1. -
  2. - the agent replies with a get response indicating that
  3. - ipInHdrErrors = 0 and ipInAddrErrors = 2
  4. -
 {
    userData {                                   -- LPP
       ro-Result {                               -- ROSE
          invokeID 10,
          {
             operation-value m-Get(3),
             argument {                          -- CMIP
                baseManagedObjectClass {
                   globalForm ip { 1.3.6.1.2.1.4 }
                },
                baseManagedObjectInstance {
                   distinguishedName {
                      relativeDistinguishedName {}
                   }
                },
                currentTime "19880821222541.300000Z",
                attributeList {
                   attribute {
                      attributeId {
                         localID 4               -- ipInHdrErrors
                      },
                      attributeValue 0
                   },
                   attribute {
                      attributeId {
                         localID 5               -- ipInAddrErrors
                      },
                      attributeValue 2
                   }
                }
             }
          }
       }
    }
 }
  1. -
  2. - the manager sends a get request to discover the ipRouteType for
  3. - the IP routing entry with ipRouteDest = 10.0.0.51
  4. -

Warrier & Besaw [Page 62] RFC 1095 CMOT April 1989

 {
    userData {                                   -- LPP
       ro-Invoke {                               -- ROSE
          invokeID 11,
          operation-value m-Get (3),
          argument {                             -- CMIP
             baseManagedObjectClass {
                globalForm ipRouteEntry { 1.3.6.1.2.1.4.21.1 }
             },
             baseManagedObjectInstance {
                distinguishedName {
                   relativeDistinguishedName {
                      attributeValueAssertion {
                         attributeType ipRouteDest
                                      { 1.3.6.1.2.1.4.21.1.1 },
                         attributeValue 10.0.0.51
                      }
                   }
                }
             },
             attributeIdList {
                attributeId {
                   localID 8                     -- ipRouteType
                }
             }
          }
       }
    }
 }
  1. -
  2. - the agent replies with a get response indicating the appropriate
  3. - route type
  4. -
 {
    userData {                                   -- LPP
       ro-Result {                               -- ROSE
          invokeID 11,
          {
             operation-value m-Get(3),
             argument {                          -- CMIP
                baseManagedObjectClass {
                   globalForm ipRouteEntry { 1.3.6.1.2.1.4.21.1 }
                },
                baseManagedObjectInstance {
                   distinguishedName {

Warrier & Besaw [Page 63] RFC 1095 CMOT April 1989

                      relativeDistinguishedName {
                         attributeValueAssertion {
                            attributeType ipRouteDest
                                         { 1.3.6.1.2.1.4.21.1.1 },
                            attributeValue 10.0.0.51
                         }
                      }
                   }
                },
                currentTime "19880821222613.780000Z",
                attributeList {
                   attribute {
                      attributeId {
                         localID 8               -- ipRouteType
                      },
                      attributeValue "direct"
                   }
                }
             }
          }
       }
    }
 }
  1. -
  2. - the manager sends a get request to read the TCP connection with
  3. - the well-known port for FTP.
  4. -
 {
    userData {                                   -- LPP
       ro-Invoke {                               -- ROSE
          invokeID 12,
          operation-value m-Get(3),
          argument {                             -- CMIP
             baseManagedObjectClass {
                globalForm tcpConnTable { 1.3.6.1.2.1.6.13 }
             },
             baseManagedObjectInstance {
                distinguishedName {
                   relativeDistinguishedName { }
                }
             },
             scope oneLevel(1),
             filter {
                item {

Warrier & Besaw [Page 64] RFC 1095 CMOT April 1989

                   equality {
                      attributeType tcpConnLocalPort
                            { 1.3.6.1.2.1.6.13.1.3 }
                      attributeValue 21           -- ftp
                   }
                }
             }
             attributeIdList { } -- an empty list means all attributes
          }
       }
    }
 }
  1. -
  2. - the agent replies with a get response providing the desired TCP
  3. - connection information. If more than one TCP connection had
  4. - satisfied the filter condition, a series of one or more linked
  5. - reply PDUs would have been returned before the final get response.
  6. -
 {
    userData {                                   -- LPP
       ro-Result {                               -- ROSE
          invokeID 12,
          {
             operation-value m-Get(3),
             argument {                          -- CMIP
                baseManagedObjectClass {
                   globalForm tcpConnEntry { 1.3.6.1.2.1.6.13.1 }
                },
                baseManagedObjectInstance {
                   distinguishedName {
                      relativeDistinguishedName {
                         attributeValueAssertion {
                            attributeType  { tcpConnLocalAddress },
                            attributeValue 128.10.0.34
                         },
                         attributeValueAssertion {
                            attributeType  { tcpConnLocalPort },
                            attributeValue 21
                         },
                         attributeValueAssertion {
                            attributeType  { tcpConnRemAddress },
                            attributeValue 0.0.0.0
                         },
                         attributeValueAssertion {
                            attributeType  { tcpConnRemPort },

Warrier & Besaw [Page 65] RFC 1095 CMOT April 1989

                            attributeValue 0
                         },
                      }
                   }
                },
                currentTime "19880821222541.300000Z",
                attributeList {
                   attribute {
                      attributeId {
                         localId 1              -- tcpConnState
                      },
                      attributeValue LISTEN
                   },
                   attribute {
                      attributeId {
                         localId 2              -- tcpConnLocalAddress
                      },
                      attributeValue 128.10.0.34
                   },
                   attribute {
                      attributeId {
                         localId 3              -- tcpConnLocalPort
                      },
                      attributeValue 21
                   },
                   attribute {
                      attributeId {
                         localId 4              -- tcpConnRemAddress
                      },
                      attributeValue 0.0.0.0
                   },
                   attribute {
                      attributeId {
                         localId 5              -- tcpConnRemPort
                      },
                      attributeValue 0
                   }
                }
             }
          }
       }
    }
 }

Warrier & Besaw [Page 66] RFC 1095 CMOT April 1989

  1. -
  2. - the manager sends a presentation release request
  3. -
 {
    releaseRequest {                             -- LPP
       user-data {                               -- ACSE
          reason normal
       }
    }
 }
  1. -
  2. - the agent sends a presentation release response
  3. -
 {
    releaseResponse {                            -- LPP
       user-data {                               -- ACSE
          reason normal
       }
    }
 }

Authors' Addresses

 Unnikrishnan S. Warrier
 Unisys Corporation
 2400 Colorado  MS #42-13
 Santa Monica, CA 90406
 Phone: (213) 453-5196
 Email: unni@cs.ucla.edu
 Larry Besaw
 Hewlett-Packard
 3404 East Harmony Road
 Fort Collins, CO 80525
 Phone: (303) 229-6022
 Email: lmb%hpcndaw@hplabs.hp.com

Warrier & Besaw [Page 67]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1095.txt · Last modified: 1989/04/18 00:16 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki