CP-TA addresses AdvancedTCA and MicroTCA interoperability
Presenting the argument that a focus by TEMs on niche application areas, leaving the basic system building activities to xTCA building block providers, makes sense.
As with any specification, the PICMG AdvancedTCA and MicroTCA specifications can be interpreted by users in different ways. As a result of these varying interpretations, firmware designers and implementers have occasionally created building blocks that are not interoperable with one another. Nirlay will address interoperability in this article, beginning with the objectives of the Communications Platforms Trade Association (CP-TA, www.cp-ta.org). He will give examples of how this global organization is working to address the interoperability challenges.
The landscape for the Telecom Equipment Manufacturer (TEM) is rapidly evolving. Traditionally, TEMs developed equipment by themselves, essentially proprietary systems, structured within the architecture. The corresponding interfaces to the outside world were based on open standards - such as Ethernet - and the TEMs deployed the systems into open networks. During this time, the equipment behind the infrastructure was a legacy system - proprietary with some standards. For example, the size of a shelf that fits within a specific rack would be considered standard. However if one disassembled a shelf into various parts, the interfaces between the building blocks would be proprietary.
In recent years, TEMs have moved from developing equipment based on proprietary standards to open standards, thus enabling companies to outsource various equipment parts and specific functions to third parties, with the option to source a building block from multiple suppliers.
TEMs often designed a switch card or a processor blade based on proprietary standards and deployed that blade in multiple applications. However in the case of open standards, a TEM can reuse building blocks for various applications over a long period of time, increasing the production volume, which subsequently lowers the overall cost for the specific building block. While reusing the building blocks may imply that the role of the TEM is reduced, TEMs do not lose control at the application layer. In addition, TEMs gain the ability to outsource as many building blocks as needed from the ecosystem. In the scheme of different layered models - including the silicon, the blade, and middleware - anything can be outsourced, including the application-ready platform. Outsourcing gives TEMs a broader choice with a different feature set and lower cost. It also allows TEMs to concentrate on their niches and not worry about the ancillary components.
Adding to these benefits, the same non-recurring cost that is incurred in creating these common building blocks can be divided among multiple customers. This business model also helps smaller players to enter the telecom market. For example, a small company may have the expertise to build an application, but may not have the expertise or the resources to build a system from scratch. As a result, a standards-based platform would help enable the second-tier TEMs to enter the telecom market.
Need to address interoperability
Manufacturers are continuously looking for standards-based products that offer improved functionality and are cost-effective, reliable, safe, and high performing. Over and above standardization, a key gap has not yet been addressed - interoperability among various building blocks at the platform level. Figure 1 shows an array of platform interoperability components to illustrate how a TEM can choose components from the ecosystem at any layer. The interoperability chasm is the number one reason why TEMs are not reaching the mainstream market for standards-based communications platforms. This is where CP-TA has taken the initiative to fill the interoperability gap. The goal of the CP-TA is to certify building blocks that are interoperable with each other.
As an association of communications platforms and building block providers, the CP-TA is dedicated to accelerating the adoption of SIG-governed, open specification-based communications platforms through interoperability testing and certification. Through industry collaboration, the CP-TA plans to drive a mainstream market for open industry standard communications platforms by certifying interoperable products.
Taking the specification ambiguity bull by the horns
The communications platforms industry has developed a rich set of open specifications in order to build modular communications platforms. However, the industry has been unable to move to the next level of interoperability due to the number of optional requirements and inconsistent interpretations of mandatory requirements.
For example, there is ambiguity regarding the association of Hot Swap sensor to FRU 0 or to its Managed FRU. The intention of the requirement is to remove the Shared Data Repositories (SDRs) from the Intelligent Platform Management Controller (IPMC) Device SDR repository that is added during M0 to M1 transition for a particular FRU. There are different opinions on whether the SDR for FRU Hot Swap sensor should be removed from the Carrier Device SDR Repository when the module is not present.
If the SDR is not deleted, the Current State reading mechanism will be the same for M0 and any other state. But this practice contradicts the AMC.0 Specification R2.0 requirement 3.124b, which states: When PS1# of an AMC Slot deactivates, the Carrier IPMC shall remove the Module SDRs of the respective Module from the Carrier IPMC Device SDR repository. SDRs with an entity instance field equal to that AMC Slot‚Äôs AdvancedMC Site Number + 60h shall be removed. If the SDR is deleted, then it does not contradict the specification. But the Current State reading mechanism will not be the same for M0 and any other state. It also adds additional complexity to the System/Shelf Manager in State reading procedure.
The goal of the CP-TA is to identify the inconsistencies in the requirements and address them, so that they are aligned with the intentions of the original authors of the specification. When PICMG authors wrote the AdvancedTCA specs such as: An IPM Controller shall remove from its Device SDR Repository all SDRs for a non-intelligent FRU that it represents before transitioning this FRU to M0 from any other state, they wanted to target this for the non-intelligent managed FRU with the non-intelligent RTM in mind. However, intelligent managed FRU RTMs have now entered the market. This means that the AMC needs to be considered as a managed FRU, because many things can now be interpreted from the multiple specifications, which can create different behaviors for managed FRUs.
In the thermal domain, the CP-TA is addressing airflow distribution in the chassis, as well as slot thermal impedance. Consider two types of boards: a switch board with low impedance and a high-density processor board with hefty heat sinks, which will have higher airflow impedance. When these two boards are placed next to each other, the switch board with low impedance will steal the air away from the processor blade beside it. The airflow scenario becomes more interesting when there is an AdvancedTCA carrier board with a variety of possible AMC combinations - including height and width variations, in addition to the number of the carrier‚Äôs AMC slots.
CP-TA documents and certification model
In pursuit of achieving the interoperability dream, the CP-TA created a requirements document called the Interoperability Compliance Document (ICD). Within this document, the requirements are addressed to ensure they are in alignment with the SCOPE Alliance (www.scope-alliance.org) profile. In addition, some should requirements in the PICMG AdvancedTCA specification, which have significance from interoperability perspective, have been upgraded to shall requirements and are mandated for CP-TA in order to receive CP-TA compliant status. Each of these requirements is mapped to one or more test cases, which are vendor agnostic. This mapping comprises the Test Procedure Manual (TPM). Any tools vendor can implement the tests in the TPM in an automatable test tool. Currently DegreeC (www.degreec.com) and Polaris Networks (www.polarisnetworks.net) are the CP-TA‚Äôs chosen tool vendors. The ultimate goal of the CP-TA is to provide certifiable building blocks to the ecosystem. Figure 2 shows a roadmap for CP-TA‚Äôs interoperability and how each layer is derived from the other. Companies can claim tested, compliant, or certified status on their building blocks against a specific version of the Test Procedure Manual.
The interoperability guidelines are as follows:
- Tested to CP-TA v1.1
- A subset of all of the mandatory tests for certification are performed on theDUT, and the standardized CP-TA test report is completed stating the resultsof the tests: pass, fail, or not executed.
- Compliant to CP-TA v1.1
- All of the mandatory tests for certification are performed on the DUT witha 100 percent pass rate using CP-TA authorized test tools, and the standardized CP-TA test report is completed.
- For this level, all of the mandatory tests are required to be performed andpassed by the DUT. This level does require a CP-TA authorized test tool beused to execute the test procedures. This level can be obtained by the DUT provider executing the required tests.
- Certified to CP-TA v1.1
- All of the mandatory tests for certification are performed on the DUT bya CP-TA authorized testing service with a 100 percent pass rate. Thestandardized CP-TA test report is completed by the same CP-TA authorizedtesting service confirming this result.
- For this level, all of the mandatory tests are required to be performed, andall of them are required to be passed by the DUT. This level requires a CP-TA authorized service to execute the test procedures and validate the results.
CP-TA is currently researching suitable test labs to provide independent certification testing at a reasonable cost.
CP-TA‚Äôs value proposition
In order to show value in CP-TA testing, CP-TA and B-Star, Shanghai (www.b-star.cn), joined in an integration effort to demonstrate that CP-TA tested building blocks from different vendors require much less time to integrate than non-CP-TA-tested boards. During the process, each building block went through the benchmark testing and bug fixing against a common tool that eliminates the primary interoperability issues. The CP-TA tested building blocks and base platforms consistent with SCOPE profiles to demonstrate that Network Equipment Providers (NEPs) can simplify the selection process, increase supply chain flexibility, improve predictability of successful integration, and reduce life cycle management costs with a more robust application-ready system. Service providers will be able to increase the flexibility and scalability of their network as well as realize faster time to market with new, innovative services.
The CP-TA is currently addressing inter-operability in the AdvancedTCA, AMC, and MicroTCA domain. It also has an ambitious dream of moving up the layered stack to address interoperability in the Carrier Grade Linux, Service Availability Forum compliant Hardware Platform Interface and Application Interface Specification arenas.
The CP-TA participates in PICMG co-ordinated Interoperability Plugfests that provide a confidential environment for the community to harmonize the execution of automated test suites, as well as offer a true multivendor environment for enhanced interoperability testing. CP-TA offers free tests against the CP-TA adopted thermal and manageability tools and provides the building block providers free test reports.
Given the interoperability issues addressed and explained in this article, Emerson Network Power firmly believes that it is crucial to support and promote a compliance program to ensure that building blocks can be integrated with third-party products. With the help of the TEMs and industry-wide endorsement, the CP-TA will continue to deliver economic benefits to the entire value chain.