Xelerated Xpress

Xelerated Is Four Years Ahead

I participated in an inspiring 100G panel at the Linley Tech Processor Conference last week. We didn’t have to debate about the need for more bandwidth and more processing. The debate, instead, was focused on how to best achieve the goal. Network processors, that are purposely designed for the task, or multicore processors that are general purpose and more capable for advanced services?

The Linley Tech Processor Conference attracted 300 attendees.

In the first day’s sessions, one could easily get the impression that multicores are up to the task of network processing. Thanks to Mike Coward of RadiSys, however, the bold marketing claims got a good reality check. RadiSys build systems based on multicore technology. Today, they do 10G per line card. In two, years, they expect to run up to 100G, and 100G in a single chip is likely four years out, all according to his estimation.

For those that don’t want to wait this long, you are welcome to Xelerated. Our 100G wirespeed NPU is here, and now going into production. And in addition to any of the multicore processors in the market, it also includes an advanced traffic manager.

Update: Xelerated’s presentation on ‘Uncompromised throughput at low power’ can be found here.

by Per Lembre on Oct. 11th, 2011

| Comment

Why Xelerated Is Winning New Designs

As was announced last week, we are now taking the HX NPU family to volume production. When looking a bit closer to the type of line cards and pizza boxes where the HX family has been selected, we  start to see a pattern. Our customers look for a combination of:

• Programmable network processing with deterministic performance
• An integrated advanced traffic manager with deep buffering
• Low power consumption

As a product marketeer, I spend quite some time on the first two parts. I’m always excited to work on architecture, describe its features, show performance and outline benefits. And of course, customer care about these things, don’t get me wrong. But features and specifications don’t mean much if power consumption is not kept in control. We have seen several cases where the low power consumption of the HX and AX series have convinced the customer to go with Xelerated, after evaluated some more heated competitive solutions.

For next week’s Linley Tech Processor conference, I’ve put together a presentation on the topic of ‘Uncompromised Throughput at Low Power’. Looking forward to discuss some of this in the 100G Networking panel on second day of the conference.

BTW, here are a couple of articles covering last week’s announcement:

• Lightwave: Xelerated ships HX 100G network processor in volume
• Lightreading: 100G watch: The ramp-up continues
• Telecom paper: Xelerated begins production of HX family
• TMC news: Xelerated starts production of HX family
• Elektroniktidningen (in Swedish): Svensk 100-Gigabit krets i volym

by Per Lembre on Sep. 29th, 2011

| Comment

100G Network Processors Start Ramping in November

Xelerated Xpress met with Anders Ericsson, VP of Sales and Marketing at Xelerated, for a chat on the state of the 100G NPU market. He explains how the technology pushes the communications industry to better optimized solutions.

Xpress: How does the 100G NPU technology contribute to the networking industry?

AE: This new generation NPUs is changing some fundamental economics for the design of Carrier Ethernet systems and how system vendors compete. First, we have the bandwidth factor. The next wave of Carrier Ethernet line cards and systems will deliver higher capacities and packet rates within the same power budget. Second, we get more processing and features. The integrated advanced traffic manager allows system vendors to build more capable systems with higher quality and more advanced services at radically reduced dollar per gigabit. Third, the shift in favor to merchant NPU enable system vendors to compete more with software and feature velocity rather than having to depend on internal ASIC projects.

Xpress: How can Xelerated compete with in-house packet processing silicon?

AE: We are gaining experience from so many more customers, markets, sources and stake holders than an internal development group can get. Our solutions are catered for a broader task and can be used in so many more systems and applications. In comparison, Xelerated network processors are more flexible and have a higher integration factor. They include advanced traffic management and buffering, many hardware engines and huge banks of embedded memories. As our technology applies to a broad set of applications, we pay attention to R&D economics such as time to market, and re-usability of investments in software.

Xpress: What attracts system vendors to use silicon from Xelerated?

AE: We provide three fundamental benefits that no other supplier can provide today.

1. Determinism through the wirespeed architecture
2. Highly efficient programmability, and
3. Low power consumption

