Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
This article provides a detailed technical analysis of CAN/CSA-ISO/IEC 10164-11-97, the Canadian adoption of the international standard Information technology — Open Systems Interconnection — Systems management: Workload management function. This standard is technically identical to ITU-T Recommendation X.739. Ratified by the Standards Council of Canada in 1997, it defines a critical component of the OSI Systems Management framework (ISO/IEC 7498-4).
The primary scope of this standard is to specify the semantics and behavior of a Systems Management Function (SMF) used for monitoring and controlling the workload of managed objects within an Open Systems Interconnection (OSI) environment. It addresses the need for standardized mechanisms to evaluate system performance, detect anomalies, and plan for capacity across heterogeneous network elements. The standard defines an abstract model of workload management that is independent of any specific implementation or protocol stack, although it is specifically designed to operate over the Common Management Information Protocol (CMIP).
The standard defines the workload of a managed object as the measure of its current usage of resources relative to its capacity. This function provides a set of services to establish workload thresholds, receive threshold crossing alerts (i.e., workload reports), and query the current workload value of a specific managed object.
The technical backbone of CAN/CSA-ISO/IEC 10164-11-97 lies in its well-defined Managed Object (MO) classes and their associated packages, attributes, and notifications. The standard uses the Guidelines for the Definition of Managed Objects (GDMO) to specify these components.
The standard introduces several specific classes to implement the workload management function. The central entity is the workloadMonitor managed object.
Table 1: Primary Managed Object Classes
| Managed Object Class | Description | Key Attributes |
|---|---|---|
workloadMonitor | Responsible for monitoring the workload of a specific managed object. It holds the current workload value and the associated threshold definitions. | workloadThresholdHigh, workloadThresholdLow, workloadHysteresis, currentWorkloadValue, observingManagedObject |
metricObject | Represents the underlying resource or counter being measured (e.g., CPU utilization, queue length, process count). | metricId, metricValue, metricModTime |
thresholdData | Defines the specific thresholds (high/low) and the parameters for the type of workload measurement. | granPeriod, thresholdInfoId, measurementDuration |
workloadReporting | A conditional package that allows the system to emit an M-EVENT-REPORT when a threshold is crossed or cleared. | workloadReportId, notificationDiscriminator |
The standard mandates the use of specific CMIS primitives for interaction. An administrator can use M-GET to retrieve the current workload value from a workloadMonitor object. M-SET is used to modify threshold values dynamically. M-EVENT-REPORT is used by the agent to inform the manager of workload anomaly events (Threshold Crossing Alerts – TCAs).
workloadHysteresis attribute is crucial for preventing “event storms”. The standard allows hysteresis to be defined as either an offset value (the workload must deviate by a specific amount from the threshold before a new event is generated) or a time-based value (the workload must remain outside the threshold for a specified duration). Implementers must correctly handle this dual nature to ensure stable behavior. Deploying a system that conforms to CAN/CSA-ISO/IEC 10164-11-97 requires a robust OSI management stack. The workload management function is typically implemented in an agent system that monitors a network element or a software process.
workloadMonitor object is created and associated with a target managed object via the observingManagedObject attribute.workloadThresholdHigh, workloadThresholdLow) and the hysteresis value are set by the managing system.M-EVENT-REPORT is sent encapsulating the relevant workload data.Table 2: Workload Monitoring Parameters (as defined in X.739/10164-11)
| Parameter | Type | Definition |
|---|---|---|
| Workload Value | Dynamic | The current metric representing the system load (e.g., percentage of CPU in use, queue depth). |
| Granularity Period | Duration | The interval over which the workload value is calculated or sampled (e.g., 5 seconds, 1 minute). |
| Threshold High | Integer | The upper boundary value. Crossing this from below triggers a highWorkload report. |
| Threshold Low | Integer | The lower boundary value. Crossing this from above triggers a lowWorkload report. |
| Hysteresis | Integer or Duration | A dead-band value. It defines either the offset by which the workload must exceed the threshold before the condition is true, or the time it must remain outside the threshold. |
M-GET, request the currentWorkloadValue and the workloadThresholdHigh/Low attributes together. This provides instant context on whether the current load is in a normal, warning, or critical state without requiring separate requests, reducing management traffic. Conformance to CAN/CSA-ISO/IEC 10164-11-97 is vital for interoperability in strict OSI/CMIP-based management environments. The standard provides a PICS (Protocol Implementation Conformance Statement) proforma (usually found in an informative annex) that defines the capabilities and options an implementation must declare.
workloadMonitor class, including the workloadMonitorPackage and the metricObjectPackage.workloadReporting package is conditional. If the agent supports reporting, it must fully implement the workloadReport notification and the associated discriminator constructs.workloadMonitor object must be consistent with the name binding specified in the standard.granPeriod and measurementDuration attributes correctly is a frequent source of certification failure. The managing system expects the values reported to represent the average load over the defined period, not an instantaneous reading. Misreporting this leads to false positives in threshold crossing alerts and invalid capacity planning data. The standard also links strongly to other OSI management functions. It must be used in conjunction with ISO/IEC 10164-1 (Object Management Function) for creating and deleting the workloadMonitor instances, and ISO/IEC 10164-5 (Event Report Management Function) for configuring the forwarding of workload reports to different manager destinations.
M-GET, M-SET, M-EVENT-REPORT). granPeriod). The management system (manager) is responsible for logging the received currentWorkloadValue or workloadReport events into its own database for historical analysis and capacity planning. The agent itself does not inherently provide a long-term data store as part of the workload function. workloadMonitor class?