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
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 reprioritized to reflect the SCOPE Alliance
profile. A few other requirements have also been added (visit
www.linuxfoundation.org
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 Riverwas 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 Foundationis 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 Allianceis 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.