Included in the ecosystem are PICMG, CP-TA, the SCOPE Alliance, Service Availability Forum, and The Linux Foundation. By way of introduction, Here's a brief overview of each of the players in the ecosystem and in the roundtable discussion:

• PICMG, founded in 1994, is a consortium of companies that collaboratively develop open specifications for high-performance telecommunications and industrial computing applications. PICMG is represented by Rob Davidson, Vice President of Marketing for PICMG.
• CP-TA is an association of communications platforms and building block providers with a goal of accelerating the adoption of SIG-governed, open specification-based communications platforms through interoperability testing and certification. CP-TA is represented by Sven Freudenfeld, Vice President and Marketing Chairman for the group.
• The SCOPE Alliance is committed to accelerating deployment of carrier-grade base platforms for service provider applications. Chris Wardale, Board Vice Chair for SCOPE is present.
• The Service Availability Forum (SA Forum) supports the broad adoption of open standards by developing missing standard interfaces necessary to deliver highly available carrier-grade systems with off-the-shelf hardware platforms, middleware, and service applications. Asif Naseem, President of the SA Forum joins the discussion.
• The Linux Foundation helps close the gap between open source and proprietary platforms. The Carrier Linux work group was formed in 2002 and was hosted by OSDL. When OSDL merged into the Linux foundation, the Carrier Grade Linux work group continued its work. Dan Cauchy, Chairman of Carrier Grade Linux Workgroup for Linux Foundation represents the group.

The organizations were not initially created to work together. The ecosystem instead is the product of a gradual evolution that has, in the past three years, been picking up steam. What follows is a conversation that helps to define each group, how they work separately and together to form this extremely valuable service.

CommsDesign: How was the decision made for each group to join the ecosystem. How did this evolve?

Sven Freudenfeld--CP-TA: The effort started with the PICMG organization, defining standardized building blocks or standards for the embedded and computing industry. They primarily targeted the telecom industry and the rolling out of the Advanced Telecommunications Architecture, (ATCA) and specifying telecom requirements. It was a ground-laying organization for defining hardware specifications to meet the telecom environment.

That was a starting point. Then, there was a need to clarify some of the standards and finalize them. The fact that we have standards does not guarantee, for example, interoperability given multiple vendors. Since this is an open community, the need grew to ratify some of the specifications.

Chris Wardale--Scope Alliance: The SCOPE alliance came after everyone else. We looked at the landscape and saw that there are lots of activities in different layers--the hardware, operating system, middleware, and applications layers. From our point of view we saw that a holistic picture could be created if we looked across those layers. That was really the reason the SCOPE Alliance was established.

Rob Davidson, PICMG: PICMG has been around since 1994 and has multiple specifications. The ones most followed in this community include AdvancedTCA, AMC and MicroTCA. We formed to advance the needs of the industrial automation marketplace for more rugged modular-type PCI computers. From there, we probably organically defined our niche in the marketplace around the hardware and lower-level software specifications. It's sort of what the organization does. It takes three executive member companies to start a specification initiative inside of PICMG so it's driven from the bottom up, not from the top down. Some of the more successful specification initiatives such as ATCA started as working groups outside of PICMG, created a foundation and brought them into PICMG. As an organization we could help bring them to market quickly.

Dan Cauchy - Linux Foundation: Figure 1 below is a good representation of how the organizations really work well together and have very little overlap.

At the bottom, PICMG focuses on hardware specifications, and the Linux Foundation on operating systems and LINUX requirements and specifications. The SA Forum concentrates on middleware and high availability specifications. These are the three organizations working on actual or technical specs.

One of the issues when you have so many members and so many requirements, you often end up with specs that are quite general and maybe a little bloated for specific applications. This is where the SCOPE Alliance comes in. Formed by the network equipment providers, the SCOPE Alliance has played a critical role in this industry in narrowing down the important aspects in each of the very large specifications and narrowing them down to specific requirements for equipment categories in specific applications.

