Carrier Grade Linux 4.0 – Raising the bar

See also: Electronics Weekly’s Focus on Linux, a roundup of content related to the open source operating system shaped for industrial uses.

Standards-based technologies are rapidly being adopted by the telecommunications industry, and for good reason, writes Glenn Seiler of WindRiver.

Standards-based technologies are rapidly being adopted by the telecommunications industry, and for good reason. Using standards-based solutions allows telecom equipment manufacturers (TEMs) and network equipment providers (NEPs) to use commercial off-the-shelf (COTS) hardware and software systems across multiple network elements – speeding time-to-market, saving money, and freeing up key resources to focus on competitive differentiation.

Equally important, the adoption of standards-based elements enables new and emerging hardware to plug into an existing network infrastructure without extensive retooling and associated costs. It also encourages use of best-of-breed technologies without imposing vendor lock-in.

For much of the new hardware being deployed in next generation networking (NGN) infrastructures, the de facto standard is the Advanced Telecommunications Computing Architecture (ATCA). This is a perfect example of a standard that not only promises all the benefits of a COTS solution, but has also reached a point of maturity for wide use in real-world implementations.

Getting standards-based technologies to deliver on their intended promise requires heavy lifting and cooperation. For many industries, such as mobile phones, the proliferation of special interest groups (SIGs) has led to overlap and competing standards, resulting in a splintered, confused industry and delays in standards adoption.

In the communications industry, however, there is significant cooperation between different SIGs. In telecommunications, nearly a dozen SIGs have worked to define the technology components that fit into an overall solution. Some of the most notable SIGs include the Communications Platform-Trade Association (CP-TA), PICMG, the SCOPE Alliance, the Service Availability Forum (SAF), and The Linux Foundation.

Each communication SIG has a specific function and focus: The Linux Foundation, created by a merger between the Open Source Development Labs (OSDL) and the Free Standards Group, focuses on specifications for the Linux OS; PICMG focuses on standards for ATCA hardware; the SAF focuses on middleware above the OS; and the CP-TA focuses on interoperability between different vendor implementations of hardware and software. The SCOPE Alliance doesn’t define any particular standard, but creates desired technology profiles based on Linux Foundation, PICMG, and SAF specifications.

Unlike in many other industries, communications SIGs work closely together. The CGL specification developed by The Linux Foundation includes some standards defined by the SAF and specifies support for ATCA. A loose consortium, the Mountain View Alliance, provides a liaison, marketing, and awareness function for all communications SIGs.

A Brief History of Carrier Grade Linux

A – X of Linux
A Android
B Broadcom and LiMo
C Carrier Grade Linux
D Driving automotive
E Ericsson 3G
F Free software embedded
G Google G1
H How to migrate
I Intel
J Jumping on board
L Lumin ary Micro
M Mobile Linux
N Nokia does battle
O Open Source engineering
P Power shift
Q Qualcomm
R RTOS versus Linux
S Stallman
T Tivo-isation
U UK radio mapping
V VirtualLogix VLX
W 2 Watt green PC
X Xilinx adds Linux
Spelling out GNU and Linux stories

Carrier Grade Linux (CGL) is the operating system of choice for ATCA-based network equipment and is considered the architectural “hub” that defines many telecom solutions. CGL is designed to support all the hardware capabilities (such as booting from flash or support for ATCA hot-plug, along with high-availability middleware interfaces) to create the foundation for a complete carrier-grade solution and ensure high performance.

CGL was started by OSDL in January 2002. Equipment providers such as Nokia, Ericsson, and Alcatel, were initial members and contributors. The first two releases of the CGL spec resulted in approximately 200 requirements across five different categories: Hardware, Performance, Standards, Availability, and Serviceability. At least seven different Linux distributions claimed compliance.

In 2005, the third CGL specification, version 3.2, was created. It added two more requirements categories, Clustering and Security, growing the number of overall requirements to more than 280. However, by the time the 3.2 spec was released, the CGL Working Group realized there was no way to consistently measure how each distribution supported the CGL specification. One distribution might support the majority of requirements, while another supported only a handful.

