Roadmap: Cisco's AON

When Cisco Systems announced its Application-Oriented Networking line in June 2005, the market was abuzz with speculation on the technology and the sudden importance of XML to the company. Thinking the announcement heralded the acceptance of XML in the enterprise, other vendors began to snatch up XML and service-oriented architecture vendors as if they were berries ripe for the picking. Less than a month after the announcement, Intel acquired Sarvega. In October, IBM snatched up DataPower Technology. And this January saw the acquisition of Actional by Progress Software, which, you may recall, is the parent of enterprise service bus vendor Sonic Software.

Now the noise has died down and the AON product line appears to have sunk into obscurity as quickly as it came into the limelight. More than a year has passed since the announcement, and competitors F5 Networks and NetScaler/Citrix, among others, report they have still not caught a glimpse of the "mythical AON" in the field. Many have even begun to question whether the product exists.

Trust us, it does. The AON line is still in controlled availability, which means it may be a while before you see products in enterprise IT on a grand scale. Cisco is being careful with AON--the risks to the line's, and Cisco's, reputation are too high, and the networking giant isn't taking chances with one of the core building blocks in its IIN (Intelligent Information Network) initiative.

Confused? You're Not AloneCisco has certainly stolen the title of King of Acronyms from Microsoft in the past year. With IIN, ANS, SONA, ACE, AVS, AON and a host of other TLAs--some of which refer to technology initiatives, others to product lines and still others to specific products--it's drowning customers in a sea of abbreviations that confuse its intelligent networking message.

Even competitors aren't certain of just what AON is designed to do and, more important, customers aren't clear how it fits into the enterprise network architecture. Add that Cisco's messaging is directed at application developers and administrators, and you've got the makings of mass chaos.

Let's clear up what AON is, so we can dig into the technology and what it means. AON is a product line in three form factors--a Catalyst 6500 blade, a network appliance and an ISR (Integrated Services Router) 3600/3800 module. AON is part of Cisco's ANS (Application Networking Services) stack, comprising a set of application-prefixed products, including ACE (Application Control Engine) and AVS (Application Velocity Services), that are part of its larger SONA (Service-Oriented Networking Architecture). SONA is a set of shared services, such as conventional network services and application services, that are centrally managed but distributed throughout the network; it's an implementation of Cisco's IIN strategy for the enterprise.

AON functions as a policy-enforcement point on the network. Its physical location is unimportant in terms of how it works because it isn't tied to any Cisco-specific technology. AON is a set of applications that run on Linux and act much in the same manner as a reverse-proxy load balancer or cache. The AON device accepts traffic bound for specific applications and applies policies to that traffic before routing it to its destination (see "Traffic Engineering" at right). AON could accept XML traffic and encrypt or decrypt the data, for example, before routing it to its destination, or perform any necessary Layer 7 protocol fix-ups, such as those often required between versions or implementations of FIX (Financial Information Exchange).

Only traffic directed at AON-managed services is delivered to AON devices. All other traffic flows normally and is unaffected by the presence of an AON blade, just as is true with Cisco's CSS (Content Services Switch) and CSM (Content Switching Module). Switch ports are assigned to the blade through the supervisor module; the blade has no ports of its own.

The advantage of an AON system and its multiple form factors is that it distributes XML processing and middleware messages throughout the network. AON deployments can be considered similar to JMS (Java Message Specification) endpoints, or brokers, which are distributed throughout an enterprise to achieve scalability. This setup is often implemented in enterprises and is well-understood.

The Stuff Of Admin Nightmares

Out of the box, AON supports two kinds of traffic: XML and middleware messages. It launched with support for IBM WebSphere MQSeries and TIBCO Software's Enterprise Message Service as well as XML, but through its software development kit, developers can add support for just about any transport or application protocol. Extensibility can be a great thing, but network administrators are likely to quash developer-written code on their routers. And therein lies the greatest strength and weakness of AON technology.The risk is that compute-intensive XML parsing and transformations will adversely affect performance of core routing functions. There are fears regarding whether a hung process on an AON blade might force the router to need a reboot, something that is rarely done except on a carefully scheduled basis since it disrupts services across the enterprise. Looming even larger than these operational questions is whether application developers can appreciate the nuances of traffic routing.

These risks are real, not imagined, and Cisco's reluctance to release AON into general availability reinforces the seriousness of the risks inherent in a partnership between the network and the application. Making it even more difficult is that the union relies on the cooperation of disparate, and sometimes rival, enterprise groups. Politics, not technology, is the roadblock here, something everyone in the industry understands and points to as the primary hurdle that Cisco must overcome before AON and products like it can explode onto the scene. Bringing together network and application architects is no easy task, but it isn't impossible, as F5 Networks proved when it launched its DevCentral site many years ago in a similar attempt to join these groups. F5 has had a great deal of success in this regard, and Cisco may need to acknowledge that one of its biggest competitors has cracked this nut and take a page from F5's playbook to achieve its goals.

