It’s come to our attention that Aruba Networks, the wireless LAN company that recently filed for an IPO, is terrified by the new architecture of the Trapeze wireless LAN system. To summarize the issues, Trapeze and Aruba both build enterprise-class wireless switches, consisting in both cases of wireless Access Points and back-end Ethernet switches. Both systems present a control point on the Ethernet side, and both switch traffic between the wire and the air.
But the new Trapeze architecture has a wrinkle that makes it much faster, more resilient, and more scalable than the Aruba system: local switching. In the Aruba system, all traffic originating on the air has to go back to a Big Ethernet switch before it can be decrypted and delivered to its final destination. But the Trapeze system, with local switching enabled, makes forwarding decisions at the edge of the wired network, not in a big switch that can become a traffic bottleneck.
Hence the Trapeze system can handle larger numbers of users with lower latency with no loss of management flexibility: you manage it as if it were a Big Fat Switch system, and it right-sizes its forwarding functions according to traffic needs, not the blinders of a mediocre group of system architects.
This has Aruba running scared, so they’re in full FUD mode as the e-mail below indicates. I’ve interspersed the Aruba message with a fisking from Trapeze.
Enjoy.
From: Alan Emory [mailto:[email protected]]
Subject: Trapeze Takes A Step Back – Selling Fat APs
We need to start with the subject of the message. Trapeze actually has taken a big step forward by combining the best of fat and thin APs in a single comprehensive solution. Aruba and Cisco force you to make a choice…one size fits all. Only Trapeze allows you to use the right tool for the right environment. It is very important to note that the customer can run the entire Trapeze system in a completely thin, centralized way if they so choose. Smart Mobile provides more flexibility in case that isn’t the right answer for your environment. Aruba? If the only tool you have is a hammer, everything looks like a nail.
In a recent announcement, Trapeze Networks announced their new architecture termed “Smart Mobile†with an emphasis on putting intelligence on the AP i.e. thick APs. Trapeze claims that with this architecture, Trapeze can now enable scalable WLANs with voice support and outdoor wireless access. In addition, this architecture provides a migration path to 802.11n without the need to upgrade their controllers. See press release at: http://www.trapezenetworks.com/ news/pressreleases/?newsId=120
Summary of Industry’s Position:
Trapeze has taken a step back in terms of the architecture and its capabilities. This architecture change is an
extremely disruptive change for Trapeze’s current customers
and
increases the WLAN TCO and security concerns
for new customers.
This change is not disruptive in any way for our current customers. The Trapeze Mobility System behaves 100% as it always has by default. The customer decides how much of Smart Mobile to enable.
As you may recall, “thick†AP architectures equate to poor Security, VLAN explosion problems, roaming issues, poor QoS and costly management. Cisco paid $450M to move away from “thick†AP architectures in 2005 for this exact reason.
This statement is indicative of a very naïve understanding of what a “thick†and “thin†AP really is. The differences have never been about hardware. This has proven out as there is little hardware cost difference between a thick or thin AP and in fact, many APs can run in both modes. The difference has always been about the software, more specifically, the operational model. Thick APs suffer in two ways when compared to thin APs. First, from a management perspective, every thick AP must be independently managed. This is difficult to scale and leads to high operating expense. Second, thick APs operate autonomously. Because the RF is a shared media, there is a need to provide coordinated real time control. This centralized control plane enables advanced services such as IDS, location, and roaming while providing higher performance. The Trapeze Smart Mobile architecture is based on thin APs. All control and management remains centralized in the wireless LAN switch and the AP is still dependent on the switch as with every other thin architecture. Smart Mobile give you the ability to decide whether traffic is centrally forwarded (i.e. tunneled) or natively switched by the AP. In fact, a single AP can do both at the same time for different applications or classes of users. This flexibility comes with no loss of features.
Trapeze had to make this disruptive and drastic change because its controller products have inherent capacity and scalability problems. Remember that Trapeze’s original product was designed as an access-layer switch with direct-connect to access points. That meant only a maximum of 20APs could connect to one controller. See Dave Molta’s report in 2003 (last paragraph) on Trapeze http://www.networkcomputing.com/ showitem.jhtml?articleID=15200335&pgno=4
This statement is patently false. First, Trapeze systems are all designed to handle 100% of “air rate†traffic for all managed access points. Second, the currently shipping switch family can scale to nearly 4Gbps of fully encrypted wireless traffic in a single switch. It is sad that Aruba has to resort to a report that is nearly 4 years old that describes a switch that Trapeze discontinued more than a year ago. In fact, all currently shipping Trapeze switches were designed and shipped after 2003.
Due to market & pricing pressures, Trapeze changed its software to be an overlay controller that handles more APs per controller, but Trapeze never re-designed the hardware to handle the higher capacity. With 802.11n & latency sensitive applications such as voice in sight, trapeze’s controllers are running out of juice and if it kept its current architecture, it would have to EOL its entire controller product family. We have tested the current Trapeze architecture internally and found the same.
Again, Trapeze switches will continue to support fully centralized forwarding. There is no need or intention to EOL any of our switches. The scalability of our switch family remains unchanged whether running fully centralized, fully distributed, or any combination of the two.
Aruba’s architecture from the start has been designed for the highest scalability and performance. Aruba’s controllers are built with specialized hardware to deliver the highest performance on the market today and have sufficient performance to support 802.11n access points. In comparison to Trapeze controllers, Aruba controllers have 4x the total capacity, 2x the voice capacity and 30% better throughput on a per AP basis.
New Architecture Details:
1. Trapeze APs are no longer thin.
All Trapeze APs are thin.
a. Trapeze APs will do local bridging for 802.11n traffic when 802.11n APs are available (no announcement date was given)
Whether an AP does local bridging or not is a configuration option on a per VLAN or SSID basis. This is true whether the AP is 802.11 a, b, g or n. All APs can be supported with 100% of the traffic centralized if desired. There is nothing in the architecture that is 802.11n specific.
b. Trapeze APs local bridging for voice traffic to reduce latency caused by having the Trapeze controller in the data path.
Again, this is an option. Trapeze believes that ANY controller will add latency. The industry has not yet developed a zero latency switch! Furthermore, if the controller is located in another building or many router hops away from the voice serving APs, the network latency can become an issue. Lastly, if the traffic is centralized, it will need to traverse the network twice…once from AP to the controller and then from the controller to the voice destination. Smart Mobile allows the customer to distribute the voice forwarding while continuing to centralize the control and data. This is EXACTLY how SIP/VoIP works. All SIP systems centralize the control and management of the handsets in a SIP gateway but allow the packets containing the actual voice to be peer to peer (i.e. fully distributed). This is a major advantage of the VoIP architecture and one that Smart Mobile enables the end user to take advantage of.
c. Trapeze APs will tunnel back all other applications to the controller.
Which applications are tunneled and which are distributed is a matter of configuration. This shows a lack of understanding and undoubtedly a lack of actual hands on experience with Smart Mobile.
2. Trapeze announced Wireless Mesh capability for outdoor applications. No date or details have been released.
Complete details and ship dates are available from Trapeze. We must have forgot to update Aruba. J
3. This architecture is a software upgrade to existing hardware. No dates or further details have been released.
Smart Mobile is available today for customers with a support contract who wish to begin testing some of its capabilities.
Detailed Issues:
1. Architectural Flaw: Our evaluation of Trapeze’s architecture points to the lack of hardware separation of control traffic and data traffic as the reason why Trapeze’s controllers cannot handle any higher loads. In comparison, Aruba’s controllers include separate hardware to handle control traffic – essential for scaling to higher number of users, applications and throughput.
Actually, Smart Mobile does EXACTLY what Aruba claims Trapeze cannot….it separates control and data! Aruba on the other hand began by building a VPN concentrator based on IPSEC. Today, they essentially build a VPN concentrator based on 802.11i. The encryption protocol has changed but the data remains centralized. Separating the control and data would require moving the encryption to the edge of the network. This flies in the face of all of Aruba’s development and market messages.
2. High Operational Expense: Thick APs require VLAN trunks to be configured all the way out at the Access Layer – to each AP.
a. Current customers need to reconfigure their wired network & access points manually, when they upgrade
Nope. No changes are required.
b. New Customers will experience “VLAN explosion†Problems
Again, no changes are required and no special VLANs need to exist.
c. No more “zero-configuration†of APs
The deployment model for APs remains unchanged. Zero-configuration remains fully supported.
d. No more inter-subnet mobility and “roving VLANs†(trapeze feature)
These features remain fully supported in all cases. In fact, the Trapeze roadmap includes provisions to distribute this functionality as well, improving the scalability and lowering the latency associated with subnet mobility and with roving VLANs.
3. Security Weakness: Thick APs mean decentralized encryption and decentralized perimeter control.
Control and management remains centralized. However, encryption is done in the AP. This means that there is never a concern with not having sufficient encryption bandwidth in the central controller.
a. Cannot do per-user roles.
This is currently supported.
b. Cannot do blacklisting of intruders
This is currently supported.
c. Cannot quarantine infected users
This is currently supported.
d. Cannot do NAC/NAP
This is currently supported. Please see the Microsoft NAC/NAP partner page. Trapeze is also a member of TCG and can support that model for end station integrity as well.
e. Cannot implement guest access on 802.11n and keep it secure
This is fully supported. Guest can access the wireless network over a/b/g/n and be fully secure.
f. Voice WLANs open up a backdoor into the LAN
This is not true. Even if it was, the vast majority of large enterprises create a separate voice only VLAN already to isolate the traffic and improve QoS.
4. Poor Application Performance: No central controller equates to no application awareness. An AP does not have the horsepower to track applications, users and devices.
We agree! This is why the APs do not track this information. The controllers do. Remember, the APs are still thin. They just do what they are told by the controller. All authentication and authorization remains centralized in the controller.
a. Not voice session-aware to be able to support converged voice & data devices such as blackberry devices.
Trapeze has many customers running with converged voice and data devices today and can provide references.
b. Cannot support voice services such as Call Admission Control and call load-balancing across APs.
This is currently supported. Call Admission Control algorithms are run in the controller. Aruba’s fundamental lack of understanding of the Smart Mobile architecture leads them to these conclusions.
5. Poor Mobility: Without centralizing traffic, cannot get central coordination.
Central coordination is maintained. Centralizing the traffic is not a requirement for centralized control and/or management. The Aruba architecture centralized the encryption. As a result, they must centralize the traffic in order to provide central coordination. Because Trapeze has complete separation of data and control in its architecture (contrary to Aruba’s claims) we are able to provide the same level of coordination whether the traffic is centralize, distributed or a mix of both.
a. No secure fast roaming with centralized MAC – cannot cache credentials, reduce authentication time outs, etc
This is currently supported. Again, this observation comes from the fact that Aruba naively assume Trapeze APs are “thick†and run autonomously. They do not. They are thin APs that are still fully coordinated and managed by the central controller.
b. No real-time RF calibration to adjust to interference and cover coverage holes without per-packet information
This is currently supported. See above.
6. Hidden Costs: Trapeze WLANs will need a separate voice server per VLAN
1. Most voice solutions depend on broadcast / multicast traffic that cannot cross VLAN boundaries.
This is not true and shows a lack of understanding with how VoIP functions. A separate VLAN for voice is not required and a single voice server can be used enterprise wide. Some proprietary voice protocols require a central server (e.g. Spectralink SVP server) but most modern VoIP implementations fully support peer -to-peer communications.
—
Now a certain amount of exaggeration is to be expected in Aruba’s response to the announcement of Trapeze’s superior architecture, but Aruba’s Alan Emory doesn’t show the slightest familiarity with the facts. If the rest of the company is amateurish as Mr. Emory, it’s no wonder they’re terrified. Trapeze will crush them.
Many of the companies that jumped into Enterprise Wireless didn’t have a strong grasp on the key technologies: TCP/IP, Ethernet switching, network management, and Wireless LANs. But Trapeze has managed to build an engineering team with key inventors and innovators in all the important areas, hence the superior architecture. Building a successful startup is all about getting the right people and then letting them work together, and it seems our friends at Aruba are still on square 1.
Too bad for them.
UPDATE: There’s a nice discussion of battling architectures at Unstrung.