It is the combination of the three that makes the big difference.

Xpress: Why is low power consumption becoming critical?

AE: Power consumption is a key design parameter in all systems today, across application types.  This is driven by direct energy costs, less complex and faster installation, minimized need for forced ventilation, and compliance to state regulations for environmental protection. And on top of that you gain a more cost-effective design.

Xpress: In what type of platforms do you see the largest adoption for HX and AX chips?

AE: OTN, Transport systems, PTN, Mobile Backhaul, Carrier-Ethernet Switch Routers and PON OLTs

Xpress: Does the technology enable fundamentally new designs, or are we mainly seeing more of the same; more ports, more packets and more bandwidth?

AE: We see both new designs and more of the same. With our state of the art integrated traffic manager we enable new systems with more efficient designs. But there is of course an ongoing cry for more bandwidth and throughput. One has to bear in mind though, that not all components are in the same maturity stage. For instance, there are a lot of optical components that are too expensive to support a cost-effective roll-out of 100G solutions before 2014.

Xpress: Are there any sweet spot designs?

AE: Yes, OTN and PTN. The HX and AX product attributes fit well in these high-volume optimized designs.

Xpress: The dataflow architecture has evolved in HX and AX. How?

AE: Our core technology continuously evolves. The HX and AX with the 100G dataflow architecture is now in production. It includes enhanced service densities; higher lookup rates and more processor cores compared to the 40G generation. In addition, we have enhanced the flexibility by allowing intelligent oversubscription through advanced pre-classification.

Moving forward the dataflow architecture is already staged for 200G and 400G. We are assessing parallel pipes, and enhanced flexibility for ingress and egress processing while retaining the deterministic characteristics.

Xpress: Xelerated is making a strong push for wirespeed processing. Is this inherent to the HX and AX chips?

AE: Wirespeed is by design and inherent to all our products.

Xpress: Doesn’t wirespeed come with a flexibility tax?

AE: Not really, our software and application utilization is not dependent on traffic load. It is always deterministic to the speed and throughput that the devices are specified for.

Xpress: How are customers responding to the new integrated traffic manager? Are customers using this feature?

AE: The market response has been overwhelming, really. It is mainly used for per-user and per-service shaping in both line card and pizza box designs. This was really the primary application we had in mind. But, we also see additional interest for building chassis-based solutions solely on the integrated TM.

Xpress: When do you expect the first platforms in volume based on HX and AX chips?

AE: HX-based products are expected to ramp in November, while AX will ramp in December.

Xpress: 100G network processing is here and now. So what’s next?

AE: The industry is screaming for more bandwidth and more advanced packet services on Carrier Ethernet systems. We have a number of interesting innovations in-design, but it is a bit early still to unveil any secrets.

by Per Lembre on Sep. 8th, 2011

| Comment

Thumbs Up for HX Rev B

The HX Rev B Network Processor is back from the wafer, and running in the lab. Xelerated Xpress gives you the initial report on the world’s first 100G NPU production silicon. We met with Johan Westergren, hardware engineer.

Xpress: Were you nervous when you turned on the power on the first HX Rev B processor?

Johan Westergren: Excited is probably a better word for it. We have worked hard and made our preparation.

Xpress: How did the chip respond?

JW: We had an initial hick up, and yes, we got a bit nervous honestly. But it is very common that you set a parameter wrong. But once that was sorted, we could quickly move on to infrastructure tests. We ran BISTs on internal memories, we set clocks, and we ran basic functions on all subsystems. After the first business day, we had a multi- parallel test effort rolling.

Xpress: And what about the continuous progress?

JW: We work at a great pace and the chip behaves very well. We are keeping up with the test plan schedule.

Xpress: So what happens between now and product release in November?

JW: The test plan covers a range of cases, all of them well detailed, implemented and tested on the Rev A version of the HX network processor. System test run application scenarios to verify the chip against customer application types. In addition we have started characterization to validate how the chip behaves under different power and temp conditions.

Xpress: Can you say anything on the quality?

