Advertisement

OpenSAF in emerging telecom specs

OpenSAF provides open-source service availability middleware and interfaces

BY JOHN FRYER and STUART JAMIESON
Emerson Network Power, Embedded Computing
Tempe, AZ
http://www.emersonnetworkpowerembeddedcomputing.com

Platforms based on open specifications for hardware and software make it easier for telecom OEMs to outsource their equipment design, focus on their core differentiation, and rapidly develop new services for their carrier customers. One key piece of this effort is the OpenSAF initiative (OpenSAF.org) which is creating open-source middleware for high-availability system designs.

A host of industry consortia are working to define open specifications for telecom system design, covering hardware, software, system integration, and high-availability design. These efforts follow the same basic structure as the system design itself, with each layer requiring its own set of specifications. Emerging from this combined effort has been an entire ecosystem—with some groups addressing the needs of a specific layer and other groups addressing the interfaces between layers, as well as testing and overall coordination.

The telecom open specifications ecosystem

The telecom open specifications structure starts with specifications for open platform building blocks (see Fig. 1 ), including the interfaces between those blocks. Both hardware and software building blocks have been specified. The PCI Industrial Computer Manufacturer’s Group (PICMG, www.picmg.org) is responsible for hardware specifications such as AdvancedTCA, MicroTCA, and Advanced Mezzanine Card.

The software building blocks start with the carrier-grade Linux Operating system, handled by the Linux Foundation (www.linux-foundation.org). The LF develops requirements that can then be implemented and contributed to the Linux kernel community.

Service availability middleware extends the OS, providing high availability features such as failure detection, fail-over, and hot-swap management along with interprocess communications. The Service Availability Forum (SA Forum, www.saforum.org) is the organization tackling the specific needs of high-availability system design, and is defining the management functions and interfaces that the hardware and software building blocks must offer. It is in this area that OpenSAF has been formed to address a number of key issues.

OpenSAF in emerging telecom specs

Fig. 1. The MVA acts as an umbrella organization, primarily coordinating marketing support and ensuring that all parties are working towards developing a comprehensive set of open specifications.

To help direct the implementation of telecom hardware and software building blocks, the telecom industry itself has begun defining reference system profiles. These profiles, created by the SCOPE Alliance (www.scope-alliance.org), outline the hardware and software needs of various types of telecom equipment, identifying specification gaps and prioritizing requirements. The Open Communication Architecture Forum (OCAF, www.itu.int/ITU-T/ocaf/) Focus Group of the International Telecommunications Union (ITU, www.itu.int) developed a similar set of references to guide development of application interface specifications that are now driven by SCOPE.

While these specifications and references go a long way toward ensuring that developers will produce building blocks that system integrators can combine as needed, they do leave some details open to interpretation. Such ambiguity can result in interoperability problems. To address these issues, and to ensure that developers properly adhere to the standards, various industry groups are offering component testing and certification as well as system-wide testing. PICMG, for example, runs a series of hardware interoperability workshops. And, the Communications Platform Trade Association (CP-TA, www.cp-ta.org) focuses specifically on hardware and software interoperability, providing testing structures and methodologies to aid the integration of ATCA, AMC, and MicroTCA products for vendors and customers alike.

With such a complex specification ecosystem and multiple organizations working independently, there is a big risk that these efforts may diverge, compete, or work at cross purposes to telecom OEM needs. To coordinate and gain synergy from their efforts, these organizations have come together to form the Mountain View Alliance (MVA, www.mountainviewalliance.org). The MVA acts as an umbrella organization, primarily coordinating marketing support and ensuring that all parties are working towards developing a comprehensive set of open specifications.

Service availability middleware

All these efforts aim to make telecom system design easier and less expensive by supporting the creation of open-system building blocks that OEMs can utilize. Until recently a key telecom building block has been missing from the open-system market: service availability middleware (see Fig. 2 ). The SA Forum has defined open specifications for service availability middleware. The middleware implementation, however, had remained proprietary.

OpenSAF in emerging telecom specs

Fig. 2. Service availability middleware is a critical system building block that has only recently become available as an open-source implementation.

That began to change in 2007 when Motorola’s embedded communications computing group (now the Embedded Computing business of Emerson Network Power) announced the creation of an open source high availability operating environment based on SA Forum specifications. The company then turned its implementation over to a new industry-wide consortium—the OpenSAF Foundation—to promote and develop this open specification base platform middleware. OpenSAF was founded by Emerson Network Power, Ericsson, HP, Nokia Siemens Networks and Sun Microsystems. The organization fits into the telecom specification environment as a provider of an open source middleware that is aligned with SA Forum specifications as well as SCOPE Alliance recommendations.

The initial structure of the OpenSAF implementation includes the service availability middleware and interfaces to both the application software on top and to the hardware and software underlying the system design. Specifically, the hardware platform interface (HPI) provides a standard mechanism to access information specific to a hardware architecture. The application interface specification (AIS) layer is meant to couple the application software with the system platform (see Fig. 3 ).

OpenSAF in emerging telecom specs

Fig. 3. The OpenSAF implementation provides a set of functions necessary in a high-availability base platform.

The implementation’s service availability middleware functions include the six services specified by the SA Forum’s Application Interface Specification version B.01.01 and a set of additional capabilities necessary for a working implementation:

System Description Service – An XML-based definition of software and hardware components in the OpenSAF middleware that helps configuration of start up and shutdown sequences, and defines automated recovery and repair policies.Availability Manager – Helps automate fail-over and recovery of hardware and software in sub-second time and ensure system reliability with fault detection, fault isolation, fault recovery, and fault repair along with system-level fault management.Message Distribution Service – A peer-to-peer messaging service.Message Based Checkpoint Service – Supports efficient replication of large data sets, for rapid transition from standby to active. Management Access Service System – Provides a system-wide access point for all management operations as well as a Command Line Interface (CLI) plus SNMP.OpenSAF SNMP Subagent – A common SNMP interface for the applications/users to manage the set of services provided by OpenSAF.Persistent Store Service – Provides mechanisms to store the configuration information of client applications persistently.System Resource Monitor – Allows applications to subscribe to this service and receive alerts, including monitoring and system resources and notifying applications of constraints. Distributed Tracing Service – Provides a mechanism for applications to post fault related information.HPI Integration Service – Makes HPI events accessible to other OpenSAF services and applications. ■

For more on open hardware and software specs, visit www.electronicproducts.com/digital.asp and www.electronicproducts.com/software.asp.

Advertisement



Learn more about Emerson Network Power – Connectivity Solutions

Leave a Reply