diff options
Diffstat (limited to 'doc/rfc/rfc1095.txt')
| -rw-r--r-- | doc/rfc/rfc1095.txt | 3755 |
1 files changed, 3755 insertions, 0 deletions
diff --git a/doc/rfc/rfc1095.txt b/doc/rfc/rfc1095.txt new file mode 100644 index 0000000..93e8840 --- /dev/null +++ b/doc/rfc/rfc1095.txt @@ -0,0 +1,3755 @@ + + + + + + +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 } + + -- The following assignments are made for the purpose of + -- 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 } + + -- The following definition is made for use in referencing a + -- managed system (for the purpose of proxy management) in the + -- CMIP Object Instance field. It does not represent a MIB + -- 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 + } + + -- 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 } + + + -- 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 + + -- 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 } + + -- 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 + + + -- 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 } + + -- 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 } + + -- 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 } + + -- 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 } + + -- 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 } + + -- 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 + + + -- 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 } + + -- the UDP group + + udp OBJECT-CLASS + SUPERIORS { system } + CONTAINS { + udpInDatagrams, + udpNoPorts, + udpInErrors, + udpOutDatagrams + } + ::= { mib 7 } + + + -- the EGP group + + egp OBJECT-CLASS + SUPERIORS { system } + CONTAINS { + egpInMsgs, + egpInErrors, + egpOutMsgs, + egpOutErrors + } + ::= { mib 8 } + + + + +Warrier & Besaw [Page 58] + +RFC 1095 CMOT April 1989 + + + -- 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. + + -- + -- the manager sends an ACSE association request carried in a + -- presentation connect request PDU + -- + + { + 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 + } + } + } + } + } + } + + + -- + -- the agent sends an ACSE association response carried in a + -- presentation connect response PDU + -- + + { + 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 + } + } + } + } + } + } + + + -- + -- the manager sends a get request to read the values of + -- ipInHdrErrors and ipInAddrErrors + -- + + { + 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 + + + -- + -- the agent replies with a get response indicating that + -- ipInHdrErrors = 0 and ipInAddrErrors = 2 + -- + + { + 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 + } + } + } + } + } + } + } + + + -- + -- the manager sends a get request to discover the ipRouteType for + -- the IP routing entry with ipRouteDest = 10.0.0.51 + -- + + + + + +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 + } + } + } + } + } + } + + + -- + -- the agent replies with a get response indicating the appropriate + -- route type + -- + + { + 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" + } + } + } + } + } + } + } + + + -- + -- the manager sends a get request to read the TCP connection with + -- the well-known port for FTP. + -- + + { + 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 + } + } + } + } + + + -- + -- the agent replies with a get response providing the desired TCP + -- connection information. If more than one TCP connection had + -- satisfied the filter condition, a series of one or more linked + -- reply PDUs would have been returned before the final get response. + -- + + { + 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 + + + -- + -- the manager sends a presentation release request + -- + + { + releaseRequest { -- LPP + user-data { -- ACSE + reason normal + } + } + } + + + -- + -- the agent sends a presentation release response + -- + + { + 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] +
\ No newline at end of file |