JW: This far it looks promising. We pay close attention to quality in the architecture and design of the chip, and it is in the testing environment you see how that starts to pay off.

Read all about the family of HX network processors, and the Carrier Ethernet solutions they empower.

by Per Lembre on Sep. 8th, 2011

| Comment

Green Sign for Xelerated Traffic Manager in System Test

Xelerated has put the integrated Traffic Manager to a big performance and functional test. And it came through in a good shape. Olof Rutgersson, System Test Manager, reports for Xelerated Xpress.

Xpress: What did you test?

OR: We put the TM up for a realistic broadband user and service shaping case featuring hierarchical shaping and buffering. We ran several types of tests to see how the system behaves under stress.

Xpress: What were the test objectives?

OR: Our goal was to utilize every part of advanced TM functionality simultaneously under high traffic load. The tests were designed to validate both the TM hardware and the TM software APIs to handle the high demands on functionality and performance in today’s broadband networks.

Xpress: And what were the results?

OR: Everything went as expected. With no exceptions. So I have only green marks to report in the test report.

Xpress: Is that so? Can you possibly elaborate a bit further?

OR: The results were very conclusive, for every test the TM performed according to its design specification. The results were almost surprisingly perfect with regards to shaper accuracy, buffer depth, scheduling algorithms and WRED drop probabilities. Our test results were nearly indistinguishable from the theoretical models.

Xpress: What was the most challenging test?

OR: That was to simultaneously monitor and measure performance on 48 Gigabit Ethernet ports with 38,400 queues to check throughput rate, buffer depth and traffic prioritization for every single queue. The dynamic nature of traffic management required some tests to run for several hours before final results were reached.

Xpress: Promising results. Any conclusive remarks?

OR: All in all I am happy that we with great confidence can offer such a well-designed integrated Traffic Manager to our customers.

Want to read the full report? Please contact us to get your own issue of the Traffic Manager Test Report.

by Per Lembre on Sep. 8th, 2011

| Comment

It Is About Time for One-step PTP

Xelerated is providing the industry’s most flexible and exact Precision Time Solution. The new Rev B of the HX network processors and AX programmable Ethernet switches come with enhanced precision time logic. We met with Tord Haulin and Johan Bäck who have engineered Xelerated’s precision time solution to give you the details.

Xpress: What’s new in Xelerated’s precision time solution?

Tord Haulin: We have added a Precision Time Unit to every Ethernet MAC embedded on the NPU. This is a piece of flexible time stamping and time correction logic, which allows advanced synchronization services. The precision time unit has one-step time stamping capability and offloads the CPU from latency calculation tasks.

Xpress: What is One-step PTP?

TH: One-step PTP is quickly becoming a key requirement for synchronization services to base stations in Carrier Ethernet mobile backhaul networks.  It allows to fully utilize the advantages provided by PTPv2-2008. With one-step time stamping each PTP event packet gets its latency time added ‘on-the-fly’, before the PTP packet is further forwarded to the next node towards the base station. Although this adds to the processing of PTP packets, we have implemented a solution that actually improves the time stamp precision.

Xpress: How precise is the solution?

Johan Bäck: To achieve high accuracy, time stamping has to be done as close to the wire as possible. We have paid close attention to jitter, and even managed to reach nanosecond time stamp accuracy for the higher link speeds. You won’t find anything better than that in the market.

Xpress: What about customers who want to support other PTP profiles, like legacy two-step PTP?

TH: The precision time solution supports PTPv1 and all clock modes in PTPv2-2008.

Xpress: What about Synchronous Ethernet?

TH: Synchronous Ethernet is of course also supported. You can flexibly monitor and select links for locking the frequency of the real time clock embedded on the NPU.

Xpress: Can other applications benefit from the new precision time unit?

JB: Sure.The technology has been developed for superior flexibility. We see One-step PTP as an important use case of course, but having time logic in the MAC increases the overall capability of the network processor. The most obvious area for other usages is OAM and performance monitoring.

Interested to understand more about Xelerated Precision Time Solution? Check out our Precision Time white paper.

