Nortel, Trapeze diverge on Smart Mobile recommendations

Trapeze and one of its primary OEMs, Nortel, don’t quite see eye to eye on their recommendations for customers’ use of distributed wireless switching.

Last fall, Trapeze announced its Smart Mobile architecture, a twist on its centralized wireless LAN system that lets customers move select traffic forwarding out to distributed access points to alleviate back-end bottlenecks and associated latency. The idea was to combine the benefits associated with both centralized and distributed architectures onto one WLAN platform.

“We saw that the pure centralized architecture wasn’t going to scale for voice,” David Cohen, director of product marketing at Trapeze, told me last week at the Interop trade show, where he was demonstrating the company’s 802.11 Draft N access point, to ship late this year.

But Kyle Klassen, in the enterprise wireless marketing group at Nortel, which OEMs Trapeze WLAN gear under the Nortel brand, countered, “We’re not fully endorsing Trapeze Smart Mobile for all implementations.” He pointed to Nortel’s long-heavy emphasis on business voice systems and said it chose to resell Trapeze WLANs largely on the merits of its voice support with the centralized architecture.

Klassen said that Nortel recommends using the distributed Smart Mobile capabilities for stationary wireless—not mobile—devices. Stationary devices are Wi-Fi-enabled desktop computers and Nortel desktop phone sets. Using Wi-Fi cards in these devices, Klassen explained, is not about enabling mobility but, rather, about reducing the cost of computers for stationary workers and for reducing cabling requirements and associated expenses.

Klassen advised that all mobile and roaming access devices remain on the centralized Trapeze/Nortel system. Why? Because the centralized system is what initially solved the problem of having to move information about all a company’s virtual LANs (VLAN) out to distributed switches when users went mobile. In a centralized scenario, a roaming user remains associated with the appropriate VLAN through the central intelligence of the switch. In the distributed scenario, VLAN information must be pushed out to the distributed forwarding devices, which creates mounds of reconfiguration work for network administrators.