A new Wi-Fi protocol has entered the race for the standard of the future - SLAPP.
Trapeze and Aruba's SLAPP proposal is a lightweight protocol to let different access points connect to other vendors' switches. And it could well slip past the impasse in the IETF's wireless management group, and be applied to areas where a central manager handles wired and wireless devices.
SLAPP only deals with the handshake between controller and access point, leaving the rest to individual vendors. "The market has decided on a centralised architecture for enterprise wireless LANs, but there is no agreement on how to implement it," said Partha Narasimhan of Aruba, one of the protocol's authors.
Dan Simone, chief technical officer of Trapeze, agreed: "Feature sets and radio types are all evolving very quickly. We need a simple protocol that will standardise how thin access points [APs] discover their controllers and get imaging information form the controllers."
The centralised approach to wireless LANs - in which a controller or "Wi-Fi switch" manages distributed access points - officially won, when Cisco bought Airespace. Since then both Trapeze and Aruba have decided to strengthen their offerings by opening up to other vendors' access points.
However, moving to multi-vendor systems is not easy. Airespace proposed LWAPP (lightweight access point protocol) in 2003, but it defined the workings of an access point too closely, say the SLAPPers.
"Forcing a control protocol down the throats of people was a bad idea," said Narasimhan. "Everyone has different things they want to do." In particular, vendors disagree on how to split MAC (media access control) functions between the AP and the controller, and would not buy into a standard that made that decision for them.
"If you set the definition in stone, you end up with a lowest common denominator definition, or you specify it in detail, and it collapses under its own weight," said Simone. "LWAPP originally defined specific things such as how you provide an SSID for a radio." Instead, the IETF set out a more relaxed timetable for a CAPWAP (control and provisioning of wireless access points) group.
SLAPP has been proposed to this group by Aruba and Trapeze, with the limited aim of allowing APs and controllers to set up communications - the actual control signals carried across that communication will still be proprietary, and could be considered as extensions to SLAPP, similar to the multiple authentication protocols allowed by 802.1x.
"We want to leave as much autonomy as possible in the specification, so vendors can differentiate if they possibly can," said Simone. "The IETF has a long history of building extensible protocols that give you standard ways to do non-standard things. For example Radius gives a standard way to communicate, but lets you communicate non-standard information. In OSPF, link state advertisements are used to carry proprietary information.
Neither expects to see SLAPP-only plugfests, as the protocol does not by itself provide working multivendor systems. "the important thing is the extensions," said Narasimhan. However, both say their existing products are very close to SLAPP and can be upgraded to it - or to any other protocol agreed by the CAPWAP group, with a simple software download.
Aruba's Narasimhan says that the boot firmware it has posted on SourceForge is an example of its SLAPP implementation.
And 802.11 is just the beginning: "This is extensible to any devices that have to be managed by a central controller," said Narasimhan. "I will be talking to the chair of the IETF's SLRRP [simple lightweight RFID reader protocol - see our article Can SLRRP lick RFID management?] group."
SLAPP could face competition, of course. Airespace's LWAPP is still on the table, and other proposals are expected from Chantry (now part of Siemens) and a group from Panasonic.
Given the steady improvement in protocol names - SLAPP and SLRRP are so much better than LWAPP - we want to encourage other vendors to get in there. How about a (Nokia-produced?) Localised AP Protocol (LAPP) in Finnish? Or Madge could help out legacy network users by submitting a Token Ring AP Protocol (though others would dismiss it as a proprietary TRAPP). Vendors that want more discipline coud threaten us with the Secure Tightly Restrained AP Protocol (STRAP). And finally, somebody, please, let's propose a Cisco Related AP Protocol...