ASF Specification v2.0 DSP0136 - DMTF
ASF Specification v2.0 DSP0136 - DMTF
ASF Specification v2.0 DSP0136 - DMTF
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Alert Standard Format (<strong>ASF</strong>) <strong>Specification</strong> <strong>v2.0</strong><br />
<strong>DMTF</strong> Document <strong>DSP0136</strong><br />
Status<br />
Code<br />
10h-<br />
FFh<br />
Description<br />
Reserved for future definition by this specification<br />
Message<br />
43h 44h C1h C2h<br />
3.2.4 RMCP “<strong>ASF</strong>” Message Types<br />
This section defines message data formats for the standard RMCP “<strong>ASF</strong>” class (i.e. the IANA<br />
Enterprise Number in the RMCP Data section is 4542). This specification defines the Data<br />
portion of each message; OEMs and ISVs can provide extensions using the general RMCP “<strong>ASF</strong>”<br />
class, but cannot extend the standard messages’ packet size.<br />
3.2.4.1 Reset (10h), Power-up (11h), and Power Cycle Reset (13h)<br />
A management console can send these RMCP messages to cause a managed client to perform<br />
a hard-reset, power up, or power cycle reset. See section 6.3.3 for detailed descriptions and<br />
definitions of these remote control functions.<br />
Each of these message types can optionally include Boot Options in its variable data; the options<br />
define operations a managed client performs with the boot initiated by the RMCP message. The<br />
RMCP message’s Data Length value indicates the presence (0Bh or greater) or absence (00h) of<br />
the options. The Boot Options contain a bit-mask of standard options and a Special Command<br />
with an optional parameter.<br />
If a managed client doesn’t support the message (as indicated on the presumed, previous<br />
response to the console’s Capabilities Request message), the alert-sending device issues an<br />
RMCP Acknowledge and otherwise disregards the message. Any message disregarded in this<br />
fashion has no effect on the alert-sending device’s response to a subsequently issued SMBus<br />
Get Boot Options message (see 5.2 for these messages’ definitions). Otherwise, the alertsending<br />
device records the Boot Options and Special Command values and reports those values<br />
in response to subsequently issued SMBus Get Boot Options messages until either<br />
1. The alert-sending device receives another RMCP message, supported by the system. This<br />
message’s Boot Options and Special Command values replace the previously recorded<br />
values.<br />
2. The alert-sending device receives an SMBus Boot Options Clear message (see 5.2.2 for<br />
details). Until the alert-sending device receives another RMCP message with Boot Options<br />
values, the device responds with the No Boot Options response to any SMBus Get Boot<br />
Options messages.<br />
When the Boot Options are present, the message’s Data field is organized as follows:<br />
Boot<br />
Options<br />
Data Byte<br />
Field<br />
Description<br />
1-4 IANA Enterprise<br />
Number<br />
IANA-assigned Enterprise Number — <strong>ASF</strong> (4542) or OEM specific<br />
— that defines the interpretation of the OEM Special Command<br />
values and their associated Special Command Parameters, and<br />
the OEM Parameters fields.<br />
Note: This specification defines the interpretation of the Boot<br />
Options Bit Mask field, regardless of the Enterprise Number value.<br />
5 Special Command Defines commands to be processed by the managed client on the<br />
boot initiated by the <strong>ASF</strong>-RMCP message. See Special Command<br />
Definitions below for more detail.<br />
<strong>DSP0136</strong> 23 April 2003 Page 33 of 94
Change language