The SCOPE alliance plays a critical role in guiding the industry and telling us what is important for specific sets of equipment. Then the CP-TA comes in and provides the glue that gives us interoperability and testing. The organizations work very well together--it's all complementary.

Asif Naseem, Service Availability Forum: There are two key trends that actually catalyzed the formation of the SA Forum. One trend on the service provider side is that all of the network operators are moving their networks from stovepipe architectures to a more service-oriented transport agnostic network where there's no need for separate control, access, and services layers. Common layers are used to create an architecture that's substantially more efficient and can provide converged services and can quickly be put together.

A related trend is on the supplier side. In the 1990s the enterprise computing industry went through a period of having a single company provide an entirely vertically integrated stack. So if you look at Figure 2, until the early 1990s, you could go to IBM or Sun or some large equipment manufacturer and buy the entire stack from silicon all the way up to the application. That industry went through a transformation. In true standardization, there are multiple layers that you can actually buy from different suppliers and multiple suppliers within the system and put together a vertically integrated system using standards-based commercial off-the-shelf-components (COTS).

Seeing that PICMG has done a great job in standardizing the hardware, and the Linux Foundation had also done a very good job on carrier-grade Linux, the next area to tackle was middleware. What we have attempted to do within the SA Forum is to draw boundaries around that middleware by specifying the set of services that would be "service availability services," and then draw interfaces around them so that we create a category. We define interfaces that abstract the high availability or service availability services form the software and from the application layer so that all the services that are written can be transported across multiple architectures. Once an application is written to these specifications it can be transported across the underlying platform as well.

CP-TA was formed out of the need that somebody must raise a flag and say, "Interoperability of the COTS components is a very important piece." CP-TA is performing a very critical function in this regard and we're working closely with CP-TA to make sure that we help with the development of their work as much as possible and expedite interoperability.

Regarding SCOPE, one of the things that we find useful from a Forum perspective is their gap analysis. SCOPE Alliance does not publish any specifications or any standards, but they given very good guidance to the industry and the different organizations that are involved in this discussion. For example, to us they specifically come back and say "Here are the important specifications that you are implementing and here are where the gaps are--and please focus on addressing these gaps." That's what their customers, who are the service providers, are looking for.

Chris Wardale--We actually publish both profiles and gaps so we take the specifications from the other organizations and w highlight what's a priority for the NEPs and then we publish that and the gaps.

CommsDesign: Is there any other industry segment where organizations work together and complement each other as you do?

Chris Wardale--Mobile consortiums for the mobile industry, but it's much more fragmented. This particular set of organizations is working quite well together, and it's complementary. If you look at other industries you have competing organizations. Some are folding and merging into others and there's simply too much fragmentation.

Rob Davidson--I'm not sure there's any equivalent ecosystem out there that's formally represented. From the view of PICMG what's driven us is probably the model of the PC and the server industries that went from being proprietary and closed and vertical to open and horizontal. They weren't exactly equivalent since they had a few dominant players that owned some key parts of the ecosystem. The fact is that the hardware layers opened up, people could be innovative and do new and interesting things, then various types of companies came in. Although the PC industry is not exactly equivalent, if you want to look for the roots of this ecosystem, it's a similar trend.

Asif Naseem--I agree with Rob that there's not an equivalent set of standards consortia on the enterprise compute market, if you look at the end result from where the whole vertically integrated system comes, often it based on COTS products so for example you can buy a server from any manufacturer and have the same operating system run it. You can get those operating systems running on a variety of hardware architectures. Then at the middle layer, there are multiple suppliers for the application servers that run on a variety of systems. So you don't have to necessarily go to one vendor to get all the layers. You can actually put together a system by getting layers from multiple vendors. So that's equivalent to what we're talking about here.

Rob Davidson--the greatest achievement to date is that we really don't compete anywhere. All the pieces fit together fairly neatly. There's a lot of the interaction and the work takes place at the interfaces between different organizations. But if you look at this ecosystem one of the things that is apparent is that there are always organizations that are extremely complementary, and there's very little competition to lead to friction between the organizations.

