x
Optical/IP

Axiowave Queues in the Core

Long quiet, and almost forgotten, Axiowave Networks Inc. has suddenly popped out of the woodwork with, of all things, a core router.

Axiowave today is introducing the XCR128, which it calls a “service convergence router.” The company claims it will trump existing high-end routers, of which there are plenty, by increasing utilization rates of the router ports as high as 90 percent, using quality-of-service (QOS) engineering similar to what is employed in ATM switches.

The company is out to make IP routing more like the ATM and Frame Relay networking market, where service providers are able to charge a premium for guaranteed service-level agreements (SLAs).

Axiowave was founded in 2000 by CEO Mukesh Chatter along with Chairman Ray Stata, who is also the chairman of Analog Devices Inc. (NYSE: ADI). Chatter 'n' Stata also teamed up to found Nexabit, sold in 1999 to Lucent Technologies Inc. (NYSE: LU) for the now-legendary sum of $900 million.

Axiowave has raised more than $120 million from investors including Argonaut Private Equity Management LLC, Madison Dearborn Partners, and Soros Private Equity. Chatter and Stata themselves are also investors (see Chatter's New Box).

In many ways, Axiowave looks to be the “next-generation” Nexabit. Chatter contends that existing IP routers are only built for best-effort IP traffic, and that routers need an entirely new architecture. In the XCR128, he says, a 10-Gbit/s OC192 port can carry 90 percent premium SLA-based traffic, with the rest of the port dedicated to best-effort IP traffic. The entire router will scale to 1.28 terabits of capacity. It will support existing routing standards such as BGP, MPLS, and OSPF, but will also introduce its own software modifications for services such as "ATM-grade" IP-VPNs.

The router's main switching shelf is 35 inches tall by 21 3/8 inches wide by 23 1/4 inches deep, and it weighs 356 pounds when fully configured, Axiowave says.

”Incumbent router architectures are conceived to support best-effort traffic,” says Chatter. “We’ve designed a box to emulate the ATM/Frame Relay business model for IP.”

Axiowave's biggest challenge will be proving to the world it has a reason to exist. The core router market is packed with competition, capital spending in the market is depressed, and startups such as Caspian Networks Inc. and Procket Networks Inc. have already touted higher-performance architectures.

One analyst points out that both Caspian and Procket were focused on refining the performance of routers, and that they've still struggled to find new customers .

"I don’t think the latest crop of core routers missed the idea that you need to optimize around performance rather than scale,” says Scott Clavenna, chief analyst with Heavy Reading, Light Reading Inc.’s market research division. “They [Axiowave] are saying this is the first core router optimized for performance rather than scale… but Caspian and Procket aren’t lacking in IP QOS. What differs is how they each achieve it and how stable the router is in different networks and at different loads.”

Chatter says Axiowave will be unique when it comes to performance and throughput. Axiowave claims a major service provider has put the product through a battery of tests. The tests showed that high-priority traffic carried in a fully loaded switch fabric, with 90 percent utilization, results in a worst-case latency of 69 microseconds. He says today's current IP/MPLS routers can only dedicate 7 percent to 8 percent of any one port to premium services. Axiowave is not naming that service provider, but it says that it has a contract with a small Ohio-based service provider, PowerNet Global Communications Inc.

Proof of concept may have to come in the form of bigger customer orders, which may be tough, given that Axiowave is focusing on Tier 2 and Tier 3 carriers. Besides that, the core router market is filled with folks trying to compete with dominant leaders Cisco Systems Inc. (Nasdaq: CSCO) and Juniper Networks Inc. (Nasdaq: JNPR). These include startups like Caspian, Procket, Chiaro Networks Inc., and Hyperchip Inc. Then there's Avici Systems Inc. (Nasdaq: AVCI; Frankfurt: BVC7), a public company that's occupying third place, by most market-share measures, in the core market. Even incumbents such as Alcatel SA (NYSE: ALA; Paris: CGEP:PA), Nortel Networks Corp. (NYSE/Toronto: NT), and Nokia Corp. (NYSE: NOK), have dabbled in core routing.

Another big question is whether Chatter and Axiowave can overcome the baggage of Nexabit's past. Nexabit was intended to be Lucent’s next-generation core router, but that project turned sour after much internal melodrama and finger-pointing. Eventually, Lucent shut the whole project down (see Whatever Happened to X?, Lucent Loses Two Big Names , Lucent Quiets Terabit Router Rumors, Lucent Faces "Exodus of Nexabit Staff", and Lucent Cleans Up Core Routing ) .

Axiowave deserves credit for making it this far. The company started by building an optical crossconnect -- a box that would have been doomed from the start, given the plight of the optical switching market. Chatter says the company changed gears about two years ago, realizing the optical crossconnect market was not nearly as bright as the routing market. It went through its own cycles of refinancings, layoffs, and product changes (see Axiowave Closes on $45M and Stealthy Startup Leads With Layoffs).

”There are two angles to approach the Tier 2 and 3 markets: either smaller telcos or MSOs getting into triple play over an IP infrastructure, or data services specialists that are looking to offer IP VPNs with SLAs that match ATM and Frame Relay.” says Clavenna. “The thing to remember is that Cisco and Juniper are pounding away at those customers as well.”

— R. Scott Raynovich, US Editor, Light Reading

Page 1 / 10   >   >>
carrierguy 12/5/2012 | 1:40:41 AM
re: Axiowave Queues in the Core Scott,

You mention in your article that Caspian and Procket have flow-based architectures and IP QoS. Is that true? Procket does not have a flow-based architecture. Nowhere on its website does Procket talk about maximum latency and jitter guarantees.

This is the first time someone is coming out with an IP product that can guarantee maximum latency values. If it works as claimed, it has real value.
And to their credit, Axiowave has announced a customer deployment that can guarantee atm slas.
In fact, you guys have a news release about Aleron touting its IP slas. ( I am assuming Aleron and PowerNet Global is the same company).
I have not come across any service provider touting maximum point-to-point latency slas for IP services. So that is definitely a new thing in the IP world.

There is a thread in NANOG about the latest Cook Report about why Best effort business and slas will doom carriers. Good to note that people are finally waking up to this ticking timebomb.
tjs 12/5/2012 | 1:40:40 AM
re: Axiowave Queues in the Core
I remember one visit to plexus... The Nexabit boxes were stacked to the ceiling. "They can't make 'em work and we can't keep 'em" was the whispered verdict. Annoucing betas with little know guys is worthless. When VZ or BT announce that means something.

The whole thing was a fable. Anyone who buys this story is just living the "greater fool theroy"

Tony Li 12/5/2012 | 1:40:40 AM
re: Axiowave Queues in the Core
You are correct, Procket's architecture is not flow based.

Providing a latency bound for IP is not hard. Most architectures will allow you to set your queue sizes down to whatever you desire. The hard part is providing enough buffering for high performance TCP.

I should also point out that most other architectures are quite capable of handling a high percentage of high priority traffic. When things become 'interesting' is when the high priority traffic starts to burst over the line rate, even instantaneously.

Tony
carrierguy 12/5/2012 | 1:40:39 AM
re: Axiowave Queues in the Core Tony,

You've got to be kidding.

what you are referring to is setting egress queue buffer. The tough problem is providing a latency bound for premium traffic when there is switch fabric contention and egress port contention. You can always set queue size, but if your architecture cannot guarantee that high priority traffic will not be subjected to packet loss or jitter issues, then it does not matter.

I am sure (in fact I know) that one can configure maximum queue depths for Cisco 12xxx and Juniper platforms too. Then why do you get the nasty results you get from those platforms?

And what do you mean "high priority traffic ... burst over line rate" ? High-priority traffic always needs to be less than the bandwidth of the egress interface.
Scott Raynovich 12/5/2012 | 1:40:38 AM
re: Axiowave Queues in the Core Yes poor wording on that. I have changed it. Caspian was the flow-based proponent, not Procket.
indianajones 12/5/2012 | 1:40:36 AM
re: Axiowave Queues in the Core Tony,

The hard part is providing latency and jitter guarantees when there is transient congestion in the network. Your statement "providing a latency bound for IP is not hard" assumes a very lightly loaded link. Try congesting one of your ports and watch what the maximum latency of high priority traffic is like. You would be unpleasantly surprised.

The reason for ATM is that people could design switch architectures with fixed cell sizes and guarantee CDV and CTD. Folks could never do that with variable sized IP packets.

Btw, tjs, isn't Aleron an announced customer and not a beta site? At least that is what the press release says .... Also if you look at Aleron website, they seem to have a pretty big sized OC-48 backbone.
uguess 12/5/2012 | 1:40:35 AM
re: Axiowave Queues in the Core Indianajones,

You are not exactly correct. Congestion doesn't necessarily cause latency for high priority traffic to go way off base, when you have QoS enabled with strict priority scheduling and assign queue depth for high priority properly.

uguess
Upside_again 12/5/2012 | 1:40:32 AM
re: Axiowave Queues in the Core "given that Axiowave is focusing on Tier 2 and Tier 3 carriers"

These re-do nexibite boys are selling core routers (better than Juniper and Cisco) to smaller carriers? Oh ok........

I don't think even lucent will buy into this (or would they?)
NetDiva 12/5/2012 | 1:40:31 AM
re: Axiowave Queues in the Core The factors that contribute to the non-gauranteed
latency and jitter behaviour of IP traffic are probably the variable packet size and connectionless nature of the IP networks ( as
opposed to fixed cell size and connection oriented bandwidth negotiated ATM network ).

For high priority IP traffic though it is possible to guarantee the min. latency bounds
if the node implements strict priority or preemptive packet scheduling in the switching fabric as well as egress port queues for the high priority traffic.
The end-to-end latency variation bounds though for high priority IP traffic though may be difficult because of the differnet internet node QoS architectures of the network elements and scheduling schemes supported.
It is possible to do some network delay estimation,at application level and do the
queue depth tuning at service level ( but it becomes application specific again , and one
will fall in flow based category again ).

This is again based on the assuption that this high priority premium IP tarffic is engineered or in other words not oversubscribing the link capacity , but is allocated a small percentage of the link capacity.

If this traffic starts using full link capacity , you know what happens to other bursty traffic on the link .
NetDiva 12/5/2012 | 1:40:31 AM
re: Axiowave Queues in the Core The factors that contribute to the non-gauranteed
latency and jitter behaviour of IP traffic are probably the variable packet size and connectionless nature of the IP networks ( as
opposed to fixed cell size and connection oriented bandwidth negotiated ATM network ).

For high priority IP traffic though it is possible to guarantee the min. latency bounds
if the node implements strict priority or preemptive packet scheduling in the switching fabric as well as egress port queues for the high priority traffic.
The end-to-end latency variation bounds though for high priority IP traffic though may be difficult because of the differnet internet node QoS architectures of the network elements and scheduling schemes supported.
It is possible to do some network delay estimation,at application level and do the
queue depth tuning at service level ( but it becomes application specific again , and one
will fall in flow based category again ).

This is again based on the assuption that this high priority premium IP tarffic is engineered or in other words not oversubscribing the link capacity , but is allocated a small percentage of the link capacity.

If this traffic starts using full link capacity , you know what happens to other bursty traffic on the link .
Page 1 / 10   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE