Request For Comments: CMOT Draft Warrier The Common Management Information Services over TCP/IP Unni Warrier Unisys Corporation December 1, 1988 1. Status of this Memo This memo defines a management architecture that prescribes the use of the International Standards Organization's Common Management Information Services and Protocol, suitable for implementation on top of TCP. It provides a means by which control and monitoring information regarding a network element may be conveyed to a remote manager. This architecture provides a means of implementation of the Draft International Standard Common Management Information Services and Protocol, suitable for deployment in the internet while CMIS/P move towards becoming International Standards. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the DARPA/NSF Internet with CMIS/P. This memo proposes a standard for the Internet community. TCP/IP implementations in the DARPA/NSF Internet which are network manageable are expected to adopt and implement this standard. 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 has directed the Internet Engineering Task Force (IETF) to co-ordinate the work of three working groups in the area of network management. One group is charged with the specification and definition of elements to be included in the Management Information Base (MIB). The second group was charged with defining the modifications to the Simple Network Management Protocol (SNMP) to accommodate the short-term needs of the network vendor and operations communities. The third group ["NetMan"] was charged with meeting the longer-term needs of the Internet community using the ISO CMIS/CMIP framework as a basis, and to align with the output of the MIB working group. Warrier [Page 1] Request For Comments: CMOT Draft Warrier The MIB working group has produced two memos, one which defines a Structure for Management Information (SMI) [2] for use by the managed objects contained in the MIB. A second memo [3] defines the list of managed objects. The SNMP working group has produced one memo which defines the short term protocol standard for the internet[7]. This memo is the output of the Netman working group, and is being issued in the spirit of RFC1052, ie providing a transition path from the SNMP definitions towards the ISO CMIS/CMIP framework. This transition path is mainly through close alignment with the output of the MIB working group, ie the core of managed objects and their definitions are aligned with the MIB working group RFCs, which are expected to develop to provide support for this standard. The Netman working group has sponsored a demonstration of the CMIP/CMIS capablility using the TCP/IP MIB, as well as some extensions that showed the feasibility of the CMIS/CMIP framework. The experience of this demonstration translates into this standard for the internet. The issuance of this memo has become possible because of two factors. One is that the ISO CMIP/CMIS has now been voted a Draft International Standard, thus providing a stable target for development. The second factor is that the experience of the demonstration has given the participating vendors enough confidence in the standard that product development work could be started. In the interests of spurring standardization of such development, a profile of the CMIP/CMIS protocol is defined here. It is expected that this profile will not change while the ISO standard moves from Draft International Standard to an International Standard. If, however, the standard does change unexpectedly, the Netman Working Group will review such changes for appropriate action. This memo, along with the MIB working group memos, defines a network management model compatible with the ISO CMIP/CMIS architecture. Warrier [Page 2] Request For Comments: CMOT Draft Warrier 2.1 Acknowledgements This RFC is the work of many people. Members of NetMan who were instrumental in this effort are: Lee LaBarre Amatzia Ben-Artzi Larry Besaw Asheem Chandna Ken Chapman Gabrielle Cressman George Cohn Pranati Kapadia Dave Mackie Jim Robertson Milt Roselinsky Marshall Rose John Scott In addition, this work draws from the technical work of two other forums: the OSI Network Management Forum,and the Network Management Special Interest Group (NMSIG) of the National Institute of Science and Technology (NIST) (formerly the National Bureau of Standards). Warrier [Page 3] Request For Comments: CMOT Draft Warrier PART I. A TUTORIAL INTRODUCTION 3. The CMOT Architecture The motivation for the CMIS over TCP/IP (CMOT) architecture is to propose a standard way to manage TCP/IP and related objects. It takes advantage of the management standards developed by ISO, while using them over the TCP/UDP transport services available today. This approach will facilitate the continued management of the internet as it migrates from TCP/IP to ISO standard transport protocols, enabling the management of networks that contain both types of components during the transition. It also builds on the many years of effort expended within the ISO and IEEE in developing management standards. 3.1 The Architectural Model The architectural model for CMOT Management is the same as the ISO model, i.e. that defined in the ISO Network Management Framework document [10]. As illustrated in that model, the essentials of network management must include definitions of the data being managed, the operations that can be performed on these data, and the protocols supporting the remoting of these operations across networks. Aspects of network management undergoing standardization include: 1. a common framework, or reference model, for describing network management concepts in terms of the logical components that take part in management, 2. a set of communication services and related protocols to transfer management operations and responses and events between managing and agent processes, 3. a common structure for the management information (SMI), 4. detailed specifications of the managed objects, and their attributes, and the management operations permitted on them, and 5. a mechanism for registering managed objects and associated characteristics. How management, per se, is accomplished is not standardized. That is, the algorithms for processing network resource observations, manipulating them to decide if management control actions are necessary, and deciding how to effect and sequence any resulting control actions to accomplish a complex management scenario are not standardized. Vendors are free to use their ingenuity to develop competitive edges in management decision-making capabilities and performance, in the efficacy and sophistication of the network manager's man/machine interface, and so on. Thus, the standards are designed to expedite the commercialization of interoperable network management products without stifling vendor creativity or product differentiation, since, at a minimum, all vendors would use the same standard tools to allow network resource observation and to allow management control action dissemination. Warrier [Page 4] Request For Comments: CMOT Draft Warrier Management may be modeled from several perspectives. An organizational model describes ways in which management can be administratively distributed. The functional model describes what management services are available to management users, and their relationships. The information model provides guidelines for describing the logical structure of the managed objects and their associated management information. 3.2 The Organizational Model The network management for a large internet will normally be partitioned into a number of management domains for reasons of scale, security, or to provide administrative autonomy over an organization's resources. Each management domain has a managing process which monitors and controls the managed objects associated with agent processes in the end-systems and intermediate systems in its domain. The management domains may overlap each other; one may be contained within another; or, they may be disjoint. An individual managed object can participate in multiple management domains. Each domain's managing process may be required to interact with managing processes of other domains to form either hierarchical or peer manager-to-manager relationships for global network management. The administration of a management domain is performed by an administrative authority. This authority may be a public organization offering communication services, e.g., telecommunication administrations, or a private organization. The administrative authority is responsible for creation, modification, and maintenance of: 1. managed objects, 2. relationships among managing and agent processes of distributed management applications, 3. relationships among agent processes and managed objects within corresponding managed systems, and 4. security mechanisms for access to managed objects and processes of the distributed management applications. NOTE: It is beyond the scope of this specification to define the relations and interactions between different domains. Our model concerns itself only with the operations and characteristics of one single domain of management. All subsequent discussions in this memo should be viewed as such. The extension of the mechanisms defined here to include multiple-domains is left for further study and future RFCs. Warrier [Page 5] Request For Comments: CMOT Draft Warrier 3.2.1 The proxy concept In the context of ISO, management is exchanged among "open systems". >From a practical point-of-view this requires every system which participates in the exchange of management-information to implement the supporting software. In "limited" systems, such as modems and bridges, that may not be possible. In particular, in the context of TCP/IP networks, these devices typically do not have their own IP addresses. Another use of the proxy approach is to protect the managed systems from management messages overloading their normal functioning. Management information that is destined for a "limited" system (e.g. a bridge) is passed to its proxy, rather than directly to that system. The "proxy" is an open system, (which has a network address) which is capable of exchanging management information, and has elected to act on behalf of the other system (the bridge) for management purposes. The proxy then uses other methods to convey (or retrieve) the information to (from) that limited system, and passes the results back to the management-peer. The management-peer (typically the MANAGER) is not aware of this process; in its view, management information was exchanged directly with this "limited" system. The information exchange between the proxy and the limited system depends on the specific system, and is not within the scope of this memo. In general, it is expected that limited-systems will use standard mechanisms available at their level of operation (e.g., MAC bridges may use 802.1 management protocols between themselves and the proxy). Each proxy may support several "limited" systems, in addition to supporting management functions for its own operations. The distinction between all the different systems is provided in the "instance" specification of management commands. During the data transfer, the proxy system uses the instance specification to distinguish (and de-multiplex) between the different limited systems it supports. The mapping between a specific instance and an actual limited system is a local matter. 3.3 The Functional Model The functional model for Common Management Information Services over TCP/IP (CMOT) network management is the one specified by ISO DIS 7498/4: the Management Framework [10]. Thus the management protocol uses an association control service (ACSE), and a remote operations service (ROSE). The difference is that, whereas in the ISO model, the underlying transport for these service elements has been defined to be the International Standards TP4 [18,19] and CLNP[18,19], here the transport is defined by the Internet standards TCP [3], UDP [1] and IP [2]. This is, however, transparent to the management application. Warrier [Page 6] Request For Comments: CMOT Draft Warrier Each manageable device on the network has network management built into it. For the purpose of management, that part of each such device that reports to and/or receives instructions from a manager is called an "Agent". A "Manager" is typically a specialized device, that runs management applications and collects its data from, as well as operates on agents. Agents have management modules associated with each communications layer known as LMEs (Layer Management Entities). All these modules are coordinated inside the agent by a management entity (ME) that accepts information from and delivers information to the LMEs. The manager has essentially the same structure, so that management communication occurs between MEs. The management protocol (CMIP) has no assumptions as to who opens the connection to who, or about the direction of management data transfer--the protocol mechanisms provided are fully symmetric between the manager and the agents. MANAGER AGENT ------------------------- ----------------------------- ! ! ! ! ! !----! !----! !-----! ! <-------> ! !----! !----! !-----! ! ! !ACSE! !ROSE! !CMISE! ! CMIP ! !ACSE! !ROSE! !CMISE! ! ! !----! !----! !-----! ! ! !----! !----! !-----! ! ! ! ! ! ------------------------- ----------------------------- ! TPP ! ! TPP ! LME ! ------------------------- ----------------------------- ! TCP ! ! TCP ! LME ! ------------------------- ----------------------------- ! IP ! ! IP ! LME ! ------------------------- ----------------------------- ! MAC ! ! MAC ! LME ! ------------------------- ----------------------------- | | | | | | ========================================================= NETWORK ========================================================= Figure 1. An Agent-Manager Model Warrier [Page 7] Request For Comments: CMOT Draft Warrier To support diverse management user needs, the notion of Specific Management Functional Areas (SMFAs) has been developed that describes the facilities available, or procedures to be used, to meet specific management requirements. As described below, there are five SMFAs: Fault Management, Performance Management, Security Management, Accounting Management, and Configuration Management. 3.4 The Information Model Management Information is modelled 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. "Manageable", in this context, means that the particular resource can be managed using CMOT. Examples of Managed Objects include protocol state machines, 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. Each Object Class has a pre-defined name assigned to it by a standards' registration authority. 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 realisation of an Object Class. Managed Objects contain properties which are referred to as attributes. Attributes are atomic items of information that can only be manipulated as a whole. This information model is a refinement of that in RFC1065 (Structure of Management Information) and its companion, RFC1066 (Management Information Base). There is a mapping between these two models. One such mapping is provided in Appendix A. Managed Objects participate in relationships with each other. The relationships that are of particular concern to the Management Information Model are a) the containment relationship, and b) the inheritance relationship. These relationships are used to construct Management Information Hierarchies, as described below. Managed objects, their attributes and events, are described using the ISO Abstract Syntax Notation (ASN.1). Warrier [Page 8] Request For Comments: CMOT Draft Warrier 3.4.1 Management Information Hierarchies Central to the representation of management information is the concept of Management Information Hierarchies. The following Management Information Hierarchies are identified: 3.4.1.1 The Containment Hierarchy This 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. Attributes are contained within objects at any level of the containment hierarchy. Attributes cannot contain objects or other attributes. All object classes 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 Object Instances. It also defines an existence dependency among its components; i.e. an object or attribute can 'exist' only if the containing object also 'exists'. Deletion of an object automatically results in deletion of all objects and attributes contained within it. 3.4.1.2 The Inheritance or Object Class Hierarchy This hierarchy is constructed by applying the relationship "inherits properties of" to object classes. An object class may inherit properties of another object class, with refinement obtained by adding additional properties. The inheriting class is called the subclass in this relationship, and the parent the superclass. For example, the class "Network Entity" may be a subclass of "Layer Entity" and a superclass of "X.25 Network Entity". Each class has only one superclass, but may have zero, one or more subclasses. Subclasses may in turn have furthur 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 object and/or instance naming. It is useful in that it leads to a manageable and extensible technique for the definition of object classes. However, it is useful for defining a Management Information Base, which is a function of the MIB Working Group. Warrier [Page 9] Request For Comments: CMOT Draft Warrier 3.4.1.3 The Registration Hierarchy This hierarchy is not based on any particular relationship, and is independent of both the inheritance and containment hierarchies. It contains Object Identifiers for Object Classes and Attributes, as assigned by the standards' registration authority (the MIB Working Group, for instance). The Registration Hierarchy is important because it is used for identifying Object Classes and Attributes. 3.4.1.4 Registration, Containment and Naming illustration | Private(0) | --------------------------------- | | Company X (0) Company Y (1) | | --------- ------------------------------- | | | | | | Pbx_id(0) Pbx(1) Modem_typ(1) Mux(2) Modem(3) Modem_id(4) Figure 2. An Example Registration Tree The numbers in the brackets () are assigned by the registration authority (MIB WG). As the registration tree is descended from the top to the desired object or attribute, these values are concatenated to yield a unique identifier for the desired object class or attribute. Pbx | | ---------------------------------- | | Mux Modem | Modem Figure 3. A Corresponding Containment Tree Warrier [Page 10] Request For Comments: CMOT Draft Warrier This portion of a containment tree shows that there are instances of a Pbx object that may contain zero or more Mux which in turn may contain zero or more modems. Also the pbx may contain zero or more modems that are not contained in a mux. The values enclosed in the brackets <> indicate which attributes are to be used as distinguishing attributes for the object. Pbx <54> | | ---------------------------------- | | Mux <11> Modem <3> | <6> Modem <3> <29> Figure 4. A Specific Instance of the Containment Tree This is a single set of instances of the general containment tree detailed previously. Pbx 54 contains a mux whose mux_id attribute=11, which in turn contains a modem of modem_type=3 and modem_id=29. The Pbx 54 also contains a modem of modem_type=3 and modem_id=6. OBJECT IDENTIFICATION In order to identify the modem of modem_type=3 and modem_id=29 both the CMIP managedObjectClass and managedObjectInstance must be identified. The managedObjectClass is of type ObjectClass and the global form is obtained by traversing the registration tree, concatenating the identifiers until the desired object is reached. Thus for the modem: managedObjectClass = 0.1.3 The specific instance of the modem is identified by the concatenation of each of the instances of each object encountered while traversing the containment tree. Therefore to get to the desired modem which is contained in mux 11 which is in turn contained in PBX 54, the managedObject instance is: "The instance of the pbx then the instance of the mux then the instance of the modem." Or slightly refined: Pbx=54 then muxid=11 then modem_type=3 and modem_id=29. Warrier [Page 11] Request For Comments: CMOT Draft Warrier In terms of the ASN1 each of the instances in the sequence is a set of attribute type and attribute value assertions. The notation used below is an illustrative convenience and is not meant to indicate how the sequence is actually encoded. Below, each set is shown enclosed in {} brackets, the attribute type is the global form of object identifier and is enclosed in <>, followed immediately by the value also in <>. Attributes and their values within the same set are separated by commas. Using this notation the sequence above becomes {<0.0.1><54>}, {<0.1.0><11>}, {<0.1.1><3>, <0.1.4><29>} Note that the object instance tree can contain components of the distinguished name which are outside the managed system (node). This enables referencing of objects across management domains 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 first portion of the name to determine where to send a request/result, i.e., resolve the presentation address for the request. This technique of naming treats each intermediate manager 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/results. 3.4.1.5 The Management Information Base (MIB) The MIB is a conceptual repository of management information, i.e. the objects that are being used in management. It provides a structured and consistent mechanism for representation of management information. Note that the MIB is conceptual in that it does not carry any implications whatsoever about the physical storage ( files, databases, etc ) of management information. This information could very well exist on a local store in the managing or managed system; or could be generated spontaneously as a result of a management (CMIP) transaction. In any case, there has to be a registered (i.e. global) definition of the objects in the MIB. The definition of a managed object includes specification of the set of management operations that can be performed upon it and the effect of these operations on the object and its attributes. Also included in the specification are the conditions under which the operation is valid and the set of possible ways that the operation may fail. In the CMOT context, such a definition would come from a MIB working group. Appendix A provides a protocol-dependent interpretation of the current TCP/IP standard MIB. Warrier [Page 12] Request For Comments: CMOT Draft Warrier 4. The CMOT Protocol Architecture The objective of the CMOT protocol architecture is to map the OSI management protocol architecture into the TCP environment. As mentioned before, the model presented here follows the ISO model at the application layer, and the Internet model in the transport layer. The gap between these two ends, in ISO, is filled by the presentation and session layers. However, in the CMOT case, the approach taken is to "fill the gap" by introducing a new non-standard "filler" between the two ends. The reason that this is done is to provide a migration path to "full ISO" in the future. Such migration would be accomplished by replacing the entire TCP and below with ISO protocols, and replacing the "filler" with real presentation and session protocols. Such an approach pays off only if such a filler is VERY simple and VERY small, since then the investment of putting it together now and replacing the entire stack later, is minimised. It is also important to EMPHASIZE here that although the "filler" is something that will ultimately be replaced in the future, its interface to all the other modules (ACSE, ROSE, and DSE) and the services it provides are "REAL". As a result, the amount of effort "wasted" is minimal. In particular, it supports "real" application layer with no changes, which means that investments in applications development is well preserved. Such a "filler" protocol is defined in IDEA017, as the "Thin Presentation Protocol" (TPP). This protocol provides minimal support for the management function to accomplish management exchange over TCP, and hence makes severe restrictions on the kind of functions that are provided by a real presentation protocol. In particular, there is no support for session pass-throughs, for negotiation of transfer and abstract syntaxes, and for real Directory Services (instead a "stub directory" is defined therein). The protocol stack for this approach is shown in Figure 1. In the context of ISO, a dialog involves an association, not just a connection, as in TCP. The association can be established on top of different modes of transport (UDP or TCP), which are transparent to the application. The CMOT architecture takes advantage of this transparency to provide for management transport over either TCP or UDP (however, the application should be conscious that negotiating a UDP association is a different Quality of Service from negotiating a TCP association). The association is created between the applications through the services provided by the Association Control Service Entity (ACSE). In order to convey the information, a presentation layer (here the TPP) translates all information into a "transfer syntax" and conveys it over the transport to the receiving presentation layer. This association can occur over a reliable or unreliable transport, depending on the "Quality Of Service" that was requested by the initiator of the association. It is during this phase of association that the manager/agent relations are established and agreement on the scope of the relationship (e.g., capabilities) is negotiated. The association establishment procedure allows a limited capability to negotiate the management context. The management context can specify both the management functions supported on both sides, and the versions of the MIB that are supported. Warrier [Page 13] Request For Comments: CMOT Draft Warrier Once the association has been established, either over TCP or UDP, management information is exchanged via remote service invocations. M-GET, M-SET, M-EVENT-REPORT, etc are the functions specified. These functions are invoked over the Remote Operations Service Element (ROSE). The Remote Operations Service Element (ROSE) provides the capability of remote procedure calls over a pre-established association. ROSE enables the correlation of invocation and result via the use of invoke ids. Although ROSE is specified to use a reliable transport, in the CMOT context, we allow ROSE to use an unreliable transport (UDP) as well. CMIS services then are particular instances of procedures that are called remotely from the manager to the agent or vice-versa. Over either TCP or UDP, the service calls are the same. However, the application should be aware of the Quality of Service that it is using. 4.1 Quality of Transport The quality of service (QOS), or more specifically the quality of the underlying transport needed for network management applications has been an issue that caused a lot of controversy, yet never been resolved. There are two basic approaches: datagram oriented, and connection oriented. There are advantages and disadvantages to either 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 reliability of the data, and provides guaranteed and consistent service to the driving application. This RFC does not take sides in this issue. Rather it passes such resolution to the network management applications, which are ultimately the point where the requirements from the underlying service need to be determined. As such, the CMOT stack provides both services. The interface to the application allows the application to direct the choice of transport to the transport preferred by the application (i.e., low quality--UDP or high quality--TCP). It is possible that an implementation would use the presentation selector in the Thin Presentation to determine the QOS supported by a particular agent. Warrier [Page 14] Request For Comments: CMOT Draft Warrier 4.2 The Application Layer 4.2.1 Introduction A brief overview of the terminology associated with the OSI application layer structure is presented here. This is intended to facilitate the comprehension of the remainder of this document, where heavy usage is made of the terms defined here. It is by no means a complete treatment of the subject, which is described in an ISO document on Application Layer Structure[22] 4.2.2 Overview of Application Layer Structure In the OSI environment, communication between "application processes" is modelled 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. The application entity is a set of communication capabilities whose components are 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. When communication is required between two application entities, one or more "application associations" are established between "application entity invocations". 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 a single or multiple application service elements. In the case of multiple application service elements, a set of rules by which the constituent application service elements may work together (i.e., sequentially or in combination) is associated with the context. 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. The description of an APDU may require reference to one or more abstract syntax definitions. 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. Warrier [Page 15] Request For Comments: CMOT Draft Warrier 4.2.3 CMISE - Detailed Description A detailed service description of CMISE is provided in this section. The CMISE provides both notification/operation-oriented and data-manipulationservices to its users. It also provides the capability to issue a series of (multiple) linked replies to an action or data-manipulation service. -------------------------------------------- | 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 The OSI Common Management Information Service Element (CMISE), is a user of the Remote Operations Service Element (ROSE) and the Application Assosciation Service Element (ACSE). The CMISE provides a common message framework for management procedures that are invoked remotely. A notation is provided for users of the service element to specify the specific messages (e.g., alarm reports,tests, etc) that are used. Management information services are used by application processes in peer open systems, to exchange information and commands for the purpose of systems management. There are two types of information transfer service: a. a management notification service b. a management operation service The Common Management Information Service provides additional facilities that enable multiple responses to confirmed operations to be linked to the operation by the use of a linked identification parameter. The Common Management Information Service also provides a service for the establishment and release of application associations. Warrier [Page 16] Request For Comments: CMOT Draft Warrier 4.2.3.1 Management Association Services These services control the establishment, normal and abnormal release of a management association. These services are simply pass-throughs to the Association Control (ACSE). The M-INITIALISE service is invoked by a CMISE-service-user to establish an association with a peer CMISE-service-user for the purposes of exchanging management information. A reply is expected. The M-TERMINATE service is invoked by a CMISE-service-user to release an association with a peer 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 peer CMISE-service-user in an abrupt manner. 4.2.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 the Common Management Information Service. 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 peer CMISE-service-user. The service may be requested in a confirmed or a non-confirmed mode. In the confirmed mode, a reply is expected. 4.2.3.2 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 the CMIS. However, certain operations are used frequently within the scope of systems 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 peer CMISE-service-user. The service may only be requested in a confirmed mode, and a reply is expected. The M-SET service is invoked by a CMISE-service-user to request the modification of management information by a peer CMISE-service-user. The service may be requested in a confirmed or a non-confirmed mode. In the confirmed mode, a reply is expected. Warrier [Page 17] Request For Comments: CMOT Draft Warrier The M-ACTION service is invoked by a CMISE-service-user to request a peer 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 peer CMISE-service-user to create another instance of a managed object. The service may only be requested in a confirmed mode, and a reply is expected. The M-DELETE service is invoked by a CMISE-service-user to request a peer CMISE-service-user to delete an instance of a managed object. The service may only be requested in a confirmed mode, and a reply is expected. 4.2.3.4. Functional Units The general service capabilities are designated as functional units, where functional units correspond to the invoker/performer support of each of the service primitives. Stand alone functional units and their relationship with service primitives are listed in Table 2. 4.2.3.4.1 Additional Functional Units If any of the additional functional units are selected, then at least one of the stand alone functional units shall be selected. 4.2.3.2.1.1. Multiple Reply Functional Unit This functional unit makes available the use of the linked identification parameter in the selected stand alone functional units. 4.2.3.2.1.2. Multiple Object Selection Functional Unit This 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 shall also be selected. 4.2.3.2.1.3. Extended Service Functional Unit This functional unit makes available presentation layer services in addition to the P-DATA service. Warrier [Page 18] Request For Comments: CMOT Draft Warrier Table 2. Stand Alone Functional Units ------------------------------------------------------------------------ | Functional Unit (number) | Service Primitive | Mode | |===============================|========================|=============| | conf. event report invoker(0) | M-EVENT-REPORT Req/Cnf | confirmed | | conf. event rep. performer(1) | M-EVENT-REPORT Ind/Rsp | confirmed | | event report invoker(2) | M-EVENT-REPORT Req | non-confrm. | | event report performer(3) | M-EVENT-REPORT Ind | non-confrm. | | confirmed get invoker(4) | M-GET Req/Conf | not appl. | | confirmed get performer(5) | M-GET Ind/Rsp | not appl. | | confirmed set invoker(6) | M-SET Req/Conf | confirmed | | confirmed set performer(7) | M-SET Ind/Rsp | confirmed | | set invoker(8) | M-SET Req | non-confrm. | | set performer(9) | M-SET Ind | non-confrm. | | confirmed action invoker(10) | M-ACTION Req/Conf | confirmed | | confrm. action performer(11) | M-ACTION Ind/Rsp | confirmed | | action invoker(12) | M-ACTION Req | non-confrm. | | action performer(13) | M-ACTION Ind | non-confrm. | | confirmed create invoker(14) | M-CREATE Req/Conf | not appl. | | confrm. create performer(15) | M-CREATE Ind/Rsp | not appl. | | confirmed delete invoker(16) | M-DELETE Req/Conf | not appl. | | conf. delete performer(17) | M-DELETE Ind/Rsp | not appl. | | multiple reply(18) | linked id in some FUs | not appl. | | mult. object selection(19) | scope, synchronization | not appl. | | extended service(20) | extended P-DATA | not appl. | ------------------------------------------------------------------------ 4.2.3.5 SMI-related Issues Within some services, CMIS provides additional capabilities that are related to the Structure of Management Information (SMI). These are scoping, filtering, synchronization and linked-reply facilities, which are all bundled into the Multiple Object Selection Functional Unit. This Unit provides the manager with the ability to operate on a collection of managed objects, rather than a single object. In this case, the object specification in a command would resolve to a "base" object. Now the command can be thought of as operating in two phases. 4.2.3.5.1 Scoping Scoping is applied to the "containment tree" under the base object. The scope of the command can be specified as being applicable to all objects within "n" levels under the base object. 4.2.3.5.2 Filtering Within the objects selected as a result of the scope parameter, it is possible to furthur refine the selection through the use of filtering. Filters provide the means to select a subset of these objects, e.g. "those connections which have sent more than 42 IP packets". Warrier [Page 19] Request For Comments: CMOT Draft Warrier 4.2.3.5.3 Synchronization Once a subset of objects has been chosen, since a single command has been specified, the question of operation atomicity comes up. For example, if a SET is to be performed on this subset, and it fails on one of the members, should the entire operation be rolled back? Setting the synchronization to atomic would cause the rollback to happen, while setting it to "best effort" does not. 4.2.3.5.4 Linked Replies If the single command on the subset of objects elicits one reply per member object, all these replies cannot be sent on a single reply PDU. This is because the structure of the reply PDU includes a single objectInstance. Since these different member objects have different objectInstances, their replies have to necessarily come in multiple reply PDUs. In order to associate all these multiple replies with the original (single) request, the linked-reply PDU is specified in the standard. PART II. PROTOCOL AGREEMENTS 5. Scope and Field of Application This is a specification of the protocol elements of the CMOT architecture. Connection oriented and connectionless-mode protocols are specified for the transport layer. These protocol suites will facilitate communication between equipment of different vendors, suppliers and networks. 5.1 Profile Selection and Selection Policy The profile selection policy is to use existing standards and draft standards from the international arena (primarily ISO), as well as existing standards (RFCs) within the Internet. This document is based on existing standards and draft standards for OSI network management and other OSI layer 7 standards. To implement the standards, profiles must be established based on choices of options from the standards and implementation choices must be made for parameters not specified in the standards. This document is a detailed, carefully reviewed statement of the profile options and implementation options chosen for CMOT to utilize the OSI network management standards. In addition to NetMan, there are at least two other bodies creating profiles for interoperability in the ISO arena. These are the NIST NMSIG and the OSI NM Forum. The desire is to fit these profiles as closely as possible to the two bodies, in the interest of more complete interoperability. Warrier [Page 20] Request For Comments: CMOT Draft Warrier The choices made by NetMan in defining these profiles are identified in the other sections of this document. An overview of the protocol architecture is depicted in Figure 5. ------------------------------------------------ | | | MANAGEMENT APPLICATION PROCESSES | | | ------------------------------------------------ ---------------------- | MANAGEMENT | | SPECIFIC ASE | ---------------------- ---------------------- | CMISE | | ISO DIS 9595, 9596 | ---------------------- ------------------- ---------------------- | | | | | ACSE | | ROSE | |ISO IS 8649, 8650| | ISO DIS 9071, 9072 | | | | | ------------------- ---------------------- ------------------------------------------------ | THIN PRESENTATION LAYER | | RFC XXX (IDEA 017) | ------------------------------------------------ ------------------- ---------------------- | | | | | TCP | | UDP | | RFC 793 | | RFC 768 | | | | | ------------------- ---------------------- ------------------------------------------------ | IP | | RFC 791 | ------------------------------------------------ Figure 5. CMOT Protocol Architecture Warrier [Page 21] Request For Comments: CMOT Draft Warrier 6. Conformance Requirements There is one class of conformance for the upper-layer protocols (layers 5-7), for transactions. There are two conformance classes for the lower-layer protocols: one for use in connection-oriented environments; and one for connectionless environments. The upper-layer protocols may be used over either lower-layer protocol stack. An implementation claiming conformance to any of the conformance classes must implement all of the protocol elements listed for the respective classes in Tables 1 - 4, except at the CMISE. At the CMISE, at least one of the set of listed functional unit groupings must be supported. Conformance at the physical and datalink levels is defined as "any network that supports the Internet Protocol (IP)". The conformance classes are summarized below: ----------------------------------- | Layer | Services Required | ==============|==================== | Application | ACSE | | | ROSE | | | CMISE | ----------------------------------- Table 3. Upper-Layer Conformance for Transaction Services ----------------------------------- | Layer | Services Required | ==============|==================== | Transport | TCP | ----------------------------------- | Network | IP | ----------------------------------- Table 4. Lower-Layer Conformance for Connection-Oriented Services ----------------------------------- | Layer | Services Required | ==============|==================== | Transport | UDP | ----------------------------------- | Network | IP | ----------------------------------- Table 5. Lower-Layer Conformance for Connectionless Services The service and protocol selections are described in greater detail in the following sections. Warrier [Page 22] Request For Comments: CMOT Draft Warrier 7. APPLICATION LAYER 7.1 Abstract Syntax Notation and Encoding The abstract syntax notation for \fIall\fH of the application service elements of the CMOT application layer protocols is ASN.1 [13,14]. 7.2 Association Control Service Element 7.2.1 Overview The association control service element (ACSE) is a mandatory service element. It is required for setting up and releasing application layer associations. 7.2.2 ACSE Service for the Application Layer The ACSE service description is detailed in ISO 8649 [16]. All of the defined ACSE services are mandatory: - A-ASSOCIATE: this confirmed service is used to initiate an application association between application entity invocations. - A-RELEASE: this confirmed service is used to release an application association between application entity invocations without loss of information. - A-ABORT:\fH this unconfirmed service causes the abnormal release of an association with a possible loss of information. - A-P-ABORT:\fH 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 ACSE services to presentation services and APDUs (for normal mode) are shown in Table 5, along with a section reference in ISO 8649 [16]. ----------------------------------------------------------------- | 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 Warrier [Page 23] Request For Comments: CMOT Draft Warrier 7.2.3 ACSE Protocol for the Application Layer The protocol specification for ACSE shall follow ISO 8650 [17]. All five APDUs specified in the standard are mandatory. 7.2.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 CMIP 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(1) mib(n) cmot(9) cmot-version(1) version-number(v) } Here v = version of CMOT supported and n = highest MIB version number For the versions of the protocols used in the protocol architecture used in these agreements [Figure 5], "version-number" has the value one (1). [NOTE: The use of this particular object identifier requires the registration of cmot as an object class by the MIB Working Group. Such a ratification, placed on the MIB WG tablem is expected at their next meeting.] 7.2.3.2 Parameters for the Presentation Service The values and defaults of parameters to the ACSE primitives which are given to the presentation service, are specified in the draft memo entitled "ISO Presentation Services on top of TCP/IP-based internets" (IDEA0017) [9]. For the Presentation Context Definition List parameter to the P-CONNECT service (see IDEA 17, p. 11), the value of the Abstract Syntax Name associated with the Presentation Context Identifier one (1) shall be identical to the OBJECT IDENTIFIER used for the Application Context Name. In this context, the "cmot-version" value implies that the versions of ACSE and ROSE specified by these agreements are part of the presentation context. Warrier [Page 24] Request For Comments: CMOT Draft Warrier The following parameter constraints in addition to those specified in the standard are required for conformance: ---------------------------------------------------- | Parameter | Value | |======================================|===========| | Mode-Selection | Normal | | Multiple-Defined-Context | True | | Presentation-Context-Definition-List | see above | ---------------------------------------------------- 7.2.3.3 ACSE 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.7.2.1.1 for more information on the CMIS M-INITIALISE parameters to be supplied.) The ACSE User Information is defined in ISO 8650 as follows: Association-information ::= SEQUENCE OF EXTERNAL For each type defined as EXTERNAL, ASN.1 requires an associated OBJECT IDENTIFIER. For each of the CMIS M-INITIALISE parameters encoded in the user-information field of the ACSE PDUs, the encoding CHOICE of "single-ASN1-type" (defined as ANY) will be used. The actual ASN.1 syntax for a particalar parameter is given in the following sub-sections. In order to assign CMOT object identifiers to these fields, the following (new) branch for CMOT has been created in the Internet sub-tree, with the assignments shown: {iso(1) org(3) dod(6) internet(1) mgmt(1) mib(n) cmot(9)} Under this branch, ACSE information has been assigned the first branch, and object identifiers assigned as follows: {iso(1) org(3) dod(6) internet(1) mgmt(1) mib(n) cmot(9) acse-info(1)} functional-units(1) user-information(2) access-control(3) Here n = highest MIB version number Warrier [Page 25] Request For Comments: CMOT Draft Warrier 7.2.3.3.1 Functional Units The FunctionalUnits EXTERNAL data is defined as a BIT STRING in ISO 9596. The legal values for this BIT STRING are given in section 7.4.2.1.3. The value of the OBJECT IDENTIFIER in the "direct-reference" field of the EXTERNAL type for Functional Units is 1.3.6.1.1.1.9.1.1. 7.2.3.3.2 User Information The CMIS User Information part of the ACSE User Information field is defined here as follows: UserInformation ::= SEQUENCE OF OBJECT IDENTIFIER The use of this user information field is described in section 7.4.2.1.4. The value of the OBJECT IDENTIFIER in the "direct-reference" field of the EXTERNAL type for User Information is 1.3.6.1.1.1.9.1.2. 7.2.3.3.3 Access Control The Access Control part of the ACSE User Information field is defined here as follows: AccessControl ::= OCTET STRING The use of this access control field is described in section 7.4.2.1.5. The value of the OBJECT IDENTIFIER in the "direct-reference" field of the EXTERNAL type for Access Control is 1.3.6.1.1.1.9.1.3. 7.3 Remote Operations Service Element 7.3.1 Overview The remote operations service element (ROSE) shall be a mandatory service element for transaction oriented management applications. The ROSE offers a simple, yet uniform service for remotely invoking operations and then receiving correlated replies to those operations. The ROSE shall be used only once an application association has been set up between two application entity invocations. (A tutorial on the ROSE is available in the literature.) ROSE is used in support of CMISE; it is not intended that ROSE will be used directly by management applications. Warrier [Page 26] Request For Comments: CMOT Draft Warrier 7.3.2 ROSE Service Requirements for the Application Layer The ROSE service description is detailed in ISO 9071 [20]. All of the defined ROSE services are mandatory: - 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. . - 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. - 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. - RO-REJECT-U: this unconfirmed service is used by a ROSE-user to reject a request (RO-INVOKE indication) of the other 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. - 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 presentation services and APDUs are shown in Table 6, along with a section reference in CCITT Recommendation X.219. --------------------------------------------------------------- | ROSE | X.219 | Related | Associated | | Service | Reference | Presentation Service | APDUs | |=============|===========|======================|============| | RO-INVOKE | 10.1 | P-DATA | ROIV | | RO-RESULT | 10.2 | P-DATA | RORS | | RO-ERROR | 10.2 | P-DATA | RORE | | RO-REJECT-U | 10.2 | P-DATA | RORJ | | RO-REJECT-P | 10.2 | P-DATA | RORJ | --------------------------------------------------------------- Table 6. Mapping of ROSE services Warrier [Page 27] Request For Comments: CMOT Draft Warrier 7.3.3 ROSE Protocol for the Application Layer The protocol specification for ROSE shall follow ISO 9072 [21]. All four APDUs specified in the standard are mandatory. In addition, the ability to support correct origination and reception of the linked-id protocol element is required, if conformance to CMOT Functional Unit Groupings (section 7.4.2.1.3)that use this functionality is desired. 7.3.3.1 Use of Underlying Services The ROSE will make use of presentation layer services from the Thin Presentation Layer, in the manner described in the memo entitled "ISO Presentation Services on top of TCP/IP-based internets" [9]. Note that owing to the use of presentation parameters mandated by that memo, first, mappings to the Reliable Transfer Service Element (RTSE) are not possible, as no RTSE is present; and, second, that no data token is used with the presentation services. No further restrictions are placed on the use of presentation parameters mandated in "ISO Presentation Services on top of TCP/IP- based internets" [9]. The quality of service parameter can be set to high/low quality service. This implies that both TCP and UDP will be used as the transport service by ROSE. 7.3.3.2 Operation Class As no turn management is required by the ROSE, this parameter shall be ignored. 7.3.3.3 Priority The ROSE will deliver each APDU in a "first in, first out" manner. Further, in as much as no turn management is required by the ROSE, this parameter shall be ignored. Warrier [Page 28] Request For Comments: CMOT Draft Warrier 7.4 Common Management Information Service Element 7.4.1 Overview The Management services for CMOT are based on the DIS of the OSI Common Management Information Service ISO 9595-2 [23]. The CMISE provides both notification/operation-oriented and data-manipulation services to its users. It also provides the capability to issue a series of (multiple) linked replies to an action or data-manipulation service. 7.4.2 Protocol Agreements The protocol agreements for CMIS fall into two categories. Firstly, there is a general agreement on restrictions to the services provided in the DIS, primarily for efficient implementation purposes. Secondly, a set of groupings of CMIS functional units are provided, based on common requirements from devices. In order to be CMOT conformant, a device thus needs to implement only that portion of the CMISE that is relevant to its functional grouping, again assisting in code reduction at the device. 7.4.2.1 Management Association Services 7.4.2.1.1 M-INITIALISE The following parameters are to be used for the M-INITIALISE service: ------------------------------------------------------ | Parameter Name | Req/Ind | Rsp/Cnf | |=====================|===============|==============| | Functional units | Mandatory | Mandatory | | User information | Optional | Optional | | Access Control | Optional | Optional | ------------------------------------------------------ Table 8. Parameters for M-INITIALIZE service Notice that the further agreement has been made that the Functional Units are mandatory at all times. 7.4.2.1.2 Functional Units The negotiation of Function Units (FUs) supported on a connection association is supported. Such negotiation takes place via the User Information string (20-bit string) specified in the CMIS document. A requestor (e.g. manager) can request a certain set of FUs via the ACSE A-Associate request, and the responser (e.g. agent) can reply with the list it is willing to support via the ACSE A-Associate reply. Warrier [Page 29] Request For Comments: CMOT Draft Warrier 7.4.2.1.3 Functional Unit Groups In order to reduce the costs of implementing CMIS in different devices, in terms of code size, processor utilization and development costs, no single set of functional units is mandated in all CMOT devices. Rather, the CMIS functional units are grouped into sets, and a conformant implementation would need to implement only that Functional Unit Group (FUG) that is appropriate. These FUGs are shown informally in Table 9 below. It is entirely possible that a "superset" FUG could also be conceived, which implements a superset of all of these FUGs. An entity with such a superset will be able to interact with a CMOT-conformant entity by arriving at a "common denominator" FUG as per the M-initialize exchange specifications below. The M-initialize function in CMIS passes a 21-bit string to the other CMIS, telling which functional units it wants support for, in this association. This string will have a 1 if that FU is supported, else a 0. The list of 21 FUs is shown in Table 2. Table 10 now shows the formal correspondence between the groups and the CMIS functional units. The M-initialize exchange will now proceed as follows. First, the requesting entity will pass a requesting bit-string which will contain an FU set request. This request string may or may not correspond exactly to a FUG. The receiving entity will reply with an FU set that SHALL be a (proper or improper) subset of the requested FU set, and may or may not correspond to a FUG. However, the receiving entity now prepares to associate using the largest FUG possible under its replying FU set. The requestor, in turn, now prepares to associate using the same FUG (i.e. the largest FUG subset of the replying FU set). This provides the synchronization needed in the FU list exchange. The only requirement in the management exchange after this association is established, is that both entities provide proper responses to function requests within the FUG, and gracefully discard all other requests. Table 9 shows the FUGs and their operational charracterestics, together with a recommended transport mechanism for that FUG. Where such transport is specified as TCP, it is understood that UDP is supported as well. Where the FUG numbers are shown, it is understood that the first number is the manager (e.g. Event Monitor is FUG1) and the second number is the agent (e.g. Event Sender is FUG2). Thus the FUGs identified, in increasing FUG numbers, are Event Monitor, Event Sender, Passively Monitoring Manager, Passively Monitored Agent, Actively Monitoring Manager, Actively Monitored Agent, Simple Controlling Manager, Simple Controlled Agent, Actively Controlling Manager, and Actively Controlled Agent. Notice that the Simple Controller provides essentially the same functionality as an SNMP Manager. Warrier [Page 30] Request For Comments: CMOT Draft Warrier ------------------------------------------------------------------------- | FUG | Name | Ev. | Get | Set | Crte | Actn | Mult | Mult | Recc. | | No | | Rpt | | | /Del | | Repl | Obj. | Trnprt| |======|=========|=====|=====|=====|======|======|======|======|=======| | FUG1 | Event | U | | | | | | | UDP | | /2 | Monitor | | | | | | | | | | FUG3 | Passive | U | C | | | | | | UDP | | /4 | Monitor | | | | | | | | | | FUG5 | Active | U | C | U/C | C | | Yes | | TCP | | /6 | Monitor | | | | | | | | | | FUG7 | Simple | U | C | U/C | C | | Yes | Yes | TCP | | /8 | Cntrler | | | | | | | | | | FUG9 | Active | U | C | U/C | C | U/C | Yes | Yes | TCP | | /10 | Cntrler | | | | | | | | | ------------------------------------------------------------------------ (U = Unconfirmed, C = Confirmed, U/C = both) Table 9. Functional Unit Groups ------------------------------------------------------------------------ | Functional Unit |FUG1|FUG2|FUG3|FUG4|FUG5|FUG6|FUG7|FUG8|FUG9|FUG10| |===================|====|====|====|====|====|====|====|====|====|=====| |conf ev rept invker| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | |conf ev rept prfmer| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | |event report invker| 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | |event report prfmer| 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | |conf get invoker | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | |conf get performer | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | |conf set invoker | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | |conf set performer | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | |set invoker | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1 | 0 | |set performer | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1 | |conf action invoker| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | |conf action prfrmer| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | |action invoker | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | |action performer | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | |conf create invoker| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | |conf create prfrmer| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | |conf delete invoker| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | |conf delete prfrmer| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | |multiple reply | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | |mult obj selection | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | |extended service | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ------------------------------------------------------------------------ Table 10. Functional Unit Groups and their Functional Units Warrier [Page 31] Request For Comments: CMOT Draft Warrier 7.4.2.1.4 User Information The user information parameter is optional, and this memo does not mandate its use. However, it is pointed out that this parameter can be used to convey information describing MIB extensions supported by the manager and agent in the following fashion: The user information parameter could be a list of OBJECT IDENTIFIERs indicating additional MIB objects that are supported by identifying the root of the subtree naming those objects. RFC 1065 defines an object naming tree that includes private and experimental subtrees. Furthermore, there is an enterprises subtree under private that allows various organizations to register private objects. The likely use for this parameter is to make it possible for both the manager and agent to inform each other what additional MIB objects are supported without unnecessary probing using CMIP. This can be viewed as a further way of refining the application context. 7.4.2.1.5 Access Control Access control fields inside CMIP PDUs need to be accepted, but not to be checked, i.e., receiving an access control field should not cause an error, but the receiving entity is free to throw away (i.e. not check) the contents of the field itself. Access control via the ACSE is supported (refer ACSE section). It is recommended (but not required) that the access control parameter be used for each A-ASSOCIATE request. It is further recommended that access control not be used for individual CMIS requests. An application entity receiving a CMIS indication with an access control parameter is free to ignore this information, but may make use of it. The Access Control part of the ACSE User Information field is defined as an OCTET STRING (see section 7.5.3.4.3). It is intended to represent some form of password. The value of this password is determined by a prior agreement between the manager and agent. It is expected that in the normal case all agents in a given domain [how is domain defined?] will share the same password, or set of passwords. It is possible that more than one password will be used to access objects on a given agent. The reason for this is to provide some granularity with respect to access rights. One password might indicate read privilege on a subset of MIB objects; another might indicate read privilege on all MIB objects; and yet another might indicate read-write privilege on all MIB objects (subject, of course, to the restrictions imposed by the MIB definition). This implies that an association may have been accepted for a certain level of access rights (say read-only), and yet a particular request on that association may be rejected due to insufficient access rights (say if it is a set request). The agent will determine what level of access will be granted when no password is provided. The Access Control parameter is optional. Warrier [Page 32] Request For Comments: CMOT Draft Warrier An AccessControl field is also available in each CMIP Protocol Data Unit (PDU). Such a field could be used to implement security via Communities of Interest as in SNMP, for example. Other security architectures are being worked on in ISO. This area will be the subject of future study and standardization. 7.4.2.2 Management Information Services 7.4.2.2.1 Time related parameters All Event related Time parameters are supported using the syntax of ASN.1 UTC Type with 1 millisecond granularity. 7.4.2.2.2 InvokeId An should be sent by the Invoker, but the absence of this parameter should not be used as the basis for the rejection of a request by a Performer. Subsequent invocations along an association should have a unique invoke id. Invoke ids monotonically increase during the lifetime of the association. The wrap issue for counters supporting such an invoke id shall be dealt with exactly as other counters are implemented in the associated Management Information Base. 7.4.2.2.3 CMISSync Only the default value of "bestEffort" need be supported. 7.4.2.2.4 Reply PDUs For all PDUs that are replies to CMIP queries, anagedObjectClass and managedObjectInstance shall always be returned to identify the managed object and currentTime shall be returned, where appropriate, to identify the time at which the reply occurred. Warrier [Page 33] Request For Comments: CMOT Draft Warrier 7.4.2.2.5 Filtering For CMISFilter, only two instances of the binary operators ("and" and "or") are guaranteed to be supported, if at all filtering is supported. String operations (e.g. \fIsubstring\fP) need not be supported, but the arithmetic operations (e.g. "greaterthan") must be supported. Double "not"s are not supported. Thus the restricted definition of FilterItem becomes: FilterItem ::= CHOICE { equality [0] AttributeValueAssertion, greaterOrEqual [2] AttributeValueAssertion, lessOrEqual [3] AttributeValueAssertion, present [4] AttributeID} 7.4.2.2.6 Scoping If scoping is supported, all values of scope shall be supported. 7.4.2.3 Protocol related naming agreements 7.4.2.3.1 Object Class The object Class field of the CMIP PDU shall be limited to the globalForm choice only. objectClass ::= CHOICE { globalForm [0] IMPLICIT OBJECT IDENTIFIER } 7.4.2.3.2 Object Instance The Object Instance field of the CMIP PDU is limited to the distinguishedName choice only: objectInstance ::= CHOICE { distinguishedName [2] IMPLICIT DistinguishedName } Where DistinguishedName is defined as: DistinguishedName ::= RDNSequence RDNSequence::= [APPLICATION 1] SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= SEQUENCE OF AttributeValueAssertion AttributeValueAssertion:: = SEQUENCE {AttributeType, AttributeValue} AttributeType ::= Object Identifier AttributeValue ::= ANY -- defined by attribute type Those attributes to be used as the distinguishing attributes of a managed object class are defined at the time of registration of the managed object and are identified in the NAMES clause of an OBJECT-CLASS macro, for example. Warrier [Page 34] Request For Comments: CMOT Draft Warrier In cases where the Object Instance is to be coveyed as NULL, the Instance will be specified as: objectInstance ::= CHOICE { distinguishedName [2] IMPLICIT DistinguishedName } DistinguishedName ::= RDNSequence RDNSequence::= [APPLICATION 1] SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= SEQUENCE OF NULL 7.4.2.3.3 Attribute identification Attributes are specified in the attributeList. Both local and global forms of the id are permitted: attributeList ::= SET OF Attribute Attribute ::= SEQUENCE { attributeId AttributeId, attributeValue AttributeValue } AttributeId ::= CHOICE { globalId [0] IMPLICIT OBJECT IDENTIFIER localId [1] IMPLICIT INTEGER } AttributeValue ::= ANY DEFINED BY attributeId 8. THIN PRESENTATION LAYER 8.1 Introduction The "thin" Presentation Layer is a NetMan defined layer that takes the place of the OSI Presentation Layer, such that it can run on top of TCP or UDP, rather than an OS transport like TP-4. In OSI, the presentation layer is concerned with the representation of information in transit between open systems. An application (layer) protocol is specified in terms of the transfer of application layer protocol data units (APDUs) between application entities. A set of APDU type definitions associated with an application protocol constitutes an \fIabstract syntax\fH. Given a set of abstract syntaxes to be used by cooperating application entities, the presentation layer entities are responsible for selecting mutually acceptable "transfer syntaxes". The presentation layer provides for the negotiation of transfer syntaxes with the presentation protocols. In addition to negotiating transfer syntaxes and transforming to and from transfer syntaxes, the presentation layer supports the pass-through session layer services provided by the respective session subsets. Warrier [Page 35] Request For Comments: CMOT Draft Warrier The Thin Presentation Layer, on the other hand, provides a limited presentation capability. It restricts the transfer syntax to always be ASN.1, and hence does NOT provide for transfer syntax negotiation. It restricts the abstract syntax also to be ASN.1, so that there is no translation involved at the presentation layer between the transfer and abstract syntax, as is common in a "full" presentation. 8.2 Thin Presentation Services Kernel ISO presentation services defined in ISO 8822 [11] are supported. Table 11 lists the relevant presentation services for the thin presentation functional unit and the related PPDUS. ----------------------------------------------------------- | Presentation | Presentation | Related | | Functional Unit | Primitive | PPDU | |=====================|====================|==============| | Kernel | P-CONNECT | CP, CPA, CPR | | | P-DATA | TD | | | P-RELEASE | | | | P-U-ABORT | ARU | | | P-P-ABOR | ARP | ----------------------------------------------------------- Table 11. Presentation Services The following requirements in addition to those specified in ISO DIS 8823 apply: - Normal Mode (non-X.410 mode) shall be supported. - Full encoding of user data shall be used in all cases. - Only the following transfer syntax shall be supported: { joint-iso-ccitt asn1 (1) basic-encoding (1) } This transfer syntax is the application of the basic encoding rules for ASN.1 [15]. 8.3 Presentation Layer Parameters 8.3.1 Presentation Context Identifier" The presentation context identifier shall be encoded in no more than two octets. 8.3.2 P-Selector P-Selectors shall have a maximum length of 4 octets. Warrier [Page 36] Request For Comments: CMOT Draft Warrier 8.3.3 Port numbers Presentation services are mapped on top of TCP/IP as in IDEA017, and the following well-known TCP port numbers shall be used for CMIS over TCP/IP: cmot manager : 163 cmot agent : 164 The resolution of addresses is specified in Section 10.0 of the memo, "ISO Presentation Services on top of TCP/IP-based internets" (IDEA 17) [9]. 9. TRANSPORT LAYER 9.1 Introduction The purpose of the transport layer is to provide transparent transfer of data between users of the transport service. It relieves transport service users from concern about the detailed way in which supporting networks are used to achieve data transfer. 9.2 "Services Required of Network Layer" The underlying network service shall conform to the Internet Protocol [IP] connectionless mode network service. 9.3 Classes of Transport Protocol While there is only a single transport service defined, two classes of transport protocol (TCP and UDP) are defined, the complete CMOT protocol suite supports the following classes: - TCP (Error Detection, Connection Setup and Recovery Class over ConnectionlessOriented Network Service): this is the most flexible and robust class defined. It provides a comprehensive set of procedures for detection and recovery from both signalled and residual errors. - UDP (Error Detection and Recovery Class over Connectionless Network Service): this provides confirmed connection establishment, but unreliable data transfer. 9.4 Transport Services for CMOT The CMOT transport layer classes shall provide transport service users with services identical to those specified in RFC 793 (TCP) [3] and RFC 768 (UDP) [1]. Warrier [Page 37] Request For Comments: CMOT Draft Warrier 10. References [1] RFC768 - User Datagram Protocol, J. Postel, 1980. [2] RFC791 - Internet Protocol, J. Postel, 1980. [3] RFC793 - Transmission Control Protocol, J. Postel, 1980. [4] RFC1052 - IAB Recommendations for the Development of Internet Network Management Standards, V. Cerf, 1988. [5] RFC1065 - Structure and Identification of Management Information for TCP/IP-based internets, M. Rose and K. McCloghrie, 1988. [6] RFC1066 - Management Information Base for Network Management of TCP/IP-based internets, K. McCloghrie and M. Rose, 1988. [7] RFC1067 - A Simple Network Management Protocol, J. Case et al, 1988. [8] IDEA012 - Network Management for TCP/IP Networks: An Overview, A. Ben-Artzi, 1988. [9] IDEA017 - ISO Presentation Services on Top of TCP/UDP, M. Rose, 1988. [10] ISO DIS 7498/4: Information Processing Systems - Open Systems Interconnection - Basic Reference Model Part 4 - OSI Management Framework. [11] ISO 8822: Information Processing Systems - Open Systems Interconnection - Connection Oriented Presentation Service Definition. June 1987. [12] ISO 8823: Information Processing Systems - Open Systems Interconnection - Connection Oriented Presentation Protocol Definition. June 1987. [13] ISO 8824: Information Processing - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1). May 19, 1987. [14] ISO/ TC 97/SC 21/N 1968: Extensions to ASN.1 - PDAD1 to ISO 8824. July 22, 1987. [15] ISO 8825: Information Processing - Open Systems Interconnection - Specification of basic encoding rules for Abstract Syntax Notation One (ASN.1). May 19, 1987. [16] ISO 8649: Information Processing Systems - Open Systems Interconnection - Service Definition for Common Application Service Elements - Part 2: Association Control. [17] ISO 8650: Information Processing Systems - Open Systems Interconnection - Protocol Specification for Common Application Service Elements - Part 2: Association Control. Warrier [Page 38] Request For Comments: CMOT Draft Warrier [18] ISO 8073: Information Processing Systems - Open Systems Interconnection - Connection Oriented Transport Protocol Specification, 1986. [19] ISO 8073/DAD 2: Information Processing Systems - Open Systems Interconnection - Connection Oriented Transport Protocol Definition. Addendum 2: Class Four Operation over Connectionless Network Service,1988. [20] ISO DIS 9071: Information Processing Systems - Open Systems Interconnection - (CCITT Recommendation X.219) Remote Operations: Model, Notation and Service Definition. [21] ISO DIS 9072: Information Processing Systems - Open Systems Interconnection - (CCITT Recommendation X.229) Remote Operations: Protocol Specification. [22] ISO DP 9534: Information Processing Systems - Open Systems Interconnection - Application Layer Structure, March 10, 1987. [23] ISO DIS 9595-2: Information Processing Systems - Open Systems Interconnection - Management Information Service Definition - Part 2: Common Management Information Service, November, 1988. [24] ISO DIS 9596-2: Information Processing Systems - Open Systems Interconnection - Management Information Protocol Definition - Part 2: Common Management Information Protocol, November, 1988. [25] Steedman, Doug. "ROS -- The Remote Operations Service", Open Systems Data Transfer (Omnicom, Inc.), Transmission #26, February 1987. Warrier [Page 39] Request For Comments: CMOT Draft Warrier APPENDIX A - Management Information Summary The management information for CMOT is defined in RFC 1066 which defines the objects in the MIB (Management Information Base). The RFC defines all elements as "OBJECTS", some of which are complex. CMIP defines elements in a hierarchical manner where complex elements are defined as "managed objects" which are made up of simple elements called "attributes". There is a mapping of the "OBJECTS" in RFC1066 to managed objects and attributes needed to define CMIP exchanges. The Object Identifiers assigned to these "OBJECTS" remain the same. The change here is a "protocol-dependent" (in the sense of RFC1065) way of addressing the same information. Such a set of managed object classes and attributes is given below. The identifiers given for the object classes and the attributes are those assigned in RFC1066. Notice that certain attributes have "moved" to the system object. The Distinguished Name is defined as a sequence of {class, attribute} where the values of those attributes would uniquely identify a member of the specified object class. A.1 The System Group Managed Object: --------------- system { mib 1 } Distinguished Name: {{{system, SysObjectId}}} Attributes: sysDescr (1) sysObjectId (2) sysUpTime (3) Warrier [Page 40] Request For Comments: CMOT Draft Warrier A.2 The Interfaces Group Managed Object: --------------- interfaces { mib 2 } Distinguished Name: {{{system, SysObjectId}}} Attributes: ifNumber (1) ifTable (2) Managed Object: --------------- ifTable { interfaces 2 } Distinguished Name: {{{system, SysObjectId}}} Attributes: (none) Managed Object: --------------- ifEntry { ifTable 1 } Distinguished Name: {{{system, SysObjectId}, {ifEntry, IfIndex}}} Attributes: ifIndex (1) ifDescr (2) ifType (3) ifMtu (4) ifSpeed (5) ifPhysAddress (6) ifAdminStatus (7) ifOperStatus (8) ifLastChange (9) ifInOctets (10) ifInUcastPkts (11) ifInNUcastPkts (12) ifInDiscards (13) ifInErrors (14) ifInUnknownProtos (15) ifOutOctets (16) ifOutUcastPkts (17) ifOutNUcastPkts (18) ifOutDiscards (19) ifOutErrors (20) ifOutQLen (21) Warrier [Page 41] Request For Comments: CMOT Draft Warrier A.3 The Address Translation Group Managed Object: --------------- at { mib 3 } Distinguished Name: {{{system, SysObjectId}}} Attributes: atTable (1) Managed Object: --------------- atTable { at 1 } Distinguished Name: {{{system, SysObjectId}}} Attributes: (none) Managed Object: --------------- atEntry { atTable 1 } Distinguished Name: {{{system, SysObjectId}, {atEntry, AtIfIndex}}} Attributes: atIfIndex (1) atPhysAddress (2) atNetAddress (3) A.4 The IP Group Managed Object: --------------- ip { mib 4 } Distinguished Name: {{{system, SysObjectId}}} Attributes: ipForwarding (1) ipDefaultTTL (2) ipInReceives (3) ipInHdrErrors (4) ipInAddrErrors (5) ipForwDatagrams (6) ipInUnknownProtos (7) ipInDiscards (8) ipInDelivers (9) ipOutRequests (10) ipOutDiscards (11) ipOutNoRoutes (12) Warrier [Page 42] Request For Comments: CMOT Draft Warrier ipReasmTimeout (13) ipReasmReqds (14) ipReasmOKs (15) ipReasmFails (16) ipFlagOKs (17) ipFlagFails (18) ipFlagCreates (19) ipAddrTable (20) ipRoutingTable (21) Managed Object: --------------- ipAddrTable { ip 20 } Distinguished Name: {{{system, SysObjectId}}} Attributes: (none) Managed Object: --------------- ipAddrEntry { ipAddrTable 1 } Distinguished Name: {{{system, SysObjectId}, {ipAddrEntry, IpAdEntAddr}}} Attributes: ipAdEntAddr (1) ipAdEntIfIndex (2) ipAdEntNetMask (3) ipAdEntBcastAddr (4) Managed Object: --------------- ipRoutingTable { ip 21 } Distinguished Name: {{{system, SysObjectId}}} Attributes: (none) Managed Object: --------------- ipRoutingEntry { ipRoutingTable 1 } Distinguished Name: {{{system, SysObjectId}, {ipAddrEntry, IpAdEntAddr}}} Warrier [Page 43] Request For Comments: CMOT Draft Warrier Attributes: ipRouteDest (1) ipRouteIfIndex (2) ipRouteMetric1 (3) ipRouteMetric2 (4) ipRouteMetric3 (5) ipRouteMetric4 (6) ipRouteNextHop (7) ipRouteType (8) ipRouteProto (9) ipRouteAge (10) A.5 The ICMP Group Managed Object: --------------- icmp { mib 5 } Distinguished Name: {{{system, SysObjectId}}} Attributes: icmpInMsgs (1) icmpInErrors (2) icmpInDestUnreachs (3) icmpInTimeExcds (4) icmpInParmProbs (5) icmpInSrcQuenchs (6) icmpInRedirects (7) icmpInEchos (8) icmpInEchoReps (9) icmpInTimestamps (10) icmpInTimestampReps (11) icmpInAddrMasks (12) icmpInAddrMaskReps (13) icmpOutMsgs (14) icmpOutErrors (15) icmpOutDestUnreachs (16) icmpOutTimeExcds (17) icmpOutParmProbs (18) icmpOutSrcQuenchs (19) icmpOutRedirects (20) icmpOutEchos (21) icmpOutEchoReps (22) icmpOutTimestamps (23) icmpOutTimestampReps (24) icmpOutAddrMasks (25) icmpOutAddrMaskReps (26) Warrier [Page 44] Request For Comments: CMOT Draft Warrier A.6 The TCP Group Managed Object: --------------- tcp { mib 6 } Distinguished Name: {{{system, SysObjectId}}} Attributes: tcpRtoAlgorithm (1) tcpRtoMin (2) tcpRtoMax (3) tcpMaxConn (4) tcpActiveOpens (5) tcpPassiveOpens (6) tcpAttemptFails (7) tcpEstabResets (8) tcpCurrEstab (9) tcpInSegs (10) tcpOutSegs (11) tcpRetransSegs (12) tcpConnTable (13) Managed Object: --------------- tcpConnTable { tcp 13 } Distinguished Name: {{{system, SysObjectId}}} Attributes: (none) Managed Object: --------------- tcpConnEntry { tcpConnTable 1 } Distinguished Name: {{{system, SysObjectId}, {tcpConnEntry, TcpConnAddr}}} TcpConnAddr ::= SEQUENCE {tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, tcpConnRemPort} Attributes: tcpConnState (1) tcpConnLocalAddress (2) tcpConnLocalPort (3) tcpConnRemAddress (4) tcpConnRemPort (5) Warrier [Page 45] Request For Comments: CMOT Draft Warrier A.7 The UDP Group Managed Object: --------------- udp { mib 7 } Distinguished Name: {{{system, SysObjectId}}} Attributes: udpInDatagrams (1) udpNoPorts (2) udpInErrors (3) udpOutDatagrams (4) A.8 The EGP Group Managed Object: --------------- egp { mib 8 } Distinguished Name: {{{system, SysObjectId}}} Attributes: egpInMsgs (1) egpInErrors (2) egpOutMsgs (3) egpOutErrors (4) egpNeighTable (5) Managed Object: --------------- egpNeighTable { egp 5 } Distinguished Name: {{{system, SysObjectId}}} Attributes: (none) Managed Object: --------------- egpNeighEntry { egpNeighTable 1 } Distinguished Name: {{{system, SysObjectId}, {egpNeighEntry, EgpNeighAddr}}} Attributes: egpNeighState (1) egpNeighAddr (2) Warrier [Page 46]