Confusion is essence of Cisco's AON

In these first few weeks of Cisco's Application-Oriented Network era, one of the biggest challenges has been to understand what AON really is. While the name strongly suggests an "awareness" of applications, the reality is that AON is an application, which is another matter indeed.

The general consensus, I found, from a number of veteran Cisco watchers and competitors was "confusion" after absorbing the initial marketing blizzard from Cisco. So many words, so little information.

In fact, one of the few concrete elements I could find in my search for the essence of AON was the phrase "Intelligent Message Routing." This, we are told, is the "breakthrough technology" that delivers more than the type of application awareness found with devices such as load balancers.

Where a load balancer, for example, would simply inspect a packet and make a decision (such as sending the stream to the least busy server), an AON-class device would work at the "message" level.

That is, the AON module would terminate the connection, gather up the packets and reassemble them into a complete message. The AON device might then reformat a message (by remapping, adding or deleting fields) so that an application incompatible with the original sender could now read it. AON would then, it seems, initiate communications with the destination application.

Cisco might call this "application oriented," but I think most of us would call it an application. To be implemented properly, this application would need queuing mechanisms, disk-based input/output for intermediate storage, transaction roll-back and recovery, and so forth. In short, you'd need the same sophisticated functions that application programmers count on the OS and middleware vendors to provide.

Think for a moment how many aggregate development dollars have gone into the hardware and software for even the most modest Dell servers that one could buy to run a "transform" application. I wouldn't hazard an exact guess but it has to be north of $1 billion.

Given that all communications "up and down" the stack will use standard Ethernet connectivity and IP - and station-to-station latency across Gigabit Ethernet is miniscule - there is no likely performance benefit to be had from the tightly coupled AON system. On the contrary, if Cisco puts too many AON hooks into its core switches and routers, it could slow all traffic.

Ask yourself: Does it make more sense to put a switch in your server or a server in your switch? Common sense would support the former; Cisco proposes the latter.

With this in mind, the press release quotes are more telling. An IBM quote addressed the question by avoiding it and saying nothing - "IBM's collaborative efforts with Cisco in support of AON will allow WebSphere and Cisco customers to capitalize on this emerging architecture to reduce complexity, consolidate IT, and improve performance."

One of the few quotes with any specifics, from BT Radianz, noted that they would use AON to "monitor and report" (not transform) Financial Information Exchange records. Not too compelling, either.

With endorsements like these, who needs critics?

Tolly is president of The Tolly Group, a strategic consulting and independent testing company in Boca Raton, Fla. He can be reached at

Learn more about this topic

Cisco's AON: Ultimate vendor lockout or something more?


Cisco puts focus on Web services, starting with AON


Q&A: Cisco's CTO on AON, data center future


The latest Cisco news

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2005 IDG Communications, Inc.

SD-WAN buyers guide: Key questions to ask vendors (and yourself)