Additionally, Cisco has put itself into a position that requires it to support application developers. Although it has worked with OEM partners to deliver integrated third-party products through exposed interfaces, it has never before dealt with enterprise application developers, and supporting those programmers without direct access to Cisco support personnel will require more resources and a different strategy than it is likely used to presenting.

If it can do so, the payback for Cisco and its customers could be dramatic. The benefits of perimeter SOA (service-oriented architecture) security, including encryption, data scrubbing and SSL termination, are well-understood. Better to stop that credit-card or Social Security number from leaving the network than face the consequences from regulations such as HIPAA and California's SB 1386. Traffic can't be routed based on payload if it's encrypted, so SSL traffic must be terminated at the routing device anyway.

And competitors in specific markets have done a lot of the leg work, touting the benefits of routing XML/SOAP (Simple Object Access Protocol) traffic. The financial and trade industries are leading adopters of SOA and rely on XML and the FIX protocol. The ability to determine which service should receive that stock trade based on known performance factors could mean the difference between a sale executing at $10 a share instead of $9--a huge difference in any high-volume transaction. Similarly, if you're going to drop or delay a connection, you don't want it to be the one carrying a $10,000 purchase order; you want it to be the one carrying the $100 one. Simple math says that being able to understand the semantics of those messages can enable intelligent decisions at the network layer that result in better business.

But there are also less obvious benefits, according to Cisco. There are pieces of your business that don't have a data center yet that would benefit from messaging services, such as the warehouse. The warehouse may need the base messaging support required to provide visibility and routing of messages to the appropriate data center or partner. Yet the cost of deploying the infrastructure and staff necessary to maintain a remote middleware presence is far greater than what is required to deploy a blade or module in a remote device that can be managed from headquarters.

Where's The Competition?

As with most commoditized technology and compute-intensive protocols, both middleware and XML are increasingly moving into hardware. The IP, TCP and SSL protocols all moved from software on PCs to hardware as demand for performance grew. Commoditization of integration technology has led to the advent of a number of appliance-based integration device lines, of which AON is one. XML acceleration hardware has been available since the beginning of the SOA craze, and it continues to be the primary delivery mechanism for SOA security and acceleration technology. The services AON provides are certainly available in software and, in some cases, in other hardware devices, which makes delivering them over AON not as far a stretch as some might initially believe. The technology is for the most part commoditized and should be distributed throughout the network in hardware rather than on lots of little boxes in the data center. There's also a great deal of "routing" and traffic management that happens within middleware brokers and XML-focused applications, so the marriage of the network and the software using AON isn't such a far-fetched idea.With AON, Cisco is not doing anything truly new, and yet the technology represents an astounding move, in that no other hardware platform vendor has considered letting enterprise developers extend the functionality of a "black box" networking solution. Although competitors, including DataPower, F5 and Forum Systems, let OEM partners extend their devices, none have considered letting enterprise developers do the same.

So why aren't more competitors on board with this technology? Actually, they are. For several years, DataPower, F5, Forum Systems, Reactivity and others have offered edge devices capable of performing most of the same functions as AON. F5 recently announced an extensive partnership with Reactivity, and its traffic-management products will soon include XML processing and security as well. You can expect to see more competition in the future as these vendors beef up and branch out with their offerings.

You might say these aren't really Cisco's competitors and that it's the lack of similar initiatives by Extreme, Juniper and Nortel that is puzzling. Extreme's open platform and partnerships bring it closest to Cisco in the intelligent network game, letting partners add code to inspect packets and make routing decisions. Internet Security Systems offers an IPS (intrusion-prevention system) module and Avaya software for VoIP (voice over IP) processing on the "cool purple switch" vendor's hardware, but still the effort is not on par with Cisco's AON. And maybe the lack of interest on Nortel's part isn't so odd given its financially rocky recent years, but even Juniper, with its ever-growing portfolio of application-specific acquisitions, remains an innocent bystander. That's likely a mistake on its part, as it is rare for Cisco to adopt a technology so wholeheartedly without first giving the market it serves serious consideration.

Cisco's introduction of AON is simply proof that the market really is converging that quickly; traffic management and application awareness cannot exist separately in the networks of tomorrow--and, in many cases, today. The inclusion of messaging technology is not a new story. Solace Systems has been offering similar technology to the telecommunications industry for years, and has only recently begun eyeing the enterprise market as it, too, looks to reap the benefits of such a pairing of features and functionality. Cisco's slow forward momentum is not surprising. Although there's technically nothing in this device that should adversely affect the router, anything on a blade in a Cisco router that disrupts traffic is going to have a detrimental effect on the overall view of Cisco's ability to deliver in this space.Cisco is in the unenviable position of knowing where it needs to go but is in a '78 Buick doing 55 mph on the highway because it's playing it safe. It wants to be in the candy-apple-red Ferrari doing 100 mph, but it's afraid of a major wreck if it makes a wrong move. And well it should be. A major accident early on means it can likely kiss a large share of the application-aware product space goodbye.

Lori MacVittie is an NWC senior technology editor working in our Green Bay, Wis., labs. She has been a software developer, a network administrator and a member of the technical architecture team for a global transportation and logistics organization. Write to her at [email protected].