Alert Standard Format Specification DSP0136 STATUS: Final Copyright © 2000-2002 Distributed Management Task Force, Inc. (DMTF). All rights reserved. DMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems management and interoperability. Members and non-members may reproduce DMTF specifications and documents for uses consistent with this purpose, provided that correct attribution is given.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 Change History Version 1.0a Date October 13, 2000 December 13, 2000 Author K. Cline K. Cline 1.0.c January 17, 2001 K. Cline 1.01 May 23, 2001 K. Cline 1.02 May 30, 2001 June 13, 2001 June 19, 2001 June 20, 2001 K. Cline K. Cline K. Cline K. Cline 1.0.b 1.03 1.03 Final DSP0136 Changes First Draft release for the DMTF Member Comment phase.
Alert Standard Format (ASF) Specification v2.0 Version 2.0.h Date 14 August 2002 Author K. Cline 2.0.k 06 November 2002 K. Cline 2.0.i 13 November 2002 23 April 2003 K. Cline 2.0 Final DSP0136 K. Cline DMTF Document DSP0136 Changes First draft version of the specification update that adds security protocols to RMCP messages, released for the DMTF Member Comment phase.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 Table of Contents Change History ................................................................................. ii 1 Introduction.................................................................................... 2 1.1 Target Audience................................................................................................................ 2 1.2 Related Documents................................................................
Alert Standard Format (ASF) Specification v2.0 3.2.4.3 3.2.4.4 3.2.4.5 3.2.4.6 3.2.4.7 3.2.4.8 3.2.4.9 3.2.4.10 3.2.4.11 3.2.4.12 3.2.4.13 3.2.4.14 3.2.4.15 3.2.5 3.2.6 DMTF Document DSP0136 Presence Pong (40h) .......................................................................................... 36 Capabilities Response (41h) ............................................................................... 36 System State Response (42h) .................................................................
Alert Standard Format (ASF) Specification v2.0 5.2.1.2 5.2.2 DMTF Document DSP0136 No Boot Options Response................................................................................. 74 Boot Options Clear .............................................................................................. 74 5.3 Discovery and Status Messages..................................................................................... 75 5.3.1 Device Type Poll Message ..............................................
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 1 Introduction The term “system manageability” represents a wide range of technologies that enable remote system access and control in both OS-present and OS-absent environments.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 • [SMBIOS] System Management BIOS Reference Specification, v2.3.1, 14 December 2000 , DMTF Document DSP0119, http://www.dmtf.org/standards/bios.php. • [SMBUS_2.0] System Management Bus (SMBus) Specification, v2.0, 03 August 2000, http://www.smbus.org/specs/index.html • [RFC2404] The Use of HMAC-SHA-1-96 within ESP and AH, http://www.ietf.org/rfc/rfc2404.txt. • [RFC_UDP] User Datagram Protocol, RFC 768, http://www.ietf.
Alert Standard Format (ASF) Specification v2.0 Term DMTF Document DSP0136 Description PCI Peripheral Components Interface, see http://www.pcisig.com PDU Protocol Data Unit PEC Packet Error Code. PET Platform Event Trap. See http://developer.intel.com/design/servers/ipmi/spec.htm. RAKP RFC RMCP RSP RSSP SEEPROM SHA-1 RSSP Authenticated Key-Exchange Protocol Request For Comment Remote Management and Control Protocol, see 3.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 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.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 1. the system firmware methods used to communicate system capabilities to an alert-capable add-in card’s OS-present configuration software 2. the format of the messages sent between the add-in card, the local system host, and local system sensors The following graphic gives a pictorial portrayal of these components.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 1. If the client includes legacy SMBus sensors, the addressing and configuration information for each. 2. If the client supports remote-control operations, which ASF-defined features are supported. Once the system owner has configured the alert-sending device, the managed client is enabled to send alert messages and, optionally, respond to remote-control requests from a specified management console. 2.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 3 Network Protocols 3.1 Transmit Protocol (PET) The ASF protocol for sending alerts from a managed client to a management console is the Platform Event Trap [PET]. 3.1.1 PET Frame Behavior 3.1.1.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 PET Variable Binding Field Description Trap Source Type The Trap Source Type is the device or software that originated the trap on the network. Normally it will be the NIC (50h), the System Management Card (58h), or the Modem (60h). Event Source Type The Event Source Type describes the originator of the event. The Event Source Type is ASF 1.0 (68h) for all PET frames defined by this specification.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 PET Variable Binding Field Description OEM Custom Fields Whenever possible PET frames should use the error codes and values contained in the PET specification to describe events. The OEM Custom fields should only be used if the event cannot be expressed in a standard way. If there are no OEM Custom Fields, then the type field is set to C1h. 3.1.4.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 Polled Legacy Sensors — Specified by ACPI This information map applies to alerts issued by an alert-sending device based on that device’s detection of an active event upon polling a legacy sensor that is specified by the system’s ACPI implementation.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 Polled ASF Sensors This information map applies to alerts issued by an alerting device based on that device’s detection of an active event upon polling an ASF-compliant sensor via the “Poll Alert Message With Event Data” SMBus command.
Alert Standard Format (ASF) Specification v2.0 3.1.5 DMTF Document DSP0136 Recommended PET Frame Values This section describes the format for various PET frames. A given managed client is not required to support all the listed PET frames, but if a client supports the event described by one of the listed PET frames, the client should format the PET frame as described in this section. 3.1.5.1 Environmental Events This table describes the Specific Trap Field values for common environmental events.
Alert Standard Format (ASF) Specification v2.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 Description Event Sensor Type Event Offset Event Data 1/2 No system memory; unrecoverable failure 0Fh (System Firmware Error or Progress) 00h (System Firmware Error) 40h/02h 32d (Memory Device) Unrecoverable hard-disk failure. 0Fh (System Firmware Error or Progress) 00h (System Firmware Error) 40h/03h 4 (Disk or Disk Bay) Unrecoverable system board failure.
Alert Standard Format (ASF) Specification v2.0 Descriptor Code Description 15h Reserved. 16h Floppy initialization. 17h Keyboard test. DMTF Document DSP0136 18h Pointing device test 19h Primary processor initialization 1Ah to FFh Reserved for future definition by this specification. This table describes the Specific Trap Field values for some system firmware progress events. The Event Type sub-field for each of these traps is set to 6Fh (Sensor-specific).
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 Description Event Sensor Type Event Offset Event Data Fields OS Boot Failure 23h (Watchdog 2) 00h (Timer Expired) ED1 ED2 OS Hung 20h (OS Critical Stop) 01h (Run-time stop) 40h to indicate that the ED2 field contains “interesting” data 03h to identify that no interrupt was generated and that the timer was monitoring an OS load process at the time of expiration N/A 3.1.5.
Alert Standard Format (ASF) Specification v2.0 3.2 DMTF Document DSP0136 Remote Management and Control Protocol (RMCP) The Remote Management and Control Protocol (RMCP) and its supporting security-related protocols are used for client control functions when a managed client is in an OS-absent state. In this environment, RMCP messages are exchanged between a management console and a managed client. Typical client control functions include operations such as reset, power-up, and power-down.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 2) The management console issues an RMCP Capabilities Request message to the managed client; the client … a) … acknowledges receipt of the RMCP message, so long as the RMCP version in the message’s header is a version supported by the client. b) … responds with a RMCP Capabilities Response message, returning the system capabilities previously configured into the alert-sending device’s non-volatile storage.
Alert Standard Format (ASF) Specification v2.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 Type Offset Value Version 1 byte 00h Copied from the received message Reserved 1 byte 01h Copied from the received message. Sequence Number 1 byte 02h Copied from the received message. Class of Message 1 byte 03h Bit(s) 7 6:0 Description Set to 1 to indicate acknowledgement. Copied from the header of the received message. RMCP Header for Acknowledge Contents Notes: 1.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 3.2.2.3 RMCP Data All RMCP messages have the same Data block format, but the interpretation of the fields within the Data block is dependent on the value present in the first field: the IANA Enterprise Number. OEMs and ISVs can provide extensions to the RMCP message set by setting the field to their IANA-assigned enterprise number.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 Contents Type Offset Value Message Tag 1 byte 05h This 1-byte field is used to match request-response pairs. This value is copied into the response message when one is generated in a request-response interaction, e.g. the Presence Ping/Presence Pong pair. When a duplicate message is received, i.e. one with the same Message Tag, the consumer of the message determines whether the message is accepted or rejected.
Alert Standard Format (ASF) Specification v2.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 3. The Next Header field indicates the type of message that is encapsulated between the RSP header and trailer. For this specification, the value in the Next Header field is defined as the value in the Version field of the RMCP Header of the RMCP message being processed (e.g.; 06h for ASF). 4. The Integrity Data field is used to hold the results of an integrity algorithm (e.g.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 If a session exists and the session is in the Message Transfer phase, RMCP passes the Session ID, the RMCP message, and RMCP message Length, to the next lower-layer protocol (RSP) for additional processing. 3.2.3.2.2 Message Encapsulation When the sending device's RSP protocol engine receives a message from RMCP, RSP inserts an RSP Header (see 3.2.3.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 3.2.3.3.1 Lower-Layer Protocol Processing When a frame containing a protected RMCP message reaches its destination, the lower-layer protocols (e.g. 802.3/Ethernet and IP) in the receiving device perform their processing and pass the resulting packet to the next higher-layer protocol (UDP) for additional processing. UDP in the receiving device then validates the Checksum field in the UDP header.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 Sliding Window of Received Messages 0 1 1 1 1 1 1 0 1 0 1 1 1 1 1 1 Message Stream Sequence Number N Sequence Number N+7 Sequence Number N + 16 0 = Message Not Yet Received 3.2.3.4 RSP Session Protocol (RSSP) To make use of RSP, an association must be established between a management console and the clients that it wishes to manage.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 All messages that are sent to the RMCP security extensions UDP port prior to the establishment of a session (at the end of the Creation phase) must be encapsulated within an RSP Header that uses the “Bypass” Session ID (see 3.2.3.1). This also means that no integrity protection is provided to messages by RSP until the Creation phase is complete.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 RAKP uses pre-shared symmetric keys and HMAC-based integrity algorithms to mutually authenticate a management console to a given managed client and to generate pair-wise unique symmetric keying material that can be used with a number of integrity algorithms to provide protection for RMCP messages.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 After receiving Message 2, the management console verifies that the value SIDM is active and that GUIDC matches the managed client that the management console is expecting to communicate with. The management console then validates the HMAC.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 Algorithms such as RAKP depend on "quality" random numbers for their security. Quality in this context means that the numbers must be random in a cryptographic sense (i.e., they must be genuinely unpredictable).
Alert Standard Format (ASF) Specification v2.0 Status Code DMTF Document DSP0136 Description Message 43h 10hFFh 44h C1h C2h Reserved for future definition by this specification 3.2.4 RMCP “ASF” Message Types This section defines message data formats for the standard RMCP “ASF” class (i.e. the IANA Enterprise Number in the RMCP Data section is 4542).
Alert Standard Format (ASF) Specification v2.0 Boot Options Data Byte DMTF Document DSP0136 Field Description 6-7 Special Command Parameter Defines a command parameter to augment the Special Command. See Special Command Definitions below for more detail. Parameter byte 1 is present in Data Byte 6; parameter byte 2 is present in Data Byte 7. 8-9 Boot Options Bit Mask Defines a standard set of firmware operations. See Boot Options Bit Mask below for more detail.
Alert Standard Format (ASF) Specification v2.0 Boot Options Data Byte Boot Options Bit Mask Byte 8 1 Bit Number 2 Boot Options Bit Mask Description 7 Reserved for future definition by this specification, set to 0b. 6 Lock Sleep Button. When set to 1b, the managed client’s firmware disables the sleep button operation for the system, normally until the next boot cycle. Client instrumentation might provide the capability to re-enable the button functionality without rebooting. 5 Lock Keyboard.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 3.2.4.3 Presence Pong (40h) A managed client sends this RMCP message — in response to a management console’s Presence Ping (80h) RMCP message — to identify the presence of an ASF-RMCP-aware managed client on the network. The Message Tag value of the Presence Ping’s RMCP Header is copied to this message’s Message Tag field.
Alert Standard Format (ASF) Specification v2.0 Data Byte(s) 12-15 16 DMTF Document DSP0136 Field Description System Firmware Capabilities Supported Defines the standard set of firmware capabilities supported by the managed client. See System Firmware Capabilities Bit Mask for detailed information. Reserved Reserved for future definition by this specification; set to 00h Special Commands Bit Mask The following table describes the special commands bit mask.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 System Firmware Capabilities Bit Mask These bit-flags identify the remote-control features supported by the system firmware. These bits are very similar to the Boot Options bit mask in the RMCP boot-related messages; see 3.2.4.1. They are slightly different because this format uses a capability bit for each encoding in the RMCP command to identify individual option support.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 3.2.4.5 System State Response (42h) A managed client sends this RMCP message in response to a management console’s System State Request (82h) RMCP message to identify the state of the managed client. The Message Tag value of the System State Request’s RMCP Header is copied to this message’s Message Tag field.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 3.2.4.6 Open Session Response (43h) A managed client sends this RSSP message to the management console in response to an Open Session Request (83h) message. Following the Status Code, Mgt Console and Managed Client Session ID fields, this message contains a single Authentication payload and a single Integrity payload. These payloads represent the proposals that the managed client selected from the list offered by the management console.
Alert Standard Format (ASF) Specification v2.0 3.2.4.11 DMTF Document DSP0136 Open Session Request (83h) A management console sends this RSSP message to the managed client to open a protected session. The client responds with an Open Session Response (43h) message. Following the Mgt Console Session ID field, this message contains one or more Authentication Payload proposals and one or more Integrity Payload proposals.
Alert Standard Format (ASF) Specification v2.0 3.2.4.13 DMTF Document DSP0136 RAKP Message 1 (C0h) A management console sends this RAKP message to the managed client to begin the session authentication process. The management console selects a Mgt Console Random Number, a Mgt Console User Role, and an optional Mgt Console User Name and sends them to the managed client along with the Managed Client Session ID specified by the client on the previous Open Session Response (44h).
Alert Standard Format (ASF) Specification v2.0 Data Byte(s) DMTF Document DSP0136 Field Description Status Code Identifies the status of the previous message. If the previous message generated an error, then only the Status Code, Reserved, and Mgt Console Session ID fields are returned. See 3.2.3.5.1 for the status codes defined for this message.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 3.2.5 RMCP Usage Scenarios The following flowchart describes the process used by the RMCP command initiator, e.g. the management console for the Capabilities Request message, to determine whether a response to a previously sent message was received.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 2. The managed client responds with an RMCP ACK, returning only an RMCP Header. Note that all values are copied from the “Request” message’s RMCP header, with the “ACK” bit set in the fourth byte. RMCP Header Vers Rsvd Seq# Class 06h 00h 05h 86h 3. The managed client responds with the associated ASF-RMCP “Response”. Note that the Message Tag value (08h) is copied from the “Request” message.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 5. The management console waits to receive an ACK from the client, but the ACK is lost; the console (again) re-transmits the “Request” message with the same Sequence Number as the original message in step 1. RMCP Header ASF-RMCP Data Vers Rsvd Seq# Class 06h 00h 05h 06h IANA Enterprise Number 00h 00h 11h Type BEh xx Tag 08h Rsvd Len xx xx 6. The managed client responds with an RMCP ACK, returning only an RMCP Header.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 3.2.6 RMCP Considerations for LAN Alert-sending Devices For the RMCP protocol to function in an OS-absent state, the alert-sending device must be capable of reporting its “network address / IP address” association to the local router. The ARP (Address Resolution Protocol), defined in [RFC1188], is typically used to accomplish this task.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 4 Firmware Interfaces A managed client’s ASF configuration and capabilities are reported by the system firmware (or BIOS) via ACPI description tables and control methods and, optionally, as static information stored within an SEEPROM. OS-present software uses this information to customize the system’s ASF-aware alert-sending device(s). An ASF-enabled system firmware provides: 1.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 4.1.1.1 Get Power-on Wait Time (GPWT) Description: Returns the current value of the system’s power-on wait time, in seconds. Input Argument(s): Output Argument(s): Power-on Wait Time (Integer) Notes: The system firmware has a single, maximum amount of time that it might wait for an ASF alert-sending device to establish connection with its transport media.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 Byte Length Byte Offset Creator ID 4 28 Vendor ID of the utility that created this table. For tables containing Definition Blocks, this is the ID for the ASL Compiler. Creator Revision 4 32 Revision of the utility that created the table. For tables containing Definition Blocks, this is the revision for the ASL Compiler.
Alert Standard Format (ASF) Specification v2.0 Offset Name Value Description BYTE Varies Identifies the minimum value (in the range 1 to 256) to which an alert-sending device’s watchdog timer should be set at power-on reset, in seconds. This value also reflects the maximum amount of time the system firmware requires to reset the initial system boot-failure watchdog timer.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 1. to ensure that an alert sending device does not dominate the SMBus 2. to ensure that every sensor in the system is polled within a reasonable time. To achieve these goals the Minimum Inter-poll Wait Time specifies the amount of time, in 5 millisecond units, an alert-sending device must wait between the completion of one event-polling cycle to the start of the next.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 4.1.2.2 ASF_ALRT Legacy sensor devices might be used in a system to provide ASF-compatible alert capabilities. This (optional) data block provides the alert-sending device’s OS-present configuration software with the information needed to poll those devices over the SMBus to determine if an alertcondition has been met.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 For example, a system implementation might include a case intrusion sensor (first event), a processor presence sensor (second event), and an over-temperature sensor (third event). If that system's ASF_ALRT structure's Assertion Event Mask is set to 02h and the De-assertion Event Mask is set to 01h, then an alert-sending device transmits only the assertion of a case intrusion event, only the de-assertion of a processor presence event (i.
Alert Standard Format (ASF) Specification v2.0 Offset DMTF Document DSP0136 Name Length Value Description 04h Alertn, Event Sensor Type BYTE Varies The value to be set7 into the alert’s Event Sensor Type field (see [PET] for definitions.) 05h Alertn, Event Type BYTE Varies The value to be set7 into the alert’s Event Type field (see [PET] for definitions.) 06h Alertn, Event Offset BYTE Varies The value to be set7 into the alert’s Event Offset field (see [PET] for definitions.
Alert Standard Format (ASF) Specification v2.0 Offset DMTF Document DSP0136 Name Length Value Description 00h Number of Controls (n) BYTE Varies Identifies the number of m-byte remote-control entries that follow. 01h Array Element Length (m) BYTE 05h Identifies the size (in bytes) of each Control Array element. For ASF version 1.0 and later, this field is set to a minimum of 04h (4). 02h Reserved WORD 0000h Reserved for future definition by this specification.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 4.1.2.6 ASF_RMCP This information record’s presence within a managed client’s ACPI implementation implies that the client supports ASF-RMCP remote-control capabilities and captures the RMCP boot options processed by the system firmware on its most recent boot of the system. The firmware provides the captured boot options to allow other system boot agents (e.g. PXE images, hard-disk boot managers) to also make use of the data.
Alert Standard Format (ASF) Specification v2.0 Offset Name DMTF Document DSP0136 Length Value Description 0Dh RMCP Special Command Parameter 2 BYTEs Varies Contains the two-byte Special Command Parameter value present in the RMCP command processed by the system firmware on its most recent boot of the system. Command parameter data byte 1 is present at offset 0Dh; data byte 2 is present at offset 0Eh.
Alert Standard Format (ASF) Specification v2.0 Type = Reserved = Length = Offset DMTF Document DSP0136 04h or 84h 00h 4 + 2 + n, where n is the number of fixed-address devices, for ASF Version 1.0.
Alert Standard Format (ASF) Specification v2.0 4.3 DMTF Document DSP0136 SMBus Serial EEPROM (SEEPROM) An implementation might choose to identify all or part of the managed client’s fixed SMBus addresses and legacy access-methods using data structures present in an SMBus-attached SEEPROM whose address is specified in the SEEPROM Address field of the ASF_ADDR structure (see 4.1.2.7).
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 4.3.3 ASF Remote Control (SEEPROM Record Type 08h) A record header of the following format (as defined by [FRU]) identifies an ASF Remote Control record: Offset Format Description 00h BYTE Record Type ID. Set to 08h to identify an ASF Remote Control record. 01h BYTE Bit(s) 7 6:4 3:0 02h BYTE Record Length. Identifies the length of the ASF Remote Control record that follows, not including this record header.
Alert Standard Format (ASF) Specification v2.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 Note: The values associated with the Wr, Command, Byte Count, Sub-command, Version Number, A, and ~A fields for each of the messages in this section are each specified in binary format with no trailing letter ‘b’. 5.1 Alert-related Messages SMBus messages defined in this sub-section convey alert-related information to the alert-sending device, which usually results in a PET frame being transmitted.
Alert Standard Format (ASF) Specification v2.0 Status Value “Get Event Status” Rd Byte Count 0000b DMTF Document DSP0136 Status Type Status Description 0Bh to 10h9 Deasserted (no send) The event is in the deasserted state, but the ASF-sensor does not want a PET to be sent on this condition. This will typically be used when a device sets its initial status upon initialization.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 5.1.1.1 Get Event Data The Get Event Data message is used to poll ASF-sensors for individual event (specified by Event Status Index) status and associated PET field values. Note: If an ASF-sensor receives a Get Event Data message with an Event Status Index that is out of range (see 5.1.1), the sensor responds with the Status field value set to Event Status End. This message uses the SMBus 2.
Alert Standard Format (ASF) Specification v2.0 8 Wr Data 1 Sub Command Get Event Data 0001 0001 DMTF Document DSP0136 1 A 0 8 Wr Data 2 Version Number 0001 0000 1 A 0 8 Wr Data 3 Event Status Index 11 00bb bbbb 1 Sr 7 Slave Address ASF-sensor Address 1 Rd 1 1 A 0 1 A 0 8 Rd Data1 Status 1 A 0 8 Rd Byte Count 0000 0001 1 A 0 8 PEC [data dependent] 8 Wr Data 4 Reserved 0000 0000 1 A 0 1 A 0 ••• ••• 1 ~A 1 1 P 5.1.1.
Alert Standard Format (ASF) Specification v2.0 8 Rd Data1 Event Status Count 8 Rd Data N Status 2*(N-2)1/2*(N-2) DMTF Document DSP0136 1 A 0 8 Rd Data2 Status 1/0 1 A 0 8 PEC [data dependent] 1 A 0 1 ~A 1 ••• 1 P 5.1.2 Asynchronous Alert Notification to SMBus Host This message notifies the SMBus host or an Auxiliary Management Device of a pending alert, and provides a common context that conforms to the strict rules for communicating with the system SMBus host.
Alert Standard Format (ASF) Specification v2.0 Field Name Bit(s) 3:0 Alert Value 7:0 DMTF Document DSP0136 Meaning Specified by the Interface Class. The combination of the Interface Class value and this field’s value defines the interpretation of the Alert Value field. • For Interface Class = 000b (ASF), the field contains the Notification Type, one of: 0h Reserved for future Alert-sending Device Receive Message Notification 1h Reserved for future Alert-sending Device Transmit Message Notification.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 • This following format of the asynchronous notification includes a PEC byte. The notifying device uses this format when the device sends a notification to an Auxiliary Management Device.
Alert Standard Format (ASF) Specification v2.0 Field Name Bit(s) 0 Auxiliary Management Device Address 2 7:0 DMTF Document DSP0136 Meaning Address Write Enable. If set to 1b, the device records the SMBus Address supplied on an SMBus write message as a target of Push Alert or Asynchronous Event Notification messages; otherwise (0b), the device preserves any previously set address. This field uses the same format as Auxiliary Management Device Address 1, defined above.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 5.1.4.1 Start Watchdog Timer This message starts the watchdog timer in the alert-sending device, sets the timer’s expiration time, and contains the information needed for the alert-sending device to form the PET frame if the timer expires. An alert-sending device performs the following steps when it receives a Start Watchdog Timer message: 1. Stop the watchdog timer, if it is currently running.
Alert Standard Format (ASF) Specification v2.0 1 S 7 Slave Address Alert-sending Device Address 8 Data1 Sub Command Stop Watchdog Timer 0001 0100 DMTF Document DSP0136 1 Wr 0 1 A 0 1 A 0 8 Command Management Control 0000 0010 8 Data2 Version Number 0001 0000 1 A 0 1 A 0 8 Byte Count 0000 0010 8 PEC [data dependent] 1 A 0 1 A 0 ••• 1 P 5.1.
Alert Standard Format (ASF) Specification v2.0 8 Data9 Sensor Number 1 A 0 8 Data10 Entity 1 A 0 DMTF Document DSP0136 8 Data11 Entity Instance 1 A 0 8 PEC [data dependent] ••• From zero (0) to five (5) bytes of Event Data 1 A 0 1 P 5.1.5.2 Message without Retransmission This message causes the alert-sending device to transmit a single, un-retransmitted PET frame.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 5.2.1.1 Return Boot Options Response Refer to section 5.2.1 for a full description of the conditions under which this Get Boot Options response is returned by an alert-sending device.
Alert Standard Format (ASF) Specification v2.0 8 Data1 Sub Command Clear Boot Options 0001 0101 5.3 1 A 0 DMTF Document DSP0136 8 Data2 Version Number 0001 0000 1 A 0 8 PEC [data dependent] 1 A 0 1 P Discovery and Status Messages 5.3.1 Device Type Poll Message The Device Type Poll message allows an SMBus master to further determine the characteristics of an SMBus 2.0 device that responds to an ARP cycle with the ASF bit of its Interface byte set to 1.
Alert Standard Format (ASF) Specification v2.0 8 Data 2 Version Number 0001 0000 5.4 1 A 0 DMTF Document DSP0136 8 Data3 System State 1 A 0 8 PEC [data dependent] 1 A 0 1 P Remote-Control Device Action Message An alert-sending device forces a remote control action to the managed client via a RemoteControl Device Action message.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 6 SMBus Device Characteristics This section describes the behavior and requirements for SMBus devices that are defined by this specification, ASF-sensor, legacy-sensor, and remote-control devices. The primary differences between these device types are summarized below. Legacy-sensor devices • • • • No well-defined or commonly accepted hardware interface for providing device information (e.g. manufacturer, class, etc.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 4. All status bits returned by the device (in the Read Result data byte response to an SMBus Byte Read message) that are set to 1b within the device’s ASF_ALERTDATA Alert Data Mask must always be valid, regardless of the power state of the function monitored by that status bit.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 A. Bit Mask De-assertion Event – true if all of the following are true: i) Bit 0 of the entry’s Alert Device Address field is cleared (0b). ii) The entire current status is cleared and any bit in the past status is set. B. Compare Byte De-assertion Event – true if all of the following are true: i) Bit 0 of the entry’s Alert Device Address field is set (1b).
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 connection by the device. For example, ASF (bit 5) and IPMI. Subsystem Vendor ID This field may hold a value derived from any of several sources: • The device manufacturer’s ID as assigned by the SBS Implementers’ Forum or the PCI SIG. • The device OEM’s ID as assigned by the SBS Implementers’ Forum or the PCI SIG.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 Host Clear C D Q Host Alert Register Poll Alert Register Event 6.2.4 Device Power On Reset Time ASF-sensor and remote-control devices are allowed up to 500ms to complete their Power On Reset once they have detected that their supply power is stable. These devices don’t appear on the SMBus (i.e. a NACK is generated for the associated slave address) before the device is prepared to communicate.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 Reset The reset function causes a low latency reset of the system. This reset must, at a minimum, reset the host processor(s) and cause PCI Reset# to be asserted so that all devices on the PCI bus are initialized. If supported, the reset function is required to produce the reset in these system states: • S0/G0 “working” • S1 • S2 • S3 • Legacy ON state.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 • S2 • S3 • Legacy ON state • Sleeping in an S1, S2, or S3 state, or Legacy SLEEP • G1 sleeping. Operation in all other system states is undefined by this specification.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 Appendix A Additions to PET Specification 1.0 A.1 Modem Support There needs to be a new entry for the Trap Source Type and Event Source type for Modems. 60h – 67h A.2 Battery Sensor To support system battery-related events a new Event Sensor Type along with a set of Sensorspecific Offsets should be added as follows: Battery 29h 00h Battery low 01h Battery failure 02h Battery presence detected A.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 Table , Entity Instance Number Bit Description 7 0 = physical entity, 1 = logical entity 6:0 Entity Instance number 00h-5Fh = system relative 60h-7Fh = sensor device relative 00h-5Fh = System Relative. Instance number must be unique for each different entity of type Entity ID in the system. This range is used for devices that have a fixed enumeration (i.e. Not add in cards) 60h-7Fh = Sensor Device Relative.
Alert Standard Format (ASF) Specification v2.0 Code 26d DMTF Document DSP0136 Entity Disk Drive Bay 27d Peripheral Bay 28d Device Bay 29d fan / cooling device 30d cooling unit (can be used as a pre-defined logical entity for grouping fans or other cooling devices) 31d cable / interconnect 32d memory device (This Entity ID should be used for replaceable memory devices, e.g. DIMM/SIMM. It is recommended that Entity IDs not be used for individual nonreplaceable memory devices.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 Appendix B ASF Entity Section Map This section identifies the relevant ASF specification sections for each type of ASF entity: B.1 Alert Sending Device 3.1.1 PET Frame Behavior 3.1.2 Agent Address Field 3.1.3 Specific Trap Field 3.1.4 Variable Bindings Fields 3.1.5.5 System Heartbeat 3.1.5.6 System Boot Failure 3.2.5 RMCP Usage Scenarios 4.1.2.1 ASF_INFO 4.1.2.2 ASF_ALRT 4.1.2.3 ASF_ALERTDATA 4.1.2.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 4.1.2.1 ASF_INFO 5.1.1.1 Get Event Data 5.1.1.2 Get Event Status 6 SMBus Device Characteristics 6.2 ASF-Sensor Devices 6.2.1 Device Identification 6.2.2 Event Generation and Clearing 6.2.3 Alert Status 6.2.4 Device Power On Reset Time B.4 Remote Control Device 4.1.2.5 ASF_CONTROLDATA 6 SMBus Device Characteristics 6.3.1 Device Requirements 6.3.2 Usage of Firmware Remote Control Device Information 6.3.3 Remote Control Functions B.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 4.1.2.2 ASF_ALRT 4.1.2.3 ASF_ALERTDATA 4.1.2.4 ASF_RCTL 4.1.2.5 ASF_CONTROLDATA 4.1.2.7 5.1.4.1 Start Watchdog Timer 5.1.4.2 Stop Watchdog Timer 5.3.1 Device Type Poll Message B.8 Remote Console Software 3.1.1 PET Frame Behavior 3.1.2 Agent Address Field 3.1.3 Specific Trap Field 3.1.4 Variable Bindings Fields 3.2.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 Appendix C ASF Entity Function Checklists This section contains the entity-specific checklists that define requirements and recommendations for an ASF implementation. C.1 Alert Sending Device The following table identifies the required and optional features for an ASF alert-sending device. See also C.2 Local Alert-Sending Device Configuration Software.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 #### Description AS20 The device responds to the SMBus Set System State message (see 5.3.2) and returns the last value written in response to an RMCP System State Request (see 3.2.4.10). If no value is written by the system firmware, the device responds with a System State value of “Unknown”.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 C.3 Legacy Sensor The following table identifies the required and optional features for an ASF legacy sensor. Table D-3 Legacy Sensor Checklist for ASF Implementations #### Description LS1 The alert associated with each sensor contained in the device must be pollable via an SMBus Byte Read command.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 #### Description RD2 The remote-control action is initiated immediately after the alert-sending device sends the associated Byte Write SMBus message. Required RD3 The device supports its associated remote-control action as described in section 6.3.3. Required RD4 The device supports SMBus PEC protocols. Optional C.
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 #### Description SF51 The system identifies all fixed-address SMBus devices that are undiscoverable, including legacy devices, using a Fixed SMBus Addresses (SEEPROM Record Type 06h) record in an SMBus SEEPROM. Optional SF52 The system identifies all fixed-address SMBus devices, even those that are discoverable.