The concept of Applications Optimized Networks (AON) has been around for many years. Absent a few proprietary implementations, the idea has mostly been that the network would use deep-packet inspection to "guess" what is optimal for the application.
The latest vision, which uses Software Defined Networks (SDNs) and OpenFlow, may change the model, based on a new set of capabilities though which the SDN network controller can directly interface with the applications system to define the characteristics of network operation.
At the ONF Open Networking Summit, HP and Microsoft showed a demonstration using an API on the HP OpenFlow SDN controller that enabled the network to dynamically allocate QoS, bandwidth and other characteristics to a Microsoft Lync real-time flow. This is a very interesting development because it actually solves two critical problems in the emerging real-time world:
* How to positively identify authorized real time flows; and
* How to dynamically allocate network resources to best accommodate those flows in bandwidth-challenged environments.
Together these two capabilities provide a new potential for the first truly applications-optimized networks--but even separately, each capability has value of its own.
The diagram below shows how the demonstration was configured and how the API allows the Lync server to provide the HP OpenFlow platform the necessary information to accommodate the optimized network services. I want to thank Pascal Menezes and Jamie Stark of Microsoft for going over the system with me and showing how it can improve Lync operations.
The first capability that's implemented is the ability of the Lync server (or any communications server, potentially) to dynamically provide to the network controller the IP addresses/ports of the paired endpoints of a real time flow. This enables the network to mark, without deep packet inspection, those flows with a CoS/QoS tag that will give them the proper treatment in the network. This becomes a positive identification of "authorized" real-time flows; any device/flow trying to use that tagging that is not "authorized" through the API can automatically be re-tagged to a best effort service class.
This technique has a number of critical advantages over current techniques. When compared to the typical VLAN, it enables positive tagging of a variety of devices, including BYOD and potentially other systems that might have multiple traffic types (e.g., a PC running a soft client or a tablet).
In addition, when compared to deep packet inspection at each access element, it reduces cost as well as eliminating the errors and complexity that encryption of the packet stream can introduce.
Marking packets at the access element based on this central API ensures tagging validity and extensibility. In addition, the API enables the communications controller (Lync) to feed back to the OpenFlow controller information about the performance of the flow, enabling better quality management and alarming. While this capability has been implemented in an OpenFlow SDN system, it is applicable generally as well. The API that enables an application to provide address/ports for service levels could be implemented on a more traditional network infrastructure as an overlay solution.
The second capability is more directly tied to the benefits of having a centralized SDN/OpenFlow controller. Because the central controller has a holistic view of the entire network structure, it is able to configure and operate the network resources to deliver specific policies, QoS, path and other requirements to each individual flow. This enables the OpenFlow controller to provide a route path optimized for the latency requirements of a flow, or in the event of a link failure, to pick a new path that has the best performance characteristics for that flow. When combined with the feedback from the real-time controller regarding operational characteristics, this capability will enable the OpenFlow SDN controller to dynamically make mid-flow corrections or change as required.
While this level of control may not be required in large LANs where bandwidth is readily available and a simple CoS system is adequate (for a discussion of CoS versus QOS, download the white paper here), it could have advantages where bandwidth is limited, .e.g., in WiFi and in WAN connectivity.
Together these capabilities represent a new horizon in how applications and network control can dynamically alter network performance and operations directly. Both capabilities are based, at least to some extent, on the relatively long duration of a real-time flow (and therefore a limited number of flow requests/events per unit time)--though the same capabilities could apply to a business application such as SAP or Oracle as well.
The automated packet marking is especially valuable; when combined with the end applications feeding back on actual end-to-end performance, it potentially removes the need for the complexity of deep packet inspection at the access switch. This could enable a new set of very low-cost, high-performance network equipment for the campus and WiFi.
The use of the policy and flow management in OpenFlow for flow-by-flow provisioning and QoS may be more specific to some environments than others, but it does portend a new set of capabilities that a centrally-controlled network using the SDN capabilities of OpenFlow can enable. All in all, these developments are something that both network and communications managers in enterprises need to pay attention to as they consider their next set of purchases. Assuring that both network and communications vendors understand and have these types of capabilities accounted for in their roadmaps may be critical to the longevity of current purchases.
