Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 10164-2-95: A Comprehensive Technical Guide to State Management in OSI Systems Management
Understanding the ISO/IEC 10164-2:2003 Standard for Managed Object State Attributes and Notifications
Standard Update: IEC 10164-2-95, published jointly with ISO/IEC 10164-2:2003, defines the State Management Function for Open Systems Interconnection (OSI) systems management. It is technically aligned with ITU-T Recommendation X.731 and provides a uniform model for representing and reporting the state of managed objects in a distributed management environment.
Scope and Introduction
IEC 10164-2-95 specifies the state management function that is used to model the operational condition of resources managed within an OSI environment. The standard defines a set of standardized state attributes, state transition graphs, and the semantics for state change reporting. It is part of the larger Systems Management series (ISO 10164, IEC 10164) and supports the management information model defined in ISO/IEC 10165.
The primary purpose of the state management function is to enable management applications to query, interpret, and control the state of managed objects consistently across heterogeneous systems. This ensures that network, system, and application administrators have a common language for describing resource availability, usage, and administrative status.
Tip: The state model defined in IEC 10164-2-95 is independent of any specific protocol. It can be used with CMIS/CMIP, SNMP proxy, or Web-based management frameworks as long as the semantics are preserved.
Technical Requirements and State Attributes
Managed Object State Attributes
The standard defines several mandatory and optional state attributes that may be present in a managed object class. These attributes collectively describe the instantaneous condition of the resource. The key attributes are:
| Attribute | Type | Allowed Values | Description |
|---|---|---|---|
| operationalState | Mandatory | enabled, disabled | Indicates whether the resource is physically or logically capable of providing service. |
| usageState | Mandatory | idle, active, busy | Describes the degree to which the resource is currently utilized. |
| administrativeState | Conditional | locked, unlocked, shuttingDown | Designates the permission or prohibition imposed by management action. |
| availabilityStatus | Optional | inTest, failed, powerOff, offLine, offDuty, dependency, degraded, notInstalled, logFull, standby | Provides additional details about the reasons for the current operational state. |
| proceduralStatus | Optional | initializationRequired, notInitialized, initializing, reporting, terminating | Corresponds to the life-cycle status related to initialization and termination procedures. |
Important: Implementations shall support at least the operationalState and usageState attributes as mandatory. The administrativeState is required only when the managed object supports administrative control.
State Transition Model
Each state attribute follows a defined state transition diagram. For instance, the operationalState can transition from disabled to enabled when the resource becomes capable of providing service; the reverse transition occurs when a failure is detected or the resource is deactivated. The standard specifies the valid transitions and the conditions under which each transition may occur. These transitions are not arbitrary—they are constrained by the resource’s internal logic and management interactions.
Non‑Compliance Risk: Using transitions not defined in the standard (e.g., directly changing from busy to locked without first going through idle) breaks interoperability and may cause management applications to misinterpret the resource state.
Implementation Highlights
State Change Notifications
Whenever any state attribute changes value, the managing system shall be notified via a stateChange event (defined in the standard’s notification template). The notification carries the attribute identifier, the old value, the new value, and an optional cause string. Implementations must ensure that notifications are reliable and that duplicate or spurious notifications are minimized.
Integration with Management Information Model
IEC 10164-2-95 is designed to be used in conjunction with the (G)DMO (Guidelines for the Definition of Managed Objects). When defining a new managed object class that requires state representation, the developer inherits the state attributes from the standard’s package or imports them using the CONDITIONAL PACKAGE construct. The standard provides an ASN.1 module that defines the syntax and behavior of all state attributes.
Implementation Example: A power supply managed object would use
operationalState (supplying power = enabled), usageState (active if running, idle if in standby), and availabilityStatus ( failed if internal fault detected). The administrativeState is set to locked by an operator to prevent the power supply from being used.Compliance and Conformance
Conformance Requirements
Systems claiming conformance to IEC 10164-2-95 must:
- Support the mandatory attributes (operationalState, usageState) and the associated state transition rules.
- Generate stateChange notifications for each mandatory attribute when its value changes.
- Implement the standard’s ASN.1 type definitions exactly as specified.
- Document any additional state attributes added via subclassing and ensure they do not conflict with the standard’s semantics.
Testing and Verification
Conformance testing typically involves verifying that the state machine behaves according to the defined transitions, that notifications are generated correctly, and that the management interface responds to M-GET and M-SET operations on state attributes in compliance with the standard’s access rules. The use of abstract test suites based on ISO/IEC 9646 is recommended.
Tip: When preparing for conformance testing, automate the generation of state transitions and verify that the sequence of notifications matches the expected pattern. Many interoperability issues arise from missing or out-of-order stateChange events.
Frequently Asked Questions
Q: Is IEC 10164-2-95 still relevant in modern management protocols like NETCONF/RESTCONF?
A: Yes. The state semantics defined in the standard are protocol independent. Many YANG modules that model resource state borrow concepts directly from X.731/IEC 10164-2-95. For example, the
A: Yes. The state semantics defined in the standard are protocol independent. Many YANG modules that model resource state borrow concepts directly from X.731/IEC 10164-2-95. For example, the
operational-state and administrative-state in network management YANG models are direct counterparts of the standard’s attributes.Q: Can I use the state management function for non-OSI applications?
A: Absolutely. The state model is abstract and can be applied to any resource that goes through operational, usage, and administrative regimes. It has been used in industrial automation, cloud resource management, and telecommunication service assurance.
A: Absolutely. The state model is abstract and can be applied to any resource that goes through operational, usage, and administrative regimes. It has been used in industrial automation, cloud resource management, and telecommunication service assurance.
Q: How does IEC 10164-2-95 relate to ITU-T X.731?
A: They are technically identical. ITU-T X.731 (02/20) is the same content, published under the Telecommunication Standardization Sector. IEC/ISO and ITU collaborate to ensure the two documents are aligned.
A: They are technically identical. ITU-T X.731 (02/20) is the same content, published under the Telecommunication Standardization Sector. IEC/ISO and ITU collaborate to ensure the two documents are aligned.
This technical article reflects the content of IEC 10164-2-95 (ISO/IEC 10164-2:2003) and its applicability as of 2026. Always refer to the latest published edition for conformance.