Xelerated Xpress

Insight on Carrier Ethernet and Beyond

Carrier Ethernet defies Economic Down Time

Michael Howard, Infonetics Research principal analyst, just announced his latest projections on Carrier Ethernet expenditure for the carrier market. As been the case now for a few quarters, investments in Carrier Ethernet continues to outblow other types of investments in telecom infrastructure.

According to Infonetics, Carrier Ethernet equipment manufacturer revenue is projected to grow to $34 billion by 2013.

This is a good place to be.

by Per Lembre on Sep. 30th, 2009

| Comment

Mobile Operators Stress About Bandwidth Growth

Reuters today published an article which captures the stress mobile operators are undergoing with Laptop dongles and the iPhone driving bandwidth requirements to completely new levels. A series of good examples is provided from different parts of the world. To understand the scope here, French operator, SFR, tells us that laptops connected to the mobile network drive 450 times (!) more traffic than a classic mobile phone. Another example is given from the Australian operator, Telstra. The day Michael Jackson died, there was a 170 percent increase in mobile traffic.

The article puts the spotlight on one of the biggest industry challenges that lies ahead. With a flat rate business model, how do Mobile Operators cope with providing competitive mobile broadband services and still earn a fair amount of money? Learning from the fixed broadband evolution, there are a few fundamental network design principles to keep in mind.

  1. Leverage Carrier Ethernet technologies to provide high bandwidth at low cost
  2. Keep it “as simple as possible…but no simpler” (lending a qoute from Einstein here)
  3. Look to increase the lifetime of the equipment to support a greater business case

Xelerated technology can be used to empower mobile backhaul networks to enable huge data growth. Some of the new platforms designed for mobile backhaul look closely at how to aggressively bring down cost while providing traffic management for committed and exessive data rates as well as preserving synchronization services for the base stations.

Mobile operators need these platforms, and are becoming more and more stressed about the situation. As Esa Rautalinko, who heads TeliaSonera’s mobile network in Finland (TLSN.ST), states:  “We are closer and closer to a situation where we reach the limits of our capacity”.

by Per Lembre on Sep. 30th, 2009

| Comment

Dataflow OAM

For service providers, Operations Administration and Maintenance (OAM) is business critical. OAM is a set of features required to operate the network efficiently. Links and nodes are contineously monitored for consistent traffic forwarding. Anomalies and faults are announced (and protection switching is carried out). Access switches and CPEs are automatically configured.

All these tasks are operated in the background, invisible to the end-user, and in most cases even to the personell at the Network Operating Centre. Every node in the network is configured to automatically carry out its OAM tasks. Reporting back to the centralized operations systems is limited to faults and status message updates at regular intervals.

At the node level, all OAM tasks need to be implemented in a highly scalable manner with limited or no performance hit of the user data traffic. A few years back, these tasks were implemented by the control plane running on the CPU. But with the  processing power needed for OAM in today’s modern Carrier Ethernet networks, the data plane on the Network Processor (NPU) has to significantly offload the CPU.

Take Ethernet link OAM as defined in IEEE 802.1ag. It is used to trigger protection switching in e.g. PBB-TE, and requires significant support by the data plane to operate efficiently. Every second, each Management End Point (and a node can support several hundreds of these) generates 300 Control Check Messages (CCM) to its peers.

At Xelerated, we have taken an holistic approach to all OAM operations. The control plane is obviously still in charge for all OAM tasks. But when monitoring links and forwarding states, we are really interested in how the data plane behaves. It should ultimately be able to collect the right information and hand it to the reqeusting entity without having to involve the CPU of the system. Even if the control plane goes down, these tasks should run without any interference.

Similar processes are carried out for routing and switching table maintenance, hardware health checks and memory repairs. On a node level, these tasks are hugely important , and when you think about it, they have a lot in common with service and link OAM.

In the last few months we have got some good feedback on our approach to OAM. For developers used to the simplistic programming model used when coding the dataflow architecture featured in all Xelerated devices, programming OAM is like programming any other part of the data plane. Maybe this is what is best about our OAM approach. OAM isn’t a new area requiring a new set of tools and software. It is an inherent part of the data plane. So all we had to do was to allow the programmable pipeline to be programmed and configured by packets generated by the control plane, or be triggered by an OAM packet arriving from the network. These control messages triggers an OAM program running in the pipeline thereby allowing the rich set of resources to be accessed in a timely manner for any type of OAM task.

We haven’t coined Xelerated’s OAM approach yet, but I’m leaning towards Dataflow OAM. Below is a first draft on how the Dataflow OAM functionality can be presented. Comments, anyone? dataflow oam

by Per Lembre on Sep. 15th, 2009

| Comment

Open Access Gaining Attention

With the broadband stimulus debate, the regulatory framwork for future unbundling of fiber access is heating up. Xelerated’s VP of Marketing, Thomas Eklund, made a comment on this at xchange magazine today. Unstrung has started to track service provider take ups to the US government broadband stimulus packages. And today, ECI Telecom announced support for open access in their Multiservice Access Node for GPON deployments.

Investments horizons are long, and there is a need to build trust and long-term commitments to the regulatory framwork for this industry. In the mean time it makes sense to design networks and platforms with programmable software and hardware, enabling alignment to different operational models. ECI is doing the right thing!

It will be interesting to watch service provider statements on this topic.

by Per Lembre on Sep. 10th, 2009

| Comment

Metcalfe’s first Ethernet Scetch from 1976

Bob Metcalfe, who invented and commercialized Ethernet, stopped by Ethernet Academy, and shared his first hand-made pre-powerpoint slide of  Ethernet cirka 1976.

Bob Metcafe Ethernet scetch

Bob Metcalfe Ethernet scetch

I will need to look around at Xelerated for the first Dataflow architecture scetches. These are from  2000, which definately is Powerpoint days. Digital archives are more easily searchable, which makes my job easier. But I’m not sure the scetches will be as compelling as Mr. Metcalfe’s hand made one. Stay tuned for later updates.

by Per Lembre on Sep. 9th, 2009

| Comment

It Is About Time

Synchronization is getting hot in Carrier Ethernet. We have engaged with quite a few customers on this topic lately, mainly driven by mobile backhaul upgrades to accommodate iPhone-uptakes, 3G roll-outs and to prepare for future LTE. I wanted to share some collected points this far:

  • Network vendors want to comply to two important evolving standards: Packet-based Precision Time Protocol, PTP 1588, and physical layer frequency synchronization defined by Synchronous Ethernet in ITU G.8261.
  • A good PTP implementation rely heavily on accurate time stamping. This can be obtained by having all incoming packets time stamped as close as possible to the physical interface. Similarly, outgoing PTP packets should be time stamped as close as possible to the outgoing interface.
  • There are a range of configuration options, why hardware support must be both broad and flexible. Programmable designs will help support future amendments to these standards.
  • Calculations show that PTP can achieve an accuracy in the range of 50 nano seconds, well in line with demands for mobile backhaul applications.

Synchronization is important for many applications. Requirements for these are collected by the IETF TICTOC work group.

Stay tuned for more updates on the synchronization topic.

by Per Lembre on Sep. 1st, 2009

| Comment