Note! PTP is short for Precision Time Protocol. This is an IEEE standard initially developed for the automation industry in mind, but was re-engineered in 2008 to support wide scale carrier deployments. The updated standard is referred to PTP IEEE 1588-2008.

by Per Lembre on Sep. 8th, 2011

| Comment

Do Your Homework – The “Four Ps”

Selecting packet processing technology for next generation line cards can be a complicated decision with many variables at play. In an article in the latest issue of EECatalog, I’m suggesting a guideline based on ‘four Ps’:

• Programmability. What level of flexibility is required?
• Processing. How many operations and table look-ups per packet? Is wirespeed performance critical?
• Power. What’s the power budget? Can the device bring the right performance per watt?
• Price. Level of integration (embedded memories, traffic management, etc.) has a huge impact on the bill-of-material, which ultimately defines the manufacturing cost and the margin for the target system.

Once coined by Jerome McCarthy and later made famous by Philip Kotler, the right marketing mix for a company can be modelled by another group of Ps: product, price, promotion and place. Kotler later added a couple of other Ps.  Is there anything missing in the ‘four P’ model for packet processing decision making?

by Per Lembre on Mar. 14th, 2011

| Comment

Why Programmability Matters in OAM

Defining OAM, Part 3 of 3. Please check out my earlier posts on defining OAM and OAM on NPUs – not only about CPU off-load.

As service providers take on new technologies, they spend a significant amount of time and resources adapting the new infrastructure to their method of operation. This means fine-tuning service provisioning, monitoring network status and having tools for consistent fault protection and mitigation. As with most things, standards is one thing, but what purchased products really can do is yet another. Designing the OAM functions therefore is as delicate as engineering the user plane for the right performance, features and availability. You need to analyze what functions you have, what you want to maintain, and what new capabilities you’d like to see across the complete network. Purchasing equipment that doesn’t meet requirements is as bad for OAM as it is for user data services. You end up compromising functions against performance and designing against the least significant denominator.

System vendors know this. Some have learned it the hard way when their products can’t support the required model of operations by some of they’re potential service provider customers. Others by owing the luxury of incumbency; once an operating system is ‘in-designed’ it becomes ‘approved’ by the service provider. This puts vendors with running contracts in a strategic position where they may advise new features that are planned for in their future releases of the OS, and are well supported by the underlying hardware. Competitors not in this position struggle to catch up and get their functions approved.

Here is why programmability matters for OAM. If the hardware is not flexible enough to develop a strong and agile OAM and service provisioning roadmap, the product will fail to concur with new market territory. Even aggressive pricing can’t compensate for a rigid hardware. Addressing the service provider requirements with a re-spin of the hardware is not very attractive either. An unproven vendor with an unproven line card is just too much uphill to win the deal.

It is rather common that network elements such as switches and transport systems are designed to perfectly meet a large incumbent carrier’s set of requirements. This customer may very well be significant enough to justify the design. But in a global market with global standards all systems have a larger market to address. But it can only be addressed with flexible OAM functions.

For a successful global expansion, Carrier Ethernet products need programmable OAM.

PS. Interested in how Xelerated technology can be used for OAM? You can find more information on the technology section on the Xelerated website.

by Per Lembre on Dec. 3rd, 2010

| Comment

OAM on NPUs – Not Only To Off-load the CPU

Last week, I wrote a blog post on how critical Operations, Administration and Maintenance (OAM) is in Carrier Ethernet and IP/MPLS networks. These functions are essential for running a smooth and scalable service provider business. This post, in turn, will highlight one critical implementation aspect of these functions in modern switch/router designs. How do you divide the tasks between the network processor and the control host CPU?

In the good old TDM world, OAM features were built-in and had a dedicated out-of-band channel for communication.  In the packet-based world, however, network OAM protocols often run alongside user traffic and therefore compete on link and switching resources. The new – and evolving – standards for packet OAM have to be thought through during the systemization phase of the line card to give the feature set its required backing from the hardware. What bandwidth, packet rates and features have to be supported? How can they be assured processing guarantees without sacrificing user data?