Asif Naseem--What actually helped was how complementary we are, and minimizing the overlap between them. We share our work in progress with each other and seek feedback from each other to ensure that we minimize overlap. We work on things that we collectively believe are important.

CommsDesign: Is there an unsolved problem or challenge for the entire ecosystem?

Asif Naseem--The industry is showing already that the adoption rate for this type of architecture, for using multiple COTS elements and system design or platform design, is already pretty high.

Rob Davidson--What has helped is what I call ease of use--integrating all of these different pieces and getting things to work. That's improved dramatically but there's still room for improvement. When you have several different specifications, with options and configurations, coming from different vendors there's always a challenge in integrating them and getting them to operate for the systems integrator. That's improved dramatically over the past three years, but there's still work to be done.

Asif Naseem--I think that you're getting the sense from everyone around the table that we have helped this ecosystem come along and some of us think we're accelerating the formation of--we have multiple suppliers for each layer. That creates an interesting and unique challenge for us. A lot of these components and layers come from a variety of different players within the industry so the question is who is best suited to actually put them all together and do interoperability testing, integrate them, and deliver an entirely vertically integrated system to either the equipment manufacturers or to the service providers.

TEMs are not in the best position to do that since traditionally they developed all components themselves and they had the expertise and the desire to do the integration and testing. Now that they don't have the expertise or the resources, and they acquire different layers from multiple players. The question now is who should actually be the system integrator. That's our biggest challenge and what's happening is that within the ecosystem, multiple players are coming together and saying that they will pull this whole thing together, integrate, test and perform quality assurance on it and then deliver it to the equipment manufacturer or service provider. But that work is just starting. So, integration is probably our next collective battle.

Sven Freudenfeld--One of the key targets of CP-TA is to make the integration work easier or eliminate the burdens when you talk about multi-vendor components. But that's the goal of CP-TA to bring the guidelines as to how to do compliance testing for interoperability as well as how to perform interoperability and testing in general in terms of airflow, data transport, and manageability. So we are on the path, but we do have some work to do.

CommsDesign: Is there room for yet another organization and, if so, what would that target?

Chris Wardale--If you look at the architecture that SCOPE Alliance has published, there are elements in that do not necessarily represent all of the organizations around the table today--for instance on the management plane. So there are opportunities of course and we are exploring those possibilities.

Rob Davidson--I second that. If there's one area that needs fleshing out in this ecosystem, it's in the system management space. There are various solutions out there and there are other organizations that do it. We have some interaction with some of them but we do not yet have the right strong player to join the ecosystem.

CommsDesign: So tell me about the Mountain View Alliance.

Asif Naseem--The Mountain View Alliance started a few years ago to coordinate the organizations talking to each other in this space. It's been pretty successful in that area. The Mountain View Alliance is currently deciding whether it still has a role to play. In terms of its original goal, it has been successful--there is now very close cooperation and good interaction between us.

CommsDesign: What's next for each organization and what's next collectively?

Dan Cauchy--Individually, the Linux Foundation Carrier Grade Linux Work Group is working on the next version of our specification. The goal this time around is to create a specification that will lead, over a reasonable amount of time, to actual code. In the past we've dragged along requirements in our specifications that were never implemented. This led to some confusion and some requirements that are no longer really valid for various reasons. We're focusing on being closer to the Linux community in the sense that the requirements are going to be things that will actually produce code. So that's one of our key charter changes.

Collectively, we have a very close working relationship with the SCOPE Alliance. We've established a formal process by which the two organizations will work and exchange information so that the SCOPE Alliance is now feeding the Carrier Grade Linux Work Group with gaps that need to be met in order to satisfy the SCOPE Alliance members. We've just started under those new processes. Meeting these requirements is our next step.

