It's a practical approach, says Cliff Grossner, AlcaLu's network solutions marketing director. At its heart is a focus on making the user experience -- meaning application performance -- the central goal for SDN.
That's in contrast to most SDN discussions, which might include user experience but are really focused on automating the configuration of the network. "We need to look at a picture that's more than: 'This virtual machine moved from this server to this server, so we need to move ports,'" Grossner says.
Another point that's different: AlcaLu is already including the enterprise, not just the data center, in its SDN plans.
"The programmability will extend outside the data center fabric, and we're preparing for that architecturally in access-layer switches," Grossner says. Others talk about putting SDN hooks into lower-level switches, but "they're still talking about configuration," he says.
As the "SDN" term took flight, AlcaLu sped up development on parts of the application-fluent network. For example, AlcaLu is now planning to release RESTful APIs for its Omniswitch line in the first half of 2013, earlier than it probably would have happened otherwise, Grossner says.
Those APIs would let the switches talk to network management systems, such as CloudStack and OpenStack. They would also let an external element program the Omniswitch boxes. That element could be something like an OpenFlow controller, but OpenFlow controllers won't necessarily be found in the enterprise network, Grossner says.
OpenFlow capability itself won't be added to the switches until later, Grossner says. "It's likely that for the enterprise, more early benefit will come from the RESTful APIs than from OpenFlow," he says.
He isn't divulging a timeframe for OpenFlow support on the Omniswitches. AlcaLu does plan to make some formal alliances with OpenFlow controller vendors, though; those could be announced early next year, he says.
But the whole point behind AlcaLu's approach is to not get obsessed with OpenFlow and configuration, so let's move on to something else.
AlcaLu wants to see policy infused into SDN early on. Ideally, the network would tap a user profile -- or a virtual machine's profile -- to help it make on-the-fly decisions about what to do with traffic coming from (or being sent to) a virtualized application.
Eventually, the virtual network profiles would get sliced even finer, applying to specific applications being run by a virtual machine. So, data intended for a virtual desktop would be treated differently from data heading to a test setup, for example. "It's something we're working on with Citrix Systems Inc. (Nasdaq: CTXS)," Grossner says.
— Craig Matsumoto, Managing Editor, Light Reading

The difference is;
does the network configure BW for the user
or
does the user configure the BW to meet their needs thru 'user profiles' and let the network then dynamically configure the shared BW between the users based on these profiles to meet their needs.
Actually this can evolve in later upgrades so the user enabled to occasionally/dynamically change the priority/BW needed. What enterprise users would really like.
PS Think like the old Fast Packet/ATM SVC parameters, but much simpler at first.