OAM doesn’t come for free. For monitoring a single link, the line card has to generate hundreds of CCM packets (Ethernet term) or Hello packets (MPLS term) every second. On the receiving side, the line card has to read and count the OAM packets coming in. The data plane has to identify if the link is lost (by three consecutive lost packets) to trigger a protection switching mechanism and routing protocol convergence at the control plane.

Link OAM traffic can add up to significant packet rates, particularly in service edge routers that may be responsible for termination and management of hundreds of thousands of virtual connections. And this is just for link monitoring, which is costly from a processing perspective, but still a rather basic service in the broader OAM world. Add to this traffic for monitoring the performance of services for quality analyses on services like voice and video per customer, and the amount of processing for OAM raise to several gigabits per second. This was one of the reasons why system vendors were looking at network processors to support OAM a few years back. They are simply running out of steam on the host CPU to cope with the load. And while performance continues to be a major reason for OAM support in network processors, I believe there is a more fundamental reason why OAM should run on the NPU.

If you run status check services in the control plane rather than in the data plane, the OAM design will eventually end up interlinking and dependent on the control plane itself. While OAM plays a key role to the control and management planes, the planes should ultimately be autonomous from each other. When you are to check the connectivity between two points in the network, you want your test packet to be forwarded exactly as if the packet was part of the user traffic. This is also required in IEEE 802.1ag for link OAM. The packet should travel across the network using tables stored in the data plane, not mirrored copies that hold in the control plane. If there are inconsistencies between them, OAM won’t provide the correct data. It is therefore critical to implement OAM functions in the data plane itself. That is, it should run on the NPU rather than on the CPU.

In my next post, I will delve deeper into the importance of programmability for OAM functions.

by Per Lembre on Nov. 25th, 2010

| Comment

A Closer Look: Defining OAM

In an earlier post, we touched on Operations, Administrations and Maintenance (OAM) and the holistic approach Xelerated takes to these critical functions. As Carrier Ethernet vendors begin to take OAM more seriously, it’s time to revisit the long-debated topic, taking a closer look at OAM and what it means to the vendor and service provider communities.  In a series of three blog posts, I will take a look at the definition of OAM, its importance from the NPU level and why programmability matters.

First, let’s take a quick look at the role OAM plays for service providers and their networks.  Service providers demand operational excellence.  It is critical to their success.  And OAM is a critical component in hitting that mark.

On a high level, OAM is the monitoring and management of network resources – a set of data plane functions which allows the network operator to e.g. identify faults before they escalate and get noticed by end users, or to set a remote node into loopback for configuration under a service window.  For a good background on Carrier Ethernet OAM, I recommend a white paper by RAD.

OAM measures the status of nodes and links of the network, and it notifies control and management planes in case of events. Closely related to OAM is the area of performance monitoring, where the data plane provides information of the performance (in terms of throughput, packet loss, delay and delay-variations) of links and services across networks and service provider domains. Ethernet network and service level OAM tasks are well defined in the IEEE 802.1ag while performance monitoring is described in the ITU Y.1731.

The increased demand for performance monitoring is driven by the interest for enterprises and content providers to monitor their networks. Services providers therefore have to offer a secure and reliable interface to the virtual private network connections these services are based on.

Automated OAM functions enable service providers to streamline their operation and reduce truck-rolls. They have invested decades and several million dollars of IT investments on operational network and service systems. Therefore, they are putting careful attention to the OAM capabilities of network nodes. The switches and routers have to comply to current ways to monitor and provide services, as well as provide the required features and performance planned in future network designs.

By providing hard requirements on OAM, service providers can continue to run their operations with small and highly experienced staff. It is way too expensive to leave this set of requirements out in the purchasing of next generation Carrier Ethernet products. With advanced OAM, the business can run more efficiently.  But for some reason, many Carrier Ethernet vendors are still behind in delivering what carriers really require for OAM and performance monitoring. It may have to do with the stress these functions put on the hardware. Next week’s blog post will focus on this. I will look into OAM from the network processing perspective.

by Per Lembre on Nov. 17th, 2010

| Comment