Achieving deterministic I/O and application scalability for the All-IP Network
Andrew connects AdvancedTCA features to requirements of the All-IP Network.
AdvancedTCA was designed to provide the telecommunications industry with a flexible, scalable, and highly reliable platform architecture. Much of the promise of AdvancedTCA has been realized, yet several challenges remain for widespread deployment in carrier grade packet networks to occur. Not the least of these is how to deliver next-generation telecom applications that demand large-scale signaling and content I/O resources deterministically in a cost-effective manner.
Delivering I/O scalability at a viable price point is the first step to successful deployment. Allocating resources between the application and I/O has led to AdvancedTCA SBC blades that have one or two, and in some cases zero, Advanced Mezzanine Card (AdvancedMC) bays. The options that straddle this divide are insufficient for complex applications with high-density, prioritized, and secure I/O requirements. This architecture requires the I/O resources be spread over many AdvancedTCA blades, which are also tasked with servicing the application’s computing needs, and thus price point and scalability are lost.
One solution to the challenge just described is to use an intelligent AdvancedTCA carrier blade that supports drivers for signaling and bearer services on the I/O cards. This approach had led to 30-40 percent cost reductions over CompactPCI or rack-mount server systems. What’s more, adding an advanced multicore Cavium processor allows the application designer to host a complete Access Network Gateway on the carrier blade.
Divide and conquer
An alternative architecture uses carrier blades with management processors. These blades have their strengths and are well suited for some applications. In many cases, however, a division of labor that requires carrier blade intelligence can best serve the application.
In order to achieve this intelligence, a processor AMC (PrAMC) card must be installed in at least one of the bays. Not only does this add significant cost to the solution, it decreases the number of AdvancedMC bays available for signaling, bearer, or voice processing modules: Cost and flexibility are sacrificed.
While designed primarily for highly parallel I/O activities, the Cavium multicore processor is well suited to handle some or all of an application’s computing requirements as well as its I/O needs. A more than 25-year UNIX/Linux development history was helpful in implmenting this solution and underlined that Symmetric Multiprocessing (SMP) programming requires a different skill set than that required for single-core applications. The understanding and judicial use of locks to protect key data yet not block access and parallel processing comprise the software design skills at the core of this experience.
MTP3 traffic and discrimination
When the AdaxPacketRunner (APR), an intelligent AdvancedTCA carrier (Figure 1), was configured with four Adax HDC-3 Advanced Mezzanine Cards to simulate MTP3 DPC look-up and routing earlier this year the results indicated that multi-threaded applications, tightly coupled with Adax drivers, outperform Xeon-based SBC blades. Benchmarks are available on request from Adax.
Code designed and optimized for single-core CPUs will not deliver 12x the performance on multicore blades, and virtualization will only take you so far.
The All-IP Network brings data speeds and use efficiencies that traditional TDM networks could never reach. Nothing, however, comes without its own set of drawbacks, and the challenges of the packet-based networks are not trivial. By design and definition, the packet-based network was architected first for redundancy and resilience in case of national emergency.
Initial guarantees for service were extremely high, but delivery was best-effort. TCP was invented to address that problem. Nor was delivering data in real time an initial priority. Enter VoIP: From its early adoption as a long-distance alternative service, VoIP drove our industry to invent ways to deliver real-time services such as Voice over Packet (VoP). RFC 1889 is dated 1996, based on theory from the 1980s and 90s. We’ve come a long way baby!
The holy grail
Today packet-based services are clearly becoming dominant. The drive for network service providers marches unrelentingly toward the holy grail of the All-IP Network. Steven Spielberg aside, we will actually reach this goal, albeit in due time.
Today’s applications require vast processing power dedicated to setting up and maintaining secure connections and data transfer to the access and core networks. For the immediate and mid term, these connections will include legacy protocols such as Frame Relay for the GERAN Gb, voice DS0s over T1, and ATM from NodeBs. All of these interfaces need to be brought into the IP network as efficiently as possible.
The Adax APR supports I/O cards for T1 TDM, SS7, ATM, and I-TDM as well as ATM for OC3 interworking to IP. The Cavium on the APR is capable of handling up to 4M RTP headers per second to AAL2 voice packets. These bearer services are in addition to maintaining the necessary IPSec tunnels for Iuh and WiMAX R interfaces to the APR resident Access Network Gateway application in HA.
This covers the basics of connectivity, security, voice and data services, and signaling. What about determinism? Millions of IP flows and tunnels will be sending packets onto the network. Which ones go first and which can wait?
Service providers can no longer afford to set up separate networks in order to sell and support Service Level Agreements (SLAs) to major customers for priority service and real-time applications. QoS, traffic, and bandwidth management must be integral to the All-IP Network design and operation. Multiprotocol Label Switching – Transport Profile (MPLS-TP) and Provider Backbone Bridges – Traffic Engineering (PBB-TE) are contenders to meet this need in the IP core and PBB may find a home in the Access Network. In either case, intelligent L2 management is the only way to prioritize time-sensitive traffic and block the bandwidth hogs that could interfere with your voice call, video stream, or IPTV.
Key to shrinking TCO
Many of the features described earlier can be achieved today with AdvancedTCA SBCs, AdvancedTCA carrier cards, AdvancedMC I/O cards, and software on PrAMCs. However, the real key to success is the ability to have intelligence in the AdvancedMC carrier and support four AdvancedMC I/O cards simultaneously.
An I/O subsystem based on the AdaxPacketRunner combines intelligent hardware with high-density I/O. With flexible architecture, an intelligent AdvancedTCA carrier blade can realize AdvancedTCA’s promise of horizontal expansion.
In a redundantly designed system, cards and blades may be added, removed, and re-allocated with virtually no loss of service. With this architecture in place, network operators are able to retain the value of their initial CAPEX investment well into the future and reduce Total Cost of Ownership (TCO).
Operators require I/O scalability, security, determinism, and high levels of availability. To reduce costs and time to market, a common platform solution that hosts multiple applications is vital. This platform requires good software, the right design for each service application, and hardware to run it. AdvancedTCA has what it takes to build the next generation of carrier grade communications equipment. Telecom equipment providers can combine these AdvancedTCA elements to build a common platform with I/O subsystems and applications that meet the challenges and deliver the promise of AdvancedTCA.
Today it is possible, by choosing an intelligent AdvancedTCA carrier, to lay the foundation for an AdvancedTCA I/O subsystem that is flexible, scalable, and redundant, while meeting ever-demanding industry price points as the cost per link becomes critical.
Andrew (Drew) Sproul is Director of Marketing at Adax, Inc. During his20+ year career in telecom Drew has held management positions in Sales and Marketing. Drew has a BA in Human Services from Western Washington University in Bellingham, WA
Adax, Inc.
dsproul@adax.com

Leave a Comment