Ultimately, while significant in scope, CGL 3.2 didn’t hit the mark in establishing a complete requirements list that met the needs of TEMs and NEPs. Many TEMs discontinued active participation in the CGL Working Group, and some in the industry wondered if the CGL specification had run its course.

Around the same time, many top-tier TEMs formed their own association, the SCOPE Alliance, to focus on hardware and software profiles they believed were most important in implementing COTS building blocks for carrier-grade-base platforms. The SCOPE Alliance quickly became an important force in the ecosystem, taking an active interest in CGL and making a conscious effort to focus on the operating system first.

This action by the SCOPE Alliance changed everything for CGL. It clearly indicated that the CGL specification was important and relevant to equipment providers – the primary consumers of CGL. It also initiated a tight working relationship between the CGL Working Group and equipment providers, a relationship that had been missing. Suddenly, the CGL specification was on a path to renewed relevance.

CGL 4.0: Tighter Alignment, Tighter Compliance

In late 2006, the CGL Working Group and members of the SCOPE Alliance joined forces to develop a new version of the CGL specification, 4.0. One of the major goals of CGL 4.0 was to align with the SCOPE Alliance Linux Profile. This profile prioritized CGL 3.2 requirements into three categories: mandatory, desired, and roadmap. This was considered a huge contribution toward moving the CGL spec forward. The users of CGL – TEMs and NEPs – provided critical input on what was absolutely required in a Linux distribution to develop ATCA-based applications.

The CGL Working Group also worked to address criticism that the specification was inconsistently implemented across distributions. In earlier spec releases, any Linux distribution that met even a few CGL requirements could claim compliance – and because The Linux Foundation (formerly OSDL) did not endorse or validate the veracity of the registration disclosure data, there was no guarantee of complete feature support. In an effort to solve this problem, the CGL Working Group created a more formal process for registering Linux software as CGL-compliant. Linux distribution providers could follow this process to ensure they delivered consistent functionality.

In February 2007, The Linux Foundation released the CGL 4.0 specification. This version does not represent a host of new technical requirements, but it highlights the unprecedented level of cooperation that led to CGL 4.0, especially between The Linux Foundation and the SCOPE Alliance. A key focus of the revised specification is to meet the needs of its primary users: equipment providers.

With CGL 4.0, when an equipment provider specifies the need for a CGL distribution, there is a consistent standard for what that means and for verifying the claim. CGL 4.0 specifies that a software distribution must meet all 135 mandatory requirements before claiming CGL compliance, guaranteeing a higher level of functionality in CGL-compliant distributions.

This major step will help accelerate growth and adoption of CGL, and further integration with ATCA-based COTS hardware, ultimately resulting in accelerated time-to-market for NEPs, TEMs, and service providers.

What’s New in CGL 4.0

In CGL 4.0, all the specifications defined in version 3.2 have been regrouped and reprioritize d to reflect the SCOPE Alliance profile. A few other requirements have also been added (visit for a complete list of CGL requirements).

Tremendous effort was required to update the specification from 3.2 to 4.0. The CGL Working Group reviewed the entire spec item by item, adding new requirements, removing old requirements, acting on change requests, correcting errata, and clarifying definitions. In some cases, an existing requirement was broken into multiple better-defined requirements. This resulted in a much clearer set of requirements that more accurately reflects the current state of Linux functionality available for carrier-grade-class systems.

CGL 4.0 comprises more than 250 individual requirements covering seven categories, or “books”: Performance, Hardware, Standards, Serviceability, Availability, Security, and Clustering. Each core member of the CGL Working Group (Hewlett-Packard, IBM, Intel, MontaVista, Motorola, NTT, and Wind River) was responsible for updating each book.

