RFC 1095
Common Management Information Services and Protocol over TCP/IP (CMOT)
RFC 1095: The Common Management Information Services and Protocol over TCP/IP (CMOT) 🎀
Okay bestie, here's the title block. 💅
Written by U. Warrier (Unisys Corporation) and L. Besaw (Hewlett-Packard) 👩💻✨
Dated April 1989 📅
Category/status: the IAB put CMOT and SNMP in the same "Draft Standard" and "Recommended" bucket 🔥
Obsoletes and updates: this header doesn't list anything it obsoletes or updates 🤷♀️
Network Working Group, Request for Comments 1095 🦋
Table of Contents 🌸
Table of Contents
1. Status of this Memo ............................................ 3
2. Introduction ................................................... 4
Part I: Concepts and Models ....................................... 7
3. The OSI Management Framework ................................... 7
3.1. Architectural Overview ....................................... 7
3.2. Management Models ............................................ 8
3.2.1. The Organizational Model ................................... 8
3.2.2. The Functional Model ....................................... 8
3.2.3. The Information Model ...................................... 9
3.3. ISO Application Protocols .................................... 9
3.3.1. ACSE ....................................................... 10
3.3.2. ROSE ....................................................... 10
3.3.3. CMISE ...................................................... 10
3.3.3.1. Management Association Services .......................... 11
3.3.3.2. Management Notification Services ......................... 12
3.3.3.3. Management Operation Services ............................ 12
4. The CMOT Architecture .......................................... 13
4.1. Management Models ............................................ 13
4.1.1. The Organizational Model ................................... 13
4.1.2. The Functional Model ....................................... 14
4.1.3. The Information Model ...................................... 14
4.2. Protocol Architecture ........................................ 14
4.2.1 The Lightweight Presentation Layer .......................... 15
4.2.2 The Quality of Transport Service ............................ 16
4.3. Proxy Management ............................................. 17
4.4. Directory Service ............................................ 18
5. Management Information ......................................... 18
5.1. The Structure of Management Information ...................... 19
5.1.1. The ISO SMI ................................................ 19
5.1.1.1. Managed Objects and Attributes ........................... 19
5.1.1.2. Management Information Hierarchies ....................... 20
5.1.1.2.1 The Registration Hierarchy .............................. 20
5.1.1.2.2. The Containment Hierarchy .............................. 20
5.1.1.2.3. The Inheritance Hierarchy .............................. 22
5.1.2. The Internet SMI ........................................... 22
5.2. The Management Information Base .............................. 23
5.3. An Interpretation of the Internet SMI ........................ 24
5.3.1. Object Class and Attributes ................................ 25
5.3.1.1. Object Class ............................................. 25
5.3.1.2. Attribute Identifier ..................................... 26
5.3.2. Management Information Hierarchies ......................... 26
5.3.2.1. The Registration Hierarchy ............................... 26
5.3.2.2. The Containment Hierarchy ................................ 26
5.3.2.3. The Inheritance Hierarchy ................................ 28
5.4. Scoping, Filtering, and Synchronization ...................... 28
5.4.1. Scoping .................................................... 28
5.4.2. Filtering .................................................. 29
5.4.3. Synchronization ............................................ 29
5.4.4. Linked Replies ............................................. 29
5.5. Accessing Tables ............................................. 29
5.5.1. Accessing Whole Tables ..................................... 30
5.5.2. Accessing Table Entries .................................... 30
Part II: Protocol Agreements ...................................... 32
6. CMOT Protocol Overview ......................................... 32
6.1. The CMOT Protocol Suite ...................................... 32
6.2. Conformance Requirements ..................................... 33
6.3. Abstract Syntax Notation ..................................... 33
7. Common Management Information Service Element .................. 34
7.1. CMIS Services ................................................ 34
7.1.1. CMIS Services Overview ..................................... 34
7.1.2. Functional Units ........................................... 34
7.1.3. Functional Unit Groups ..................................... 36
7.1.4. M-INITIALISE Parameters .................................... 37
7.1.4.1. Functional Units ......................................... 37
7.1.4.2. User Information ......................................... 39
7.1.4.3. Access Control ........................................... 39
7.2. Supporting Services .......................................... 39
7.3. CMIP Agreements .............................................. 39
7.3.1. Invoke Identifier .......................................... 39
7.3.2. Object Class ............................................... 40
7.3.3. Object Instance ............................................ 40
7.3.4. Access Control ............................................. 41
7.3.5. Synchronization ............................................ 41
7.3.6. Scope ...................................................... 41
7.3.7. Filter ..................................................... 41
7.3.8. Attribute Identifier ....................................... 42
7.3.9. Event Type Identifier ...................................... 42
7.3.10. Action Type Identifier .................................... 42
7.3.11. Time Fields ............................................... 43
7.3.12. Response PDUs ............................................. 43
7.3.13. Error PDUs ................................................ 43
8. Association Control Service Element ............................ 43
8.1. ACSE Services ................................................ 44
8.2. Supporting Services .......................................... 44
8.3. ACSE Protocol ................................................ 45
8.3.1. Application Context Name ................................... 45
8.3.2. User Information ........................................... 45
8.3.3. Presentation Service Parameters ............................ 46
9. Remote Operations Service Element .............................. 46
9.1. ROSE Services ................................................ 46
9.2. Supporting Services .......................................... 47
9.3. ROSE Protocol ................................................ 47
9.3.1. Operation Class ............................................ 47
9.3.2. Priority ................................................... 48
10. Lightweight Presentation ...................................... 48
10.1. Lightweight Presentation Services ........................... 48
10.2. Supporting Services ......................................... 48
10.3. Lightweight Presentation Protocol ........................... 49
11. Acknowledgements .............................................. 49
12. References .................................................... 49
Appendix A - The CMOT Group ....................................... 52
Appendix B - Management Information Summary ....................... 53
Appendix C - Sample Protocol Exchanges ............................ 601. Status of this Memo ✨
Okay so this memo defines a network management architecture that uses the ISO's CMIS/CMIP in a TCP/IP environment 🌈 Basically, it's a way for a manager and a remote network element to swap control and monitoring info back and forth. Iconic. 💅
The main move here is spelling out how to run the Draft International Standard (DIS) version of CMIS/CMIP on top of Internet transport protocols, so it can carry management info defined in the Internet-standard management information base. DIS CMIS/CMIP is already deployable on TCP/IP networks, even while CMIS/CMIP is still on its way to becoming an International Standard 🚀
Put it all together with the relevant ISO standards and the companion RFCs that describe the initial structure of management information and the management information base, and you get a full architecture and system for managing TCP/IP-based internets, the Internet itself very much included 🌸
The Internet Activities Board (IAB) gave two different network management protocols the same status: "Draft Standard" and "Recommended" 👑
Those two are CMOT (this memo!) and the Simple Network Management Protocol (SNMP) [4] 🦋
The IAB wants both of these protocols to get attention from implementers and experimenters, and it's actively asking system builders and users to send in reports of their experience with them 🫶
Then the IAB basically recommends that all IP and TCP implementations be network manageable (e.g., implement the Internet MIB [3]), and that network manageable implementations adopt and implement at least one of these two Internet Draft Standards 💜 Lowkey a big deal.
Distribution of this memo is unlimited 🎀
More parts are coming, so stay tuned bestie 🧚
2. Introduction ✨
okay so bestie, RFC 1052 ("IAB Recommendations for the Development of Internet Network Management Standards") [1] is the origin story 🌸. The Internet Activities Board (IAB) told the Internet Engineering Task Force (IETF) to coordinate three working groups for network management, and it's giving main character energy 💅. The MIB working group was in charge of specifying and defining the elements that go into the Management Information Base (MIB). The SNMP working group was tasked with changing the Simple Network Management Protocol (SNMP) so it could handle the short-term needs of network vendors and operations teams 🎀. The Netman working group got the long-term mission: build a network management system based on ISO CMIS/CMIP 🔥. Netman and SNMP both had to line up their work with the MIB group's output so the management info matched across the short-term and long-term approaches for managing TCP/IP-based internets. That's the whole point, because it means a smooth glow-up from SNMP (short-term) to CMIP (long-term) ✨.
The MIB working group has put out two memos. RFC 1065 [2] defines the Structure of Management Information (SMI), which is the thing you need for naming and defining managed objects in the MIB 🧚. RFC 1066 [3] lists the managed objects in the initial TCP/IP MIB. The SNMP working group wrote a memo [4] with the SNMP protocol spec, plus an SNMP-specific reading of the Internet-standard MIB from RFC 1066 🍓.
This memo is the Netman working group's output 💜. Following the IAB's direction in RFC 1052, it tackles the need for a long-term network management system built on ISO CMIS/CMIP. Using ISO protocols inside a TCP/IP environment to manage TCP/IP networks is called "CMIP Over TCP/IP" (CMOT) 🦋. This memo lays out the CMOT architecture and the protocol agreements you need to implement CMIP and its companion ISO protocols over the TCP and UDP transport protocols. It also gives an interpretation of RFC 1066 so CMIP can carry the management info defined in the Internet-standard MIB 🫶.
Vendor support for CMOT is seriously strong 😭. The Netman group showed prototype CMOT implementations at the Interop '88 TCP/IP Interoperability Conference, and the demo proved that the CMIS/CMIP framework is feasible and powerful for multivendor network management 🌈. CMIS/CMIP has been voted a Draft International Standard (DIS), and lots of vendors feel the ISO standard is now a stable base for building products 👑. Because people clearly need this standardized, the current profile of CMIP came out of it. The profile is expected to stay the same while the ISO standard moves from DIS status to International Standard (IS) status. If the standard changes unexpectedly anyway, the Netman working group will review those changes and decide what to do 🙈.
There's another reason for CMOT too 💖. It helps the ISO network management standards get used early in big operational networks. That lets the Internet community send useful recommendations to ISO, written in the language of OSI management and based on real experience using and implementing these standards. ISO is still working on network management standards, and contributions like these would be valuable there 🧚.
The CMOT architecture is based on the Open Systems Interconnection (OSI) management framework and the models ISO developed 🎀. This memo has a set of protocol agreements for building a network management system on that architecture. The protocol agreement sections must be read alongside the ISO and Internet documents that define the specific protocol standards 📖. Implementors are required to have the documents for the following ISO standards: 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 lightweight presentation layer protocol used in this profile 💅. RFC 1065 [2] and RFC 1066 [3] are also required, since they define the initial SMI and MIB used with the CMOT management system 💜.
This memo is split into two main parts 🦋. The first part covers concepts and models, and the second part has the protocol agreements you need to implement the CMOT network management system. The first part has three sections: section 3 is a tutorial on the OSI management framework, section 4 defines the basic CMOT approach, and section 5 covers management information and explains how the abstract management information defined in the Internet-standard SMI and MIB maps into CMIP 🌸. The second part has a section for each protocol that needs implementor agreements: CMISE, ACSE, ROSE, and the lightweight presentation protocol 🔥. The profile 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), which used to be called the National Bureau of Standards 🌈. Wherever it was possible, the authors tried to stay consistent with the protocol agreements those groups reached ✨.
Part I: Concepts and Models 🌈
3. The OSI Management Framework
okay this is the tutorial bit and it's actually so cute 🧚. The OSI management framework [15] lays out the basic concepts and models you need for developing network management standards 💖. OSI management lets you monitor and control network resources, which are represented as "managed objects" 🎀. To describe a network management architecture and standardize a network management system, you need these essentials: a model (or set of models) for understanding management, a common structure of management information for registering, identifying, and defining managed objects, detailed specs for the managed objects themselves, and a set of services and related protocols for doing remote management operations 💅.
3.1. Architectural Overview
the basic concepts behind OSI network management are honestly simple [16] 🦋. There are application processes called "managers" running on managing systems (also called management stations). There are application processes called "agents" running on managed systems (the network elements being managed) 🌸. Network management happens when managers and agents work together, using protocols and a shared conceptual schema, to swap monitoring and control info that's useful for managing a network and its parts 🫶. The words "manager" and "agent" also get used loosely to mean the managing system and the managed system, respectively 💜.
The shared conceptual schema is basically the a priori knowledge about "managed objects" that the info gets exchanged about 🔥. Managed objects are system and networking resources (for example, a modem, a protocol entity, an IP routing table, or a TCP connection) that can be managed 🌈. Management happens by manipulating managed objects on the managed systems ✨. Using the management services and protocol, the manager can tell the agent to do something to a managed object the agent is responsible for 👑. That something can be returning values tied to a managed object (reading a variable), changing values tied to it (setting a variable), or running an action on it, like a self-test 🙈. The agent can also pass along notifications that managed objects generate asynchronously, which are called events or traps 🧚.
The terms "manager" and "agent" describe an asymmetric relationship between management application processes, where the manager is the superior and the agent is the subordinate 🎀.
But here's the twist 💅. The management protocol (CMIP) defines a peer protocol relationship, and it makes no assumptions about which end opens or closes a connection or which direction the management data flows 🦋. The protocol mechanisms are fully symmetric between manager and agent, so CMIS operations can start at either the manager or the agent, as far as the protocol is concerned 😭. That means you can have symmetric relationships as well as asymmetric ones 🌸. Most devices will have management applications that can only play the agent role 💖. Applications on managing systems, though, may be able to play both roles at once 🌈. That's what makes "manager to manager" communication possible, along with one manager managing another manager 👑.
3.2. Management Models
Network management can be modeled in different ways 💜. Three models are typically used to describe OSI management [17, 18] 🔥. The organizational model describes the ways management can be distributed administratively 🫶. The functional model describes the management functions and how they relate to each other 🌸. The information model gives guidelines for describing managed objects and their associated management information ✨.
3.2.1. The Organizational Model
The organizational model introduces the idea of a management "domain" 🧚. A domain is an administrative partition of a network or internet, made for the purpose of network management 🎀. Domains can be handy for reasons of scale, security, or administrative autonomy 💅. Each domain may have one or more managers monitoring and controlling the agents in that domain 🦋. Managers and agents can also belong to more than one management domain 🌈. Domains make it possible to build both strict hierarchical systems and fully cooperative, 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 🌸. Splitting the network management problem up this way has turned out to be really helpful from an application point of view 💖. These facilities are known as the Specific Management Functional Areas (SMFAs) 🔥: fault management, configuration management, performance management, accounting management, and security management 💜. Fault management gives you the ability to detect, isolate, and correct network problems 🙈. Configuration management lets network managers change the configuration of remote network elements 🎀. Performance management provides the tools to monitor and evaluate network performance 🧚. Accounting management makes it possible to charge users for the network resources they use, and to limit how much they use 💅. And security management is about managing access control, authentication, encryption, key management, and so on 🫶.
3.2.3. The Information Model 🧠✨
okay so the OSI Management Framework says ALL the info that's relevant to network management lives in one place called a Management Information Base (MIB) 📚. It's a "conceptual repository of management information," which is a very fancy way of saying a big organized storage spot for network info 💅. Anything inside a system that the management protocol (CMIP) can reference counts as part of the MIB 🫶. There are also conventions for describing and uniquely identifying that MIB info, so the management protocol can point at a specific piece and actually do stuff with it. Those conventions are called the Structure of Management Information (SMI) 🎀. We'll get the full tea on the information model in section 5 🦋.
3.3. ISO Application Protocols 🌸
the ISO application services and protocols you need for network management in the OSI framework are ACSE, ROSE, and CMIS/CMIP 💖. All three are defined using ASN.1 [5] 🧚. The ASN.1 modules for each one live in the relevant standards documents 📄. And the encoding rules for ASN.1 [6] give you a machine-independent network representation for data, which is giving "works on any computer" energy 🌈.
A quick overview of the application layer vocab is coming up here. The full deal is in the OSI Application Layer Structure document [22] 📖.
In OSI land, when "application processes" talk to each other, it's modeled as their application entities talking 💬. An "application entity" is basically the communication stuff of an application process 🫶. An application process can have more than one set of OSI communication functions, so one process might show up as multiple application entities 👯♀️. BUT each application entity only ever represents ONE application process 🙅♀️. An application entity has a bundle of communication capabilities called "application service elements." An application service element is a coherent set of integrated functions 💅. You can use them on their own or mix them together 🍓. Examples include X.400, FTAM, ACSE, ROSE, and CMISE ✨.
When two application entities need to communicate, one or more "application associations" get set up between them 🤝. You can think of an association like a connection at the application layer 🦋. An "application context" defines the set of application service elements that the user of an application association is allowed to invoke 👑. It can prescribe one or more application service elements 💜.
Generally, an "application layer protocol" gets built using a bunch of application service elements working together 🔥. That functionality comes from a set of application protocol data units (APDUs) plus the procedures for how to use them 📦. An application layer protocol might need a mix of APDUs from different application service elements, which is totally normal 🙈. The application entity uses presentation context identifiers directly to specify and identify APDUs 🧚♀️.
3.3.1. ACSE 🤍
The Association Control Service Element (ACSE) is what sets up and tears down associations between application entities 🔗. Before any CMIP management operations can happen, the two application entities involved have to form an association first 💅. Either the manager or the agent can kick off association establishment 🙌. During this, ACSE lets the manager and agent swap application entity titles so they can identify each other, plus application context names so they can set up an application context ✨. Like we said before, an application context defines which service elements (ROSE and CMISE, for instance) can be used over the association 🎀. Once the association is up, ACSE stays out of the way until the manager or agent releases the association 😌.
3.3.2. ROSE 🎯
The Remote Operation Service Element (ROSE) is the ISO version of remote procedure call 📞. It lets you invoke an operation on a remote system 🌐. The Remote Operation protocol carries an invoke identifier (so requests and responses can be matched up), an operation code, and an argument field for the parameters that are specific to the operation 🧩. ROSE can only be invoked after an application association has been established 🚪. CMIP uses ROSE's transaction-oriented services for all of its requests and responses 💌. CMIP also uses ROSE's error response facilities 😭.
3.3.3. CMISE 🌟
The Common Management Information Service Element (CMISE) is the service element that provides the basic management services 👑. CMISE is a user of both ROSE and ACSE 🫶. It provides both confirmed and unconfirmed services for reporting events and for retrieving and manipulating management data 📊. Manager and agent application entities use these services to swap management information 💜. Table 1 lists the CMISE services 📋. CMISE can also send 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 SummaryCMIS services split into two main classes: management association services and information transfer services 🗂️. Information transfer services come in two types: management notification services and management operation services 🧃. On top of all that, CMISE has facilities that let multiple responses to a confirmed operation get linked back to that operation using a linked identification parameter 🔗💖.
3.3.3.1. Management Association Services 🤝
CMIS provides services for setting up and releasing application associations 🚀. These services control how a management association gets established and how it gets released, both normally and abnormally 🫧. Honestly, these services are just pass-throughs to ACSE 🎀.
The M-INITIALISE service gets invoked by a CMISE-service-user to set up an association with a remote CMISE-service-user so they can swap management information 💬. A reply is expected 🙏. (Quick reminder: a CMISE-service-user is the part of an application process that makes use of CMISE 🧚.)
The M-TERMINATE service gets invoked by a CMISE-service-user to release an association with a remote CMISE-service-user in an orderly way 🌸. A reply is expected 💌.
The M-ABORT service gets invoked by a CMISE-service-user or a CMISE-service-provider to release an association with a remote CMISE-service-user in an abrupt way 💀.
3.3.3.2. Management Notification Services 🔔
How a notification is defined, and how the communicating entities behave because of it, depends on the managed object that generated the notification 👀. That part is outside the scope of CMIS 🙅♀️. CMIS does provide the following service for conveying management information that applies to notifications 💅.
The M-EVENT-REPORT service gets invoked by a CMISE-service-user to report an event about a managed object to a remote CMISE-service-user 📣. The service can be requested in confirmed or non-confirmed mode 🌈. In confirmed mode, a reply is expected 💖.
3.3.3.3. Management Operation Services ⚙️
How an operation is defined, and how the communicating entities behave because of it, depends on the managed object the operation is aimed at, and that's also outside CMIS's scope 🙈. BUT certain operations get used a lot in management, so CMIS gives definitions for the common services that can convey management information for those operations 💫.
The M-GET service gets invoked by a CMISE-service-user to request retrieval of management information from a remote CMISE-service-user 📥. It can only be requested in confirmed mode 🔒. A reply is expected 🙏.
The M-SET service gets invoked by a CMISE-service-user to request modification of management information by a remote CMISE-service-user ✏️. It can be requested in confirmed or non-confirmed mode 🌗. In confirmed mode, a reply is expected 💌.
The M-ACTION service gets invoked by a CMISE-service-user to ask a remote CMISE-service-user to perform an action 🎬. It can be requested in confirmed or non-confirmed mode 🌓. In confirmed mode, a reply is expected 🫶.
The M-CREATE service gets invoked by a CMISE-service-user to ask a remote CMISE-service-user to create another instance of a managed object 🐣. It can only be requested in confirmed mode 🔐. A reply is expected 💜.
The M-DELETE service gets invoked by a CMISE-service-user to ask a remote CMISE-service-user to delete an instance of a managed object 🗑️. It can only be requested in confirmed mode 🔐. A reply is expected 🥹.
4. The CMOT Architecture 🦋
the CMOT (CMIP Over TCP/IP) architecture is built on the OSI management framework [15] and on the models, services, and protocols ISO developed for network management 🏗️. It shows how the OSI management framework can be applied in a TCP/IP environment and used to manage objects on a TCP/IP network 🌐. Using ISO protocols to manage widely deployed TCP/IP networks will make it easier to eventually migrate from TCP/IP to ISO protocols 🚚. The architecture also introduces proxy management as a useful extension 💡. Proxy management lets you manage network elements that either can't be reached by an Internet address or that 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 the foundation for network management 🧱. A protocol-dependent interpretation of the Internet SMI [2] is used to define management information 📐. The Internet MIB [3] provides an initial list of managed objects 📋. Last but not least, a way is defined to use ISO management services and protocols on top of TCP/IP transport protocols 🔌. Management applications themselves are NOT in scope for the CMOT architecture 🙅♀️. What's standardized right now is the minimum needed to build 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 show how the CMOT architecture applies the OSI management models, and they point out any limitations the CMOT architecture has as currently defined in this memo 👀.
4.1.1. The Organizational Model ✨
Okay so this one is basically a scope check 🧐. It's beyond the scope of this memo to define the relations and interactions between different management domains. The current CMOT architecture only deals with the operations and characteristics of a single domain of management. Extending the mechanisms here to multiple domains is left for further study 🔭.
4.1.2. The Functional Model 💅
The CMOT architecture lays the foundation for management in the five functional areas (fault, configuration, performance, accounting, and security) 🎀. It doesn't spell out how any of those types of management actually get done though, so no spoilers there 🙈. It's anticipated that most functional requirements can be satisfied by CMIS. ngl the biggest impact of the functional requirements in each area will likely land on how managed objects get defined 🧚.
4.1.3. The Information Model 🌸
There are two different SMI specifications that matter a lot for the CMOT architecture 📚. The first is the SMI currently being defined by ISO [19]. This one is important because the ISO management protocol CMIP was designed with the ISO model of management information in mind 💜. The second is the SMI defined by the IETF MIB working group for use in defining the Internet MIB [3]. This Internet SMI is loosely based on a simplified version of the ISO SMI, and it matters because the managed objects defined for TCP/IP networks that CMOT uses are defined in terms of it 🦋. So to make the CMOT architecture complete, we have to show how the Internet SMI maps into CMIP so it can convey the management information defined in the Internet MIB. That gets covered in the section devoted to management information (section 5) ✨.
4.2. Protocol Architecture 👑
The goal of the CMOT protocol architecture is to map the OSI management protocol architecture into the TCP/IP environment 🌈. The model follows the OSI model at the application layer, but uses Internet protocols at the transport layer 🫶. The ISO application protocols used for network management are ACSE, ROSE, and CMIP. Instead of stacking these 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 works thanks to the lightweight presentation protocol defined in RFC 1085 [13], which maps ROSE and ACSE onto TCP/UDP/IP 🎀. The Internet transport protocols are totally transparent to network management applications, since those apps are still presented with real ISO services 💖.
4.2.1. The Lightweight Presentation Layer 🦋
So the big question is, if we want to run ISO application protocols on top of TCP/IP, how do we do it? We need to somehow 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 all the way down to the transport layer. The ISO Transport Protocol Class 0 (TP 0) then uses TCP instead of an ISO network protocol. Basically this treats TCP as a reliable network connection, kind of like X.25 📡. The upside is that it lets us run "standard" ISO applications over TCP no matter what their service requirements are, since all ISO services are provided. In this case, network management is just another one of those applications 💅. The major drawback is that full ISO presentation, session, and transport layers are expensive to implement, both in processing time and in memory 😭.
Another approach is presented in RFC 1085. Since the service elements needed for network management (ACSE, ROSE, CMISE) don't require full ISO presentation layer services, it's possible to define a "streamlined" presentation layer that only provides the services that are required ✨. This lightweight presentation protocol (LPP) lets you use ISO presentation services over both TCP and UDP 🌸. The nice part is that you don't have to implement ISO presentation, session, and transport protocols just to do ISO network management in a TCP/IP environment 🙌. This minimal approach is justified because the non-ISO presentation protocol used is very small and very simple 🧚. So the LPP defined in RFC 1085 gives us a compact, easy-to-implement solution to the problem 💜. The resulting CMOT protocol stack is shown in Figure 1 🦋.
Manager Agent
+-----------------------+ +-----------------------+
| | | |
| +----+ +----+ +-----+ | <-------> | +----+ +----+ +-----+ |
| |ACSE| |ROSE| |CMISE| | CMIP | |ACSE| |ROSE| |CMISE| |
| +----+ +----+ +-----+ | | +----+ +----+ +-----+ |
| | | |
+-----------------------+ +-----------------------+
| LPP | | LPP |
+-----------------------+ +-----------------------+
| TCP | UDP | | TCP | UDP |
+-----------------------+ +-----------------------+
| IP | | IP |
+-----------------------+ +-----------------------+
| Link | | Link |
+-----------------------+ +-----------------------+
| |
| |
| |
=========================================================
Network
=========================================================
Figure 1. The CMOT Protocol ArchitectureIt's important to note that the presentation services the LPP provides are "real" (but minimal) ISO presentation services [24] 🌈. That gives us a clear migration path to "full ISO" down the road 🛣️. That migration would happen by swapping in ISO protocols for the Internet protocols TCP, UDP, and IP [25], and replacing the LPP with ISO presentation and session protocols 🔁. The good news is that no changes will be required in the ISO application layer protocols 🙌. Which means investments in application development will be well preserved 💰✨.
4.2.2. The Quality of Transport Service 🔥
Okay the quality of transport service needed for network management applications is lowkey the most controversial topic here 😭. It's caused a lot of debate and it has never been resolved 🥲. There are two basic approaches: datagram-oriented and connection-oriented. Both have advantages and disadvantages ⚖️. The datagram-oriented approach is simple, needs minimal code space, and can operate in conditions where connections may not be possible 🦋. The connection-oriented approach, on the other hand, offers data reliability and provides guaranteed and consistent service to the driving application 💎.
This memo does not take sides on this issue 🙅♀️. Instead it hands that decision over to the network management applications, since they're the point where the requirements from the underlying service actually need to be determined 🎯. So the CMOT protocol architecture provides both services ✨. The presentation layer service lets the application pick either high or low quality service for the underlying transport 🎀. Depending on that choice, the LPP will use either UDP (low quality) or TCP (high quality) to establish the application association and carry the application data 🧚. It's really important that the application is aware of which quality of service it's using, because low quality means low quality! 🚨 Using an unreliable transport like UDP necessarily puts more burden on the application 💀.
4.3. Proxy Management 🧚
Okay so "proxy" is actually a legal-world word 💼 for an entity that's allowed to act on behalf of someone else. Here it's giving: a proxy is a manager that's empowered to do stuff on behalf of another manager 💅. This may be necessary because the manager can't talk directly to the managed devices, either for security or other admin reasons, or because the two sides use incompatible communication mechanisms or protocols 🙅♀️. Either way, the proxy becomes an agent toward the requesting manager 🎀 and a manager toward the managed device 🦋.
Some network elements, like modems or bridges, may not be able to support CMIP and all the associated protocols 😭. On top of that, those devices may not have Internet addresses. These are called "limited systems" 💀. You may be able to manage them with proprietary mechanisms or other standard protocols, like the IEEE 802.1 management protocol for managing bridges 🌉. But if you want to integrate their management with the overall CMOT management of an internet, you need to use proxy management 🫶. And fr, some network elements that aren't "limited systems" may still benefit from proxy management too. If the management protocol on such a system is proprietary, or some standard protocol other than CMIP (like SNMP), CMOT proxy management can be used to integrate it ✨.
Here's how a proxy operates 🔥. When a CMOT manager wants to send a request to a managed device it can't communicate with directly, it routes the request to the proxy. The proxy maps the CMIP request into the information schema the managed device understands, then sends the appropriate request to that device using the device's native management protocol. When the proxy gets the response back from the managed device, it uses CMIP to return the info to the manager that made the original request 💖.
Proxy management can be pretty much transparent to the requesting manager 👀, who feels like they're talking straight to the selected device. The only thing the manager knows is that extra "instance" information is required to pick out one particular device 🍓. Each proxy may support loads of managed devices, using the "instance" info to multiplex CMIP requests and responses among them 🧚. How a specific instance maps to 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 a less transparent sense 🧠. The proxy manager may be asked to calculate summary statistics on info gathered from lots of different managed systems (e.g., the average number of PDUs transmitted, or the distribution of PDUs transmitted over time 📊). It may also be asked to log events transmitted by the managed systems under its control, and send only events of specific types to the requesting manager 🚨. When this use of proxy management happens, the conceptual schema for managed objects known to both the requesting manager and the proxy must include definitions of these aggregate managed objects (i.e., objects that don't belong to any one managed system 💜). How the aggregate statistics would be calculated, and how logging would be performed based on info from the different devices the proxy manages, 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 spells out how the service name for an OSI application entity gets converted into an "application entity title." That application entity title is then mapped into a presentation address 🗺️. You can find the form of a service name, an application entity title, and a presentation address in RFC 1085 🎀.
5. Management Information ✨
Okay, this section is all about the info that actually gets managed 🧠. There are two aspects. First, a structure of management information (SMI) defines the logical structure of management information and how it's 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 💅.
5.1. The Structure of Management Information
The SMI is the model for understanding management info, and it also gives you templates and ASN.1 macros for defining actual management info 🧩. This section discusses the ISO SMI, the Internet SMI, and a way of interpreting the Internet SMI in terms of the ISO SMI, so that CMIP can carry management info 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 🌸. Not gonna lie, this isn't a complete or totally accurate description of the latest ISO SMI work 🙈. It's more a clear presentation of the basic ISO SMI concepts you need to understand the CMIP-specific interpretation of the Internet SMI 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 get represented as 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 🌐. Here, "manageable" means 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 it belongs to 🧚. So an object instance is an actual realization of an object class (i.e., a managed object of a particular class bound to specific values) 💜. For example, "transport connection" is an object class. 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 about various relationships the object may be involved in ✅. All of this info 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 🔗. Two relationships 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. There's also 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 🦄 periodt.
5.1.1.2.2. The Containment Hierarchy ✨
okay so the containment hierarchy is built by using the relationship "is contained in" on objects and attributes 🌸 Objects of one class can contain objects of the same class or a different class, and objects can also contain attributes. Attributes can't contain objects or other attributes, no exceptions 🙅♀️ For example, objects of the class "transport entity" can contain objects of the class "transport connection," and an object of the class "management domain" can contain objects of the class "node." 💅
When an object class contains another object class, it's called the "superior" object class. The one that gets contained is the "subordinate" object class. The containment relationships an object can take part in are part of the definition of its object class, so the class itself decides who it can live inside 🏠 Every object class (except the topmost one) needs at least one possible superior in the containment tree. A class is allowed to have more than one possible superior, but even then, each individual instance is still contained in only one instance of a possible containing class. One home per object, bestie 🦋
The containment hierarchy matters a lot because it's how you identify instances of a managed object 🔥 Say you have an object class "domain" that contains an object class "node," which contains an object class "transport entity," which contains an object class "transport connection." You can pin down one specific transport connection by stringing together the "instance information" for every class in the containment path:
{ domain="organization," node="herakles," transport entity=tp4,
transport connection=<TSAP-AddressA, TSAP-AddressB> }The "instance information" that counts for each class is set by that class's definition, and it's called the "distinguished attribute(s)." A distinguished attribute is made up of an OBJECT IDENTIFIER that names the attribute plus the attribute's value 🧚 For each class, the distinguished attributes that tell instances apart are grouped together as the "relative distinguished name." Stack up one relative distinguished name per class along the containment path and you get the "distinguished name" of a managed object. The example above is the distinguished name of a transport connection 🎀 Because the containment hierarchy is what lets you "name" a specific instance, people sometimes call it the "naming tree" 🌈
Containment also sets up an existence dependency between its pieces. An object or attribute can only "exist" if the object that contains it also "exists" 💜 So deleting an object might wipe out everything inside it too. Or, depending on how that managed object is defined, the deletion might get refused until all of the contained managed objects have been deleted first. It depends on the object, periodt 💀
5.1.1.2.3. The Inheritance Hierarchy 🌸
Now the inheritance hierarchy is built with the relationship "inherits properties of," but this time it's applied to object classes 🦋 One object class can inherit properties from another, and you refine things by adding extra properties on top. The parent is called the "superclass" and the one doing the inheriting is the "subclass" 👑 Say the class "layer entity" is a superclass of "network entity," and "network entity" is a superclass of "X.25 network entity." Any attribute defined for "network entity" (like the number of packets sent) is automatically defined for "X.25 network entity" too, so you don't have to spell it out again in that class's definition 🙌 That's why inheritance is basically a shortcut for defining object classes with an object-oriented approach. ✨
Every class (except the topmost one) has at least one superclass, but it can have zero, one, or many subclasses. Subclasses can have their own subclasses, as deep as you want to go 🌈 There's also a special object called "top," which is the ultimate superclass, and it doesn't have any properties of its own 🫶
Here's the tea though: the inheritance hierarchy has nothing to do with naming object instances 💀 It's only useful because it leads to a way of defining object classes that's manageable and easy to extend, and that's the whole point 🍓
5.1.2. The Internet SMI 💖
The Internet SMI [2] is designed to be protocol-independent, so it can be used with both SNMP and CMIP 🎀 Because of that, any management protocol that uses this SMI has to explain how it's meant to be read in its own protocol-specific way. This memo does that for CMIP 💅
The Internet SMI covers two things: how to identify managed objects, and how to define them 🔥 It sets aside a registration subtree rooted at { iso(1) org(3) dod(6) internet(1) } so people can register OBJECT IDENTIFIERs that uniquely identify managed objects 🧚 The current Internet SMI defines objects using an "object type" template and an associated OBJECT-TYPE ASN.1 macro. Each object type definition has five fields: a textual name plus its matching OBJECT IDENTIFIER, an ASN.1 syntax, a definition of what the object type means, an access setting (read-only, read-write, write-only, or not-accessible), and a status (mandatory, optional, or obsolete) 🌸 The current Internet SMI doesn't give you any way to define actions or events tied to a managed object, which is kind of a bummer 🙈
The Internet SMI doesn't use the "object class" and "attribute" ideas from the ISO SMI. It only uses "object type" and "object instance" 💜 It shows you how to define object types, but leaves the specification of object instances up to each protocol 🦋 Honestly, the current Internet structure of management information is simpler and less rich than the ISO version 🥲 The ISO SMI separates simple "attributes," which act as "leaf objects" at the very bottom of the containment hierarchy, from composite "managed objects" that belong to an "object class" and have a structure (meaning they can contain attributes). The Internet SMI skips that split, and both simple and composite "objects" are just defined as "object types" ✨ Any structure the Internet SMI gives objects comes from deliberately organising the lower part of the Internet registration tree around containment principles. Objects that count as "attributes" of a containing object get defined directly beneath it in the object registration tree 👑 That comes with a bit of inflexibility, since the registration hierarchy is implicitly doing double duty as the containment hierarchy. So the Internet SMI has no way to define containment relationships that don't line up with the registration hierarchy 😭 When you use the Internet SMI with CMIP, you have to work around that limitation 🛠️
5.2. The Management Information Base 🌈
The Management Information Base (MIB) is a "conceptual repository of management information" 🫶 It's an abstract view of every object in the network that can be managed 💅 The MIB is only conceptual, which means it says absolutely nothing about how the management information is physically stored (main memory, files, databases, etc.) 🧚 The SMI is what gives the guidelines for defining the objects contained in the MIB 🎀
The CMOT approach is going to use the Internet MIB, which is based on the Internet SMI we just covered 💖 The first version of the Internet MIB came out of the IETF MIB working group and is defined in RFC 1066 [3]. It holds objects split into eight groups: system, interfaces, address translation, IP, ICMP, TCP, UDP, and EGP 🦋 On top of that, the Internet SMI makes room for future versions of the Internet MIB, and for extending the MIB by registering managed objects under "private" and "experimental" branches of the object registration tree 🌸 Appendix B gives a protocol-specific reading of the first version of the TCP/IP MIB defined in [3], so it can be used with CMOT. That reading is based on a straightforward mapping from the current Internet SMI to the ISO SMI (section 5.3) 🔥
The first version of the Internet MIB is focused on objects tied to various Internet protocols 🍓 Future versions and extensions are expected to bring a much richer set of objects to manage, including management information about all kinds of network devices and systems 👑 A bigger MIB means wide-ranging and powerful management with the CMOT approach, and that's the glow-up we're aiming for 🌟
5.3. An Interpretation of the Internet SMI ✨
okay so bestie, to actually use CMIP with stuff defined in the Internet SMI, we need two things: a way to show how object instances get specified, and enough structure to tell apart object classes and attributes 🧠💖 we get both by splitting the containment hierarchy (used for naming objects) away from the registration hierarchy, and by slapping an "object class" structure on top of the Internet SMI 🎀 imposing that structure doesn't replace or redefine the object definitions in the Internet MIB. It's just a gloss or commentary on a MIB that's defined in terms of the Internet SMI 💅 For example, Appendix B references the "object type" definitions found in [3], but adds extra structure on top of them 🦋
The object class definition is a simplified version of the OBJECT-CLASS macro from the ISO SMI [19]. The full fancy version isn't needed for what we're doing 🌸 (Side note: this simplified object class definition could be extended someday to show what actions and events are associated with a managed object 👀) The object class definition has these fields:
OBJECT CLASS: A textual name, called the OBJECT CLASS DESCRIPTOR, for the object class, along with its matching OBJECT IDENTIFIER 🏷️
Definition: A textual description of the object class 📝
Subclass Of: The OBJECT CLASS DESCRIPTOR of the object class that's the superclass of this one. This field is how we show the inheritance relationship 🧬
Superiors: A list of OBJECT CLASS DESCRIPTORs of the possible superior object classes of this one. This field is how we show the containment relationship 🪆
Names: A list of OBJECT DESCRIPTORs naming 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 show up in the Attribute field of the object class definition. This field tells us which attributes must be present in the relative distinguished name that identifies an instance of this object class 🔑
Attributes: A list of OBJECT DESCRIPTORs naming the OBJECT TYPES that are attributes of this object class. (The OBJECT-TYPE macro is defined in RFC 1065.) This field tells us which attributes are contained in this object class 📦
Now here's the slay part 💅 This object class definition meets our goals for interpreting the Internet SMI for use by CMIP. The Attributes field shows which attributes live in this object class, which gives us the object-class-versus-attribute distinction CMIP needs 🙌 Instead of pointing at an "attribute" definition (like the ISO SMI does), the Attributes field points at the "object type" definition from RFC 1065, which was used to define the Internet-standard MIB in RFC 1066 ✨ The name, syntax, and access info needed for attributes lives inside that "object type" definition 📋
To specify an instance of a managed object, you need two things 💜: a containment relationship that determines a sequence of object classes, and a way to specify the distinguished attributes for each object class. The Superiors field makes the containment relationship explicit, so it's no longer just a function of the registration tree 🌳 The Names field lets you point out the distinguished attributes an object class needs in order to give instance information. So basically, the object class definition is what makes it possible to specify an object instance using CMIP 🎉
5.3.1. Object Class and Attributes 🎀
The mapping of management information onto the CMIS parameters Managed Object Class and Attribute Identifier List is now officially clicking into place 😤
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.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's global, it's the OBJECT IDENTIFIER assigned to the attribute (aka "object type") 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's an integer that is the last component of the OBJECT IDENTIFIER identifying the object. For ipForwarding, the local Attribute Identifier is 1 🔢 When the local identifier is used, the leading components of the attribute's OBJECT IDENTIFIER must be the OBJECT IDENTIFIER of the containing object class. This is true for the interpreted Internet MIB defined in Appendix B, but it may not be true generally ⚠️ The local identifier is meant to be interpreted relative to the Managed Object Class field of the CMIP PDU. When a local Attribute Identifier shows up in a CMIP PDU, the global form is formed by prepending the OBJECT IDENTIFIER in the Managed Object Class field to the local identifier. This only works when scoping isn't 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's used purely for assigning identifiers to 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 that 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 object class in the containment hierarchy that a managed object belongs to is the distinguished name of the object. An object instance is fully specified by its distinguished name 🫶
Let's do a concrete example from Appendix B 🧁 How would we represent an instance of an entry in the IP routing table? We start by examining the object class in question (ipRouteEntry), and use the Superiors field to find its superior class in the containment hierarchy (ipRoutingTable). We keep doing this until we build the following containment path of object classes: system, ip, ipRoutingTable, ipRouteEntry 🛤️ Next, for each of these object classes, we check the Names field to find the distinguished attribute for that class. If there's no Names field (like for "ip" and "ipRoutingTable"), then no instance information is required at that level 🙅♀️ Both "system" and "ipRouteEntry" have Names fields to show what information is expected at that level. With all that, we can build 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 isn't present, it's assumed to be the system the management association is established with (i.e., the system receiving the request) 🖥️
Heads up: the object instance tree can contain components of the distinguished name that are outside the managed system (node) 👀 This lets you reference objects across management domains (there could be an object class "domain") and across a collection of nodes 🌐 In a network where several intermediate managers might be involved in a request, each intermediate manager can use the "system" portion of the name to figure out where to send a request or result. This naming technique 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. So the "system" instance information can be used to name devices being managed by proxy 💖
5.3.2.3. The Inheritance Hierarchy 🧬
The Internet SMI doesn't use the inheritance relationship 🙃 The "Subclass Of" field is in the object class definition to show how the inheritance relationship would be represented, and to leave room for future extensibility. It isn't used for any of the object classes defined in Appendix B 🌸
5.4. Scoping, Filtering, and Synchronization 🔥
Within some services, CMIS provides extra capabilities related to the SMI. These are the scoping, filtering, synchronization, and linked-reply facilities. Whether these facilities are present is indicated by the Multiple Object Selection Functional Unit defined in CMIS [11] 🎀
These facilities let the manager operate on a collection of managed objects, rather than just one single object 🫶 Selecting multiple objects happens in two phases: scoping and filtering. Scoping identifies the managed objects that a filter is going to be applied to. Then filtering selects a subset of managed objects that satisfy certain conditions 🧹 If scoping isn't used, only the "base" managed object indicated by the CMIS Managed Object Class parameter is implied. An example of using scoping and filtering to select a particular managed object (a table entry) is 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 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 💅✨
5.4.2. Filtering ✨
Okay so once the scope has picked out a bunch of managed objects, you can narrow things down even more with filtering 💅 You get to pick a subset based on conditions on attributes, like the example "ipRouteAge > 100" for IP routing table entries, and you can combine those conditions with logical operations: and, or, not 🧚
5.4.3. Synchronization 🔥
Now, if your scoping and filtering picked out several managed objects (think multiple IP routing table entries), you have to decide how they stay in sync 🫶 There are two options: "best effort" and "atomic." With "best effort", a failure to apply an operation (like M-SET) to one instance doesn't stop the attempt on the other instances of that object. With "atomic", the operation either happens on every selected instance or on none of them 💀 The default is best effort 🌸
5.4.4. Linked Replies 🦋
Okay this one is kinda wild 😭 If one request for a set of managed objects gets back more than one managed object, you can't just stuff them all into one CMIP response PDU. Why? Because the response PDU only has one field for instance information, and every managed object has its own instance info. So each managed object has to come back in its own separate CMIP PDU 📦 That's where the CMIP Linked Reply PDU comes in. It links each reply back to the original request that made it. So a single CMIP Get Request PDU that uses scoping and filtering might give you zero or more CMIP Linked Reply PDUs, and then a final CMIP Get Result PDU to wrap it up 🎀
Linked replies can also be used to split up a CMIP response about one single managed object. That's only needed when UDP is the transport and you can't fit everything you asked for about that object into one response PDU, given the size limits in section 10.2 🙈
5.5. Accessing Tables 💖
This section is all about how to use the interpreted Internet SMI and MIB to get at tables ✨
5.5.1. Accessing Whole Tables 🌈
To grab a whole table, you give the object class of the table, set the scoping level to one, and leave out any attribute identifier list. Quick tea: the CMIS standard [11] says that if the attribute identifier parameter isn't there, then all attribute identifiers are assumed 🍓 So to get the entire TCP connection table, you'd use these CMIS parameters:
Object Class: { tcpConnTable }
Object Instance: "empty" (unless proxy management is used)
Scope: oneLevel(1)
Filter: not present
Attribute Identifier List: not presentScoping one level below "tcpConnTable" selects all the managed objects of the class "tcpConnEntry", since that's the only object class one level below tcpConnTable in the containment hierarchy 🧚 And with no attribute identifier list, you get all the attributes of each managed object, meaning every field of the TCP connection table entry 👑
When it replies, every table entry comes back in its own separate CMIP PDU (either a Linked Reply PDU or a Get Result PDU) 💜 Each one says Object Class "tcpConnEntry", gives the right Object Instance info for that entry, and includes an Attribute List with the value of every field in that entry ✨
5.5.2. Accessing Table Entries 🦋
To get one whole table entry, you give the object class of the entry, a distinguished name that points to the exact instance, and no attribute identifier list. Like we saw before, leaving out the attribute identifier list means you want all the attributes 🫶 And leaving out the scope means the base managed object class is what you're after 🙈 Here's how you'd grab the entire IP routing table entry where ipRouteDest is 10.0.0.51:
Object Class: { ipRouteEntry }
Object Instance: { ipRouteDest, 10.0.0.51 }
Scope: not present
Filter: not present
Attribute Identifier List: not presentThe result comes back in one CMIP Get Result PDU, with an attribute list holding every attribute (every field) of the table entry and its value 💅
If the object class points at a table entry but you don't give any instance info to pick one out, then a "noSuchObjectInstance" CMIP error should be returned 😭
Part II: Protocol Agreements 🎀
6. CMOT Protocol Overview 🧚
This part of the doc is the spec for the CMOT architecture's protocols 💖 It has the agreements you need to build network management systems that actually interoperate. The protocol suite these implementors' agreements define lets equipment from different vendors, suppliers, and networks talk to each other, which is how powerful multivendor network management based on ISO models and protocols can happen 🌸
The combo of a set of protocol standards plus the extra agreements needed to implement them is usually called a "profile." The CMOT profile picks existing standards from the international community (ISO and CCITT) and the Internet community 🦋 Existing ISO standards and draft standards for OSI network management are the foundation here. Other ISO application layer standards (ROSE and ACSE) support the ISO management protocol (CMIP) 🌈 To keep things interoperable, some choices and restrictions are made about the options and parameters those standards offer 🔥 Internet standards handle the underlying network transport, and these agreements spell out exactly how ISO network management gets implemented over TCP/IP-based internets ✨
There are at least two other groups working on profiles for interoperable OSI network management too: the National Institute of Science and Technology (NIST) Network Management Special Interest Group (NMSIG) and the OSI Network Management Forum 👑 Both are like the Netman working group, since they're all defining profiles for using ISO standards in network management. The difference is that they're specifying underlying ISO protocols, while Netman is focused on using OSI management in TCP/IP networks 🍓 For greater future compatibility, the Netman working group tried to keep the CMOT profile as close as possible to what those two groups are doing 🫶
6.1. The CMOT Protocol Suite 💜
The CMOT protocol suite is made of seven protocols: ISO ACSE, ISO DIS ROSE, ISO DIS CMIP, the lightweight presentation protocol (LPP), UDP, TCP, and IP 🦋 Figure 2 gives a quick look at how they all fit together 🧚
+----------------------------------------------+
| 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 Suite6.2. Conformance Requirements ✨
A CMOT-conformant system must implement ACSE, ROSE, CMIP, LPP, and IP 💅 It must support LPP over either UDP or TCP. It may support LPP over both UDP and TCP on the same system 🌸 A conformant system doesn't need to support every CMIS operation 🙈 It does, however, have to support at least one of the functional unit groups (a set of supported services) defined in section 7.1.3 👑 The service and protocol choices are covered in more detail in the sections that follow 🫶
6.3. Abstract Syntax Notation 🌈
All the application service elements in the CMOT protocol suite use Abstract Syntax Notation One (ASN.1) [5] 🧚 LPP is defined in ASN.1 too. The basic encoding rules for ASN.1 are in [6], and 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 CMIS service definition is in ISO DIS 9595-2 [11], and the CMIP protocol specification is 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 in the CMOT approach: M-INITIALISE, M-TERMINATE, M-ABORT, M-EVENT-REPORT, M-GET, M-SET, M-ACTION, M-CREATE, and M-DELETE 🍓 Which services a system actually supports depends on the functional unit group or groups it belongs to 👑
7.1.2. Functional Units ✨
okay so the CMIS services are designated in terms of functional units [11] 💅. Each functional unit matches the invoker or performer side of one particular service. (Quick vocab: "invoker" and "performer" come from ROSE, where the invoker is the caller of a remote operation and the performer is the responder 🧚.) The "stand alone" functional units for each management service are listed in Table 2 as functional units 0-17. The number after each name is the one CMIP [12] uses to identify that unit 🔢. The CMISE-service-user uses these at association establishment to say which services it's willing to support 🫶.
+---------------------------------+------------------------+------+
| 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 UnitsOkay, so on top of the stand alone ones, there are three extra functional units 🌈. If any of those extras get selected, then at least one stand alone unit must be selected too (rules are rules 🙈). The multiple reply unit unlocks the use of the linked identification parameter in the selected stand alone units, which is what makes linked reply possible: multiple CMIP PDU responses to a single request 🔗. The multiple object selection unit unlocks the scope, filter, and synchronization parameters in the selected stand alone units, and if you pick it, the multiple reply unit must also be selected 💖. The extended services unit gives you presentation layer services on top of the P-DATA service. Picking it does absolutely nothing in CMOT, since the lightweight presentation layer only gives minimal ISO presentation services 💀.
7.1.3. Functional Unit Groups 🎀
So to keep code size and complexity down for different kinds of devices, a bunch of "functional unit groups" have been defined 🧁. Each group is a set of services for either a manager or an agent. The "negotiation" about which groups are supported happens through the Functional Units parameter of the M-INITIALISE service (see section 7.1.4.1) 🤝. There are five manager groups: Event Monitor, Monitoring Manager, Simple Manager, Controlling Manager, and Full Manager, and each one is a superset of the group before it 📈. There are also five agent groups: Event Sender, Monitored Agent, Simple Agent, Controlled Agent, and Full Agent, and again each is a superset of the one before 🤖. The operations each group supports 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 GroupsAlright, the tea ☕: 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 it supports 🌸. And a system may also support services that aren't required by any group it supports 🦋.
7.1.4. M-INITIALISE Parameters 🧚
The M-INITIALISE service is provided by the ACSE A-ASSOCIATE service ✨. Its parameters are defined in [11] and summarized in Table 4, so here's the cheat sheet 📝:
+-------------------+-----------+-----------+
| Parameter Name | Req/Ind | Rsp/Conf |
+-------------------+-----------+-----------+
| Functional Units | Mandatory | Mandatory |
| User Information | Optional | Optional |
| Access Control | Optional | Optional |
+-------------------+-----------+-----------+
Table 4. M-INITIALISE ParametersNotice that there's an extra agreement here: the Functional Units parameter is mandatory at all times 🔒. The M-INITIALISE parameters get carried as ACSE user information in the ACSE request PDU 📦.
7.1.4.1. Functional Units 🍓
The initiating CMISE-service-user and the responding CMISE-service-user must exchange functional units. This is how the two CMIS-service-users tell each other which functional units they support 👀. CMIP [12] defines a 21-bit BIT STRING for this, and a functional unit counts as supported when its bit in that string is one 🔢. Table 5 shows the mapping between functional units and functional unit groups. The left column lists the functional unit for each bit position, the numbers across the top are the functional unit group numbers (which you can look up in Table 3), and each column shows the bit values for one group 🗂️.
+------------------------------+---+---+---+---+---+---+---+---+---+---+
|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 ValuesNow the negotiation 🤝✨, step by step. The initiating CMISE-service-user (manager or agent) sends the functional units for the functional unit group it belongs to. The responding CMISE-service-user does the same with its own group 💌. (If an application process belongs to both a manager and an agent group, then both groups get indicated in the same functional unit bit string 🧩.) If the groups the two application entities support don't allow meaningful communication, either entity may refuse the association 🙅♀️. "Meaningful communication" means the entity can invoke or perform at least one CMIS operation the other entity supports (in other words, some "complementary" set of functional units exists 💞). Once the association is established, a system must give the proper response for the functional units it has said it can support, and it should gracefully refuse other requests in line with the protocol 🫶💅.
7.1.4.2. User Information ✨
The User Information parameter is optional 💖 Nobody is required to send it, but all entities are expected to tolerate receiving it 🫶
One possible use 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 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 AttributeValueAssertionThe 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 attributeIdThose 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 🧩
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) 💅
⚠️ bestie, an unencrypted password is a big ask. Read that line twice before you rely on it 😭
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:
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
}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 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:
- A-ASSOCIATE: This confirmed service is used to initiate an application association between application entities.
- A-RELEASE: This confirmed service is used to release an application association between application entities without loss of information.
- A-ABORT: This unconfirmed service causes the abnormal release of an association with a possible loss of information.
- 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 Services8.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] 💜
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 ✨
okay so the Application Context Name is an OBJECT IDENTIFIER 🎀 and it's giving two versions in one tag. It carries the CMOT version used for the association AND the version number of the highest Internet-standard MIB the manager or agent supports. Iconic double-check energy 💅
{ 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 supportedFor the version of CMOT defined in these agreements, "version-number" is always one (1) 🦋. This version of CMOT also implies the versions of the ISO protocols specified in this memo (see Figure 2). Main character energy, honestly 👑
8.3.2. User Information 🧚
The CMIS M-INITIALISE parameters Functional Units, User Information, and Access Control all get mapped onto the ACSE User Information parameter 💜 (see section 7.1.4 for more on those M-INITIALISE parameters). ACSE User Information is defined in ISO 8650 like this:
Association-information ::= SEQUENCE OF EXTERNALThe ASN.1 type EXTERNAL is defined in section 35 of ISO 8824 [5], and it needs an OBJECT IDENTIFIER for identification plus an associated ASN.1 encoding. Bestie, that's the whole vibe 🫶
The OBJECT IDENTIFIER and syntax for the ACSE Functional Units EXTERNAL are in [12]. The OBJECT IDENTIFIER is { 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 for now 🙈. It'll get defined in a future memo, so stay tuned ✨
If some form of access control is REQUIRED, a simple unencrypted password can be used 🔐. That simple access control EXTERNAL uses 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 the parameters to the ACSE primitives that go 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 Abstract Syntax Name tied to 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). Lowkey the key link between the two ✨
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) is the bit that gives you the ability to invoke remote operations 🔥. It's 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 🙅♀️. It's used to support CMISE, and it is NOT intended to be used directly by management application processes, so please don't go poking it directly 💅
9.1. ROSE Services 🦋
The ROSE service definition is detailed in ISO 9072-1 [9]. 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. 🚨
The 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]. Here's the tea 🍵:
+-------------+------------+----------------------+-------------+
| 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. Two restrictions come along with using 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. Okay, that's a lot of "no" but it's giving clean 🫧
9.3. ROSE Protocol 🎀
The protocol specification for ROSE SHALL follow ISO 9072-2 [10] ✨. All four APDUs specified in the standard are mandatory. On top of that, 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 🙃
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) lives 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 needed to support ACSE and ROSE. The protocol specified to provide these services is a replacement for the ISO presentation protocol. Glow-up arc, iykyk 🦋
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 gives you an unreliable datagram service, while TCP gives you a reliable, connection-oriented transport service 🔌.
Practically speaking, there are two ways to find out whether a remote system supports the LPP over UDP or TCP 🕵️♀️. The first is to use some undefined form of directory service, which might be nothing more than a local table. The second is to simply 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-provider will issue a negative P-CONNECT.CONFIRMATION primitive. ACSE will interpret that 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/udpWhen UDP is used, an implementation need not accept a lightweight presentation PDU whose length exceeds 484 🙈. The purpose of this restriction is to make sure CMIP requests and responses can be sent 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, IBM12. References 📚
Okay bestie, this is the bibliography, so every single title, date, and number stays exactly as the original has it. Here we go 🫶
[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 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.
[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.
Appendix A - The CMOT Group 🧚
okay the appendix is giving CMOT vibes and it's honestly iconic 💅 here's the whole definition, copied exactly so nothing gets lost ✨
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.
ENDLook at that, the whole CMOT group is wrapped up, no notes, no drama 🦋
Appendix B - Management Information Summary ✨🎀
okay bestie, this is the big ASN.1 module that lays out the whole MIB tree 🌳💜 every object class is in there, grouped by system, interfaces, address translation, IP, ICMP, TCP, UDP and EGP, all sitting under mib. it's giving organized closet energy 💅 here it is, copied exactly:
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
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 }
-- 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
}
::= { 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,
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 }
-- 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 }
-- the EGP Neighbor table
egpNeighTable OBJECT-CLASS
SUPERIORS { egp }
::= { egp 5 }
egpNeighEntry OBJECT-CLASS
SUPERIORS { egpNeighTable }
NAMES { egpNeighAddr }
CONTAINS {
egpNeighState,
egpNeighAddr
}
::= { egpNeighTable 1 }
ENDAppendix C - Sample Protocol Exchanges ✨
okay bestie, this is the fun part 🧚 the appendix has sample conversations between a manager and an agent, and it's literally a little story. the manager makes an association with the agent, asks how many IP address and header errors there are, asks what type of route goes with the destination 10.0.0.51, asks for the TCP connection on the well-known FTP port, and then hangs up by releasing the association 💅 every single sample runs the lightweight presentation protocol over TCP, so the whole vibe is consistent 🫶
First, the manager sends an ACSE association request, wrapped up in a presentation connect request PDU 🎀
--
-- 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
}
}
}
}
}
}Next, the agent sends back its ACSE association response, carried in a presentation connect response PDU 🦋
--
-- the agent sends an ACSE association response carried in a
-- presentation connect response PDU
--
{
connectResponse { -- LPP
user-data {
user-information { -- ACSE
functionalUnits {
direct-reference 1.0.9596.2.1.0.0,
encoding {
single-ASN1-type '101001010101010101110B'
-- Full Agent
}
}
}
}
}
}Now the manager sends a get request to read the values of ipInHdrErrors and ipInAddrErrors 👀
--
-- 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
}
}
}
}
}
}
--
-- 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 agent answers with the values ipInHdrErrors = 0 and ipInAddrErrors = 2, which is the tea 🍓
Next up, the manager wants the ipRouteType for the IP routing entry where ipRouteDest = 10.0.0.51 🗺️
--
-- the manager sends a get request to discover the ipRouteType for
-- the IP routing entry with ipRouteDest = 10.0.0.51
--
{
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 {
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 agent replies with the right route type, which is "direct" ✨
Now for the big one: the manager asks for the TCP connection on the well-known port for FTP 🦋
--
-- 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 {
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 },
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
}
}
}
}
}
}
}The agent's reply has the TCP connection info. If more than one TCP connection matched the filter, the agent would send a series of one or more linked reply PDUs before the final get response, so keep an eye out for those too 👀
Finally, the manager sends a presentation release request to wrap things up 🌸
--
-- the manager sends a presentation release request
--
{
releaseRequest { -- LPP
user-data { -- ACSE
reason normal
}
}
}And the agent sends a presentation release response to close it out, with a reason of 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📦 where this page comes from
- ietf: rfc1095 1989-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms