SA Forum specs accelerate COTS

This standardization effort is catalyzing the emergence of a strong and viable ecosystem of suppliers that provide Commercial Off-The-Shelf (COTS) components for most if not all of the layers in the stack. The TEMs can rely on this ecosystem to provide pre-tested, pre-integrated COTS components. These components are easily and cost effectively integrated to produce network elements that are standards-based, are highly reliable, and enable component reuse. Some of the obvious benefits of this approach can be realized as reduction in R&D costs, reduced project risks and shorter time to revenue.

In recent years the Service Availability Forum has made significant strides in developing and releasing specifications that standardize interfaces for the service availability middleware with the hardware layer and the application layer. The SA Forum has also begun to address standardizing the interfaces required for the manageability aspects of highly available networks elements. Commercial implementations based on these specifications are available from a variety of COTS suppliers, including hardware platform vendors and Independent Software Vendors (ISVs). A few examples of such implementations are described later in the article.

SA Forum interfaces
In the past three years the SA Forum has released and updated two sets of specifications. The Application Interface Specification (AIS) defines standard interfaces that allow application developers to write software that is interoperable and portable across multiple platforms as long as the underlying middleware is compliant with the AIS; the Hardware Platform Interface (HPI) specification enables ISVs to develop COTS components that provide hardware platform management capabilities across multiple heterogeneous platforms. In January 2006, the SA Forum released the most comprehensive set of specifications yet, providing updates to AIS and HPI, as well as an initial set of systems management capabilities---all under the umbrella of a consolidated architecture.

For an overview of AIS functionality and the state of the commercial implementation please see An In-Depth Look at SA Forum Specs and the SA Forum Web site. A brief overview of the HPI specification and example implementations follow.

HPI
Why is HPI important and what does it do for us? Consider, for an example, a High Availability (HA) middleware application that is required to manage disparate hardware platforms--presumably from different manufacturer--each richly featured with proprietary platform management capabilities. In order for the user application--the HA middleware in this case--to effectively manage a set of platforms, it must provide for distinct interfaces specific to each hardware platform. Moreover as the system grows, proprietary interfaces must be developed to exploit the hardware management capabilities of each new and distinct platform (See Figure 1).

HPI eliminates the need to develop such proprietary interface software by defining standards for implementing the hardware management functionality in the platform, and interfaces for accessing such information from the platform in a manner that is hardware independent (See Figure 2).

At the highest level, HPI provides functionality to address three major resource management areas for a given hardware platform:

• Resource discovery and the ability to provision the hardware resources that are present and configurable.
• The ability to monitor such resources for health and performance.
• Management of the configured resources so appropriate fault management policies can be implemented in case of failure.

A subset of available functionality that supports these platform resource management areas is briefly described here.

Resource discovery
HPI allows user applications to enumerate the set of hardware elements that are present and manageable within the system along with the set of management capabilities those elements possess. HPI defines three essential concepts related to hardware elements:

Entity represents a hardware element that has a unique identifier and a set of associated management capabilities; Resource provides access to the management capabilities of one or more hardware entities; Field Replaceable Unit (FRU) is a special type of HPI resource which can be inserted and extracted from the system while power is applied to the system, i.e., it can be hot swapped in or out of the system.

Page 2: next page
Page 1 | 2 | 3 | 4