Feedback from the SCOPE Alliance was taken into account by the CGL Working Group during their edits. “SCOPE and The Linux Foundation are both committed to accelerating the deployment of carrier-grade-base platforms based on open industry specifications,” says Leslie Guth, SCOPE Alliance Marketing Co-Chair and Board Member. “With the cooperation of OSDL prior to the merger and The Linux Foundation since, we’ve worked to align the CGL specification with our released Carrier Grade Profile, and we look forward to the benefits – such as faster time-to-market – that interoperable commercial off-the-shelf building blocks bring.”

The new CGL 4.0 specification also includes useful information and resources for developers. The specific tools and APIs needed for CGL distributions are specified, and proofs of concepts (PoCs) are provided, along with reference code. The PoCs play a critical role, because they refer to existing open-source projects that can be used to implement the CGL requirement. All requirements in the specification must have an associated PoC.

In some cases, there may be multiple PoCs or other open-source projects available to meet a requirement. This has a dual impact: First, all distributions registering for CGL 4.0 will have a consistent set of features, with at least one active open-source project supporting it. Second, because there are often many ways to implement a feature, there is room for different distributions to compete and differentiate. This improves the overall quality and choice available to providers implementing CGL.

Carrier Grade Linux: Now a Linux Standard Base Workgroup

With publication of CGL 4.0 complete, The Linux Foundation is in the process of rechartering the CGL Working Group to fit the foundation’s organizational structure. The foundation plans to integrate the CGL specification into the Linux Standard Base (LSB). The LSB delivers interoperability between applications and the Linux OS. Currently, all major distributions comply with the LSB, and many leading application vendors – such as MySQL, RealNetworks, and SAP – are certifying. The LSB provides a cost-effective way for vendors to target multiple Linux distributions while building only one software package.

For end users, the LSB and its mark of interoperability preserves choice by allowing them to select the applications and distributions they want, while avoiding technology and vendor lock-in. LSB certification of distributions results in more applications being ported to Linux, and ensures that distribution vendors are compatible with those applications. The LSB ensures that Linux does not fragment.

By adding the CGL specification as a LSB certification or sub-profile, The Linux Foundation will raise the bar even further for the CGL spec, improving its already high level of credibility and value for equipment providers.

The Impact of CGL 4.0

The CGL 4.0 specification has immediate, ongoing benefits for everyone who develops, deploys, and uses Linux-based software for communications-based applications.

• For TEMs and NEPs, a unified, stable specification means faster time-to-market, investment protection, a longer life cycle for network equipment, improved interoperability, a real multi-vendor ecosystem, and streamlined compliance with environmental standards.

• For Hardware and Software COTS Vendors, reduced fragmentation of the ecosystem will motivate application vendors to produce off-the-shelf building-block components consistent with the needs of TEMs and NEPs.

• For Service Providers, CGL 4.0 means the ability to accelerate service deployment with confidence, knowing the platform is stable and delivers a high level of functionality, performance, and reliability.

• For Developers, specifying the right tools and practices for carrier-grade development, along with PoCs and reference code, simplifies and expedites the development process.

• For End Customers and End Users, the net result is equipment and services that deliver exceptional performance and availability, increased freedom of choice and quality of services, and a seamless user experience.

Glenn Seiler of Wind River was the Steering Committee Chairperson for the CGL Working Group of the OSDL and remains an active member of the new Carrier Grade Working Group of The Linux Foundation.

The Linux Foundation is a nonprofit consortium dedicated to fostering the growth of Linux. Founded in 2007 by the merger of the OSDL and the Free Standards Group, the foundation sponsors the work of Linux creator Linus Torvalds and is supported by leading Linux and open-source companies and developers around the world.

The SCOPE Alliance is an association of NEPs aimed at accelerating the deployment of carrier-grade-base platforms for service provider applications. SCOPE was founded by Alcatel, Ericsson, Lucent, Motorola, NEC, Nokia, and Siemens.

Tags: ATCA, Carrier Grade Linux, CGL, communications, PICMG, standards, Technologies

Related Tech News

Share your knowledge - Leave a comment