RTC Magazine

Service availability requirements for services implemented by network equipment providers (NEPs) can be as high as 99.99999% (seven nines equates to unavailability of approximately 3 sec/year), when taking network redundancy into account. The availability requirement for applications providing service in a single network element can vary between 99.9% and 99.999% or better (five nines equates to unavailability of approximately 5 min/year).

The SCOPE Alliance has defined a reference architecture for a generic Carrier Grade Base Platform (CGBP) that is documented in a published technical position paper available on the SCOPE Alliance Web site. This architecture, which includes hardware, operating system, operations and maintenance functions and tools, also specifies CGBP Middleware (or just “middleware” for short) as a fundamental component for service availability. This middleware is architecturally positioned on top of the operating system but underlying higher level services such as databases, protocols and application servers. The functions of the middleware include high-availability (HA) services, hardware management, software management (including software lifecycle management and live software upgrade), naming services, notification services, basic security, logging services and others. Having all of these available as open specification, for the most part, is essential to make the CGBP a stand-alone entity that can be integrated from a diverse and rich COTS supplier ecosystem

To achieve the required high levels of service availability, application services are built on top of the CGBP in a manner such that the application software is aware of the high-availability services provided by the CGBP but is not closely tied to the underlying hardware. On the hardware level, redundant resources are used to prevent service outages caused by any hardware failure.

The CGBP Middleware Profile Version 1.0

The Service Availability Forum (SA Forum) is the main organization active in the middleware standardization effort. Therefore, initially the SCOPE Alliance focused on profiling the existing SA Forum recommendations. The two cases to consider in the SCOPE middleware profile were:

• What SA Forum-defined services would be mandatory/desirable/nice-to-have as supplied by middleware product provided for NEPs to use in constructing their own products?

• What middleware services should third-party software vendors develop against in their products in order to allow NEPs to integrate those products with the CGBP middleware and the rest of the system?

The most important SA Forum services in both lists were the Availability Management Framework (AMF), Notification Service (NTF) and Logging (LOG). The main difference was Cluster Management (CLM): it is a key service for a middleware product to provide, but it is not mandatory that third-party software would subscribe to the same cluster view. This profile is publicly available at the SCOPE Alliance Web site.

The CGBP Middleware Profile Version 2.0

While the CGBP Middleware Profile Version 1.0 focused on the defined services, Version 2.0 now under construction will extend this to identify missing or insufficient capabilities that NEPs would like to see addressed by the SA Forum and middleware providers. The initial focus of the SCOPE Alliance in the CGBP middleware space has been in HA Services and closely related functionality.

• A few services provide useful capabilities but were not specified in a way that would allow for a high-performance implementation. The message service (MSG) is one such example: while messaging could be a very important integrating service that a middleware provides, the current SA Forum messaging service stipulates such high reliability that the implementation cannot perform well enough to yield cost-effective solutions. Therefore, high-performance messaging is a clear gap.

• Another example is checkpointing: many telecom applications require very fast failover, which the current SA Forum CKPT cannot provide for some classes of applications.

• While notifications (NTF) are an important integrating service, the event service (EVT) was not deemed important. The main reason is that NTF defines semantics for the message, while EVT does not. Thus, there is a gap in the semantics for system-wide event channels with defined syntax and semantics.

• Completely missing capabilities that were identified include trace, statistics and measurements. These would provide a standard way to provide tracing information and to collect middleware-level statistics or measurements.

• A cluster-level debugging service and tools would be valuable to improve NEP integration and development activities. Such a capability, when integrated with middleware, could, for instance, stop component health-checking while the system is stopped for debugging.

• Mechanisms for handling overload would be beneficial since this is a big source of service outages. Defined services to detect, report and manage overload conditions are important framework capabilities. While the policy of deciding what to do during an overload is up to the application, there can be a generic service to collect the measurements, report when an overload situation is imminent, and provide a framework for overload notification.

In summary, the SCOPE Alliance has identified HA services as a key capability that NEPs would like to source from an open COTS ecosystem. These services take the form of the middleware component of the Alliance’s CGBP Reference architecture and are fundamental to achieve stringent levels of service availability. Through two distinct publications, the Alliance prioritizes and suggests necessary extensions to the CGBP middleware services that have currently been defined by the SA Forum.

The SCOPE Alliance.
[www.scope-alliance.org].