Asif Naseem--We have two sets of specifications and we've successfully released them. One is a hardware platform interfaces, and the other is at the application layer. The platform interface is known as HPI, hardware platform interface. That is a commercial success. Many if not most of the standard hardware providers actually either provide HPI libraries as part of their hardware or have plans to do so. Service Availability middleware implementers can assume that interface--so we believe this is a commercial success.

AIS, the Application Interface Specification has just begun as far as the commercial implementation is concerned. We have several initiatives within the forum to accelerate its adoption. So that will be our next hurdle, to provide examples to the industry why different application providers and equipment manufacturers have to actually move up to AIS. We have initiatives going on within the forum to demonstrate to the industry that applications to go up to our AIS are portable across underlying implementations; developed once they can be used many times.

In addition, we also work with the SCOPE Alliance very closely and one of the gaps that we're hearing is on the systems management side and we're addressing part of that issue which has to do with software upgrade. So, as part of the AIS, specification, we have released and will continue to enhance the software management framework specifications.

Sven Freudenfeld--Since the creation of CP-TA we've been fairly successful with gaining a lot of ecosystem member partners eager to address interoperability issues. We currently have approximately 23 members in the organization. What we have accomplished so far is to define a way of having shorter interoperability test times. We've defined or identified some of the common test tools working closely with PICMG and SCOPE. To create interoperability combines documentation as well as well as some test procedure manuals, which help in two cases. One, is the component selection from multiple vendors and the other is the integration portion for platform design.

We have created guidance for ATCA for the first step in covering data transport manageability and as a result we have test tools available through CP-TA. As a next step, we're focusing on AMC and MicroTCA. As you can imagine, there's a wide range of variables where you can use AMC so it's a little more challenging but we're working together and in the ecosystem to create a guidance on that and we have new compliance levels.

Chris Wardale--Other speakers have already made reference to the work from SCOPE that they're making use of in the ATCA and MicroTCA areas. We also work independently and have been looking at such things as virtualization and although we haven't really found a home for our requirements yet, we have published documents in the area and we'll be looking to encourage the adoption of the requirements. Also we've been looking at the environmental aspects as to what our needs are and we recently published an environmental profile. We will be looking at other slices through the stack. Our focus until now has been the control plane and service plane equipment. We've not addressed the data plane equipment. And we're looking more at the central office. So there is other TEMs equipment that we expect to explore in the future.

CommsDesign: What is not understood--where is there still apt to be confusion?

Asif Naseem--One of the things that come up in panel discussions--there seems to be confusion about why we need so many standards organizations. So it's almost like the concept is that there's a lot of overlap, and there isn't. We're complementary--there's very little overlap between the organizations.

Rob Davidson--Just a comment on what Asif said. The question still is why are there these different organizations. Each organization serves a different cross-section of the marketplace. PICMG, which is a lot of hardware and firmware platform suppliers, wants these platforms to be applied across as wide a range of industry applications as possible. At the other end of the organization, the SCOPE Alliance focuses primarily on telecom infrastructure equipment. They have a different member base even though they may be related to subsets of some of the other organizations. If they were trying to cover the whole marketplace that PICMG was trying to cover, they'd never get anything done. So the size of these organizations and their particular area of expertise is driven more by the user group that they naturally fit. Each organization has found its natural fit of members that allow for good separation of developments.

Sven Freudenfeld--By having all these standards and this much freedom of choice, it is necessary to have a community or ecosystem working together to make sure the components are integrating together seamlessly. It's really a comparison between standards-based components with multi-vendor choices in all the layers vs. a proprietary architecture.

CommsDesign: Whether or not the organizations fit together by accident or design--the fact remains the ecosystem is very good for the industry. This is a very strong ecosystem with each organization concentrating their core competency in terms of the standards, and then sharing. As a result, COTS is gaining more interest and traction in the marketplace, which is ultimately beneficial for the end user.

For more information contact: rmiller@nereus-worldwide.com.

Related Articles:

An in-depth look at SA Forum interface specs
Network makers team up to boost carrier platform standards
Save time and money with COTS middleware for network equipment
Tip of the week: Narrow the options for ATCA data transport interoperability