Alert Standard Format (ASF) Specification
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136
DSP0136 23 April 2003 Page 5 of 94
2 Overview
Alerting technologies provide advance warning and system failure indication from managed
clients to remote management consoles. Initial generations of this technology — like the
IBM/Intel Alert on LAN™ (AoL) implementations — provided remote notification of client system
states and hardware or software failures without regard to operating system or system power
state. The Intelligent Platform Management Interface initiative, led by Intel and others,
subsequently provided an open alert interface: the Platform Event Trap. Management console
providers and system OEMs were faced with the possibility of supporting multiple alerting
interfaces.
Once a system alert provides its warning or error report, the next step in remote system
manageability is to allow corrective action to be taken — these actions include the ability to
remotely reset or power-on or -off the client system. When the system is in an OS-present state,
these actions can be provided by Common Information Model (CIM) interfaces [CIM] that interact
with the local system and provide orderly shutdown capabilities. This specification provides
similar functionality when the system is in an OS-absent state, as added by the second
generation of the IBM/Intel AoL technologies.
2.1 Principal Goals
The principal goal of this specification is to define standards-based interfaces with which vendors
of alerting and corrective-action offerings can implement products and ensure interoperability.
These vendors include:
• Add-in card suppliers
• SMBus sensor suppliers
• Communication controller suppliers
• System vendors
• Operating system vendors, with a primary focus on operating systems which are ACPI-
aware.
• Management application vendors
The standards-based protocols (e.g. SNMP, UDP) upon which this specification’s interfaces are
built are lightweight, bit-based information carriers since this specification anticipates that the
majority of the ASF client implementation will be hardware and/or firmware based. CIM-based
configuration methods can provide the abstraction layer between OS-present XML
implementations and ASF-defined low-level primitives.
2.2 Problem Statement
Multiple solutions exist in the industry today, resulting in a loss of interoperability in system alert
and corrective-action offerings.
2.3 Solution
An Alerting System consists of a client system (or systems) and a management console that both
monitors and controls the clients. An ASF-aware client provides the following interfaces to allow
interoperability between the client and its management console:
1. the alert messages transmitted by the client system
2. the remote maintenance requests sent to the client system and the associated responses
3. the data description of the client’s system-specific capabilities and characteristics
4. the software used to configure or control the client system in an OS-present state
An additional level of interoperability occurs between a client system’s alerting components: