ASF Spec Pools IP Device Management

By Cameron Sturdevant  |  Posted 2001-05-28 Print this article Print

By the end of the year, it managers will start to see the first wave of hardware devices that can be uniformly managed before the operating system slogs through the boot-up process, thanks to the new Alert Standard Forum specification from the Distributed

By the end of the year, it managers will start to see the first wave of hardware devices that can be uniformly managed before the operating system slogs through the boot-up process, thanks to the new Alert Standard Forum specification from the Distributed Management Task Force.

This is good news: Because the ASF specification covers any IP- capable device—not just PCs and servers—while also establishing a uniform standard for alerting, monitoring and controlling remote systems, most sites should be able to whittle down the number of management consoles currently needed to just one or two.

Released last month as a preliminary standard, the ASF specification (details are available at could become an official DMTF standard as early as this summer. At that time, eWeek Labs believes administrators should place ASF compliance at the top of their list of requirements for any new server, router, appliance or other infrastructure device.

The latest iteration of the standard proposal defines the message formats and transmission protocols for alerting and corrective action for various hardware products, including add-in cards, SMBIOS (SMB Internetwork Operating System, a local interface to reach system management information) sensors, system servers, operating systems and management platforms.

If it becomes widely adopted, ASF should promote the interoperable management of these devices and software products.

ASF uses bit-based transmission protocols, including SNMP and User Datagram Protocol, all tried and true in the management arena. This should make ASF fit comfortably amid the network and system management products that IT managers are already using.

In addition, because ASF was developed by the DMTF, it interoperates with Common Information Model; this means that basic ASF information could also be abstracted to operating-system-present Extensible Markup Language formats, which would allow managers detailed access to remote systems.

And now the bad news: With this power and convenience come new avenues for attacks.

Based on our reading of the specification, ASF is built with an overly large reliance on trust that operators and machines are who and what they say they are. This is especially true when it comes to issuing maintenance commands, which can force devices to reboot or shut down altogether. Managers should keep these weaknesses in mind when rolling out systems that contain active ASF elements.

PET Sounds

ASF defines alert messages that are sent from the client system to the management console, remote maintenance requests that are sent to the client, data descriptions of client-specific capabilities, and an interface to software that is used to configure or control the client when the operating system is present.

When an ASF-capable device, such as an Ethernet card or sensor, is added to a system, the specification currently requires that the system perform at least one normal boot. This reboot allows the device configuration software to run and store system information in nonvolatile memory. Future versions will likely overcome this limitation by permitting configuration data to be stored without cycling the system.

ASF alerts are sent as a PET (Platform Event Trap) that is presumed to be sent on an IP network. IPX is supported as an option, as are other network transport protocols. However, ASF is also IP-centric and requires that the device sending the alert always support the IP address scheme.

The DMTF appears to have worked out a way for ASF to provide enough specific management information without falling into the trap of being a Trojan horse for one or another vendor. A healthy cross-section of interested parties—including 3Com Corp., Cisco Systems Inc. and Tivoli Systems Inc.—seems to be playing nicely together to ensure that the specification will be widely used.

Cameron Sturdevant Cameron Sturdevant is the executive editor of Enterprise Networking Planet. Prior to ENP, Cameron was technical analyst at PCWeek Labs, starting in 1997. Cameron finished up as the eWEEK Labs Technical Director in 2012. Before his extensive labs tenure Cameron paid his IT dues working in technical support and sales engineering at a software publishing firm . Cameron also spent two years with a database development firm, integrating applications with mainframe legacy programs. Cameron's areas of expertise include virtual and physical IT infrastructure, cloud computing, enterprise networking and mobility. In addition to reviews, Cameron has covered monolithic enterprise management systems throughout their lifecycles, providing the eWEEK reader with all-important history and context. Cameron takes special care in cultivating his IT manager contacts, to ensure that his analysis is grounded in real-world concern. Follow Cameron on Twitter at csturdevant, or reach him by email at

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel