I find it really refreshing how the news from this week has fueled the discussion around various aspects of applications and software-defined networking (SDN) that have been raised a few times in the past.

It is about the application, right? That was and will always be true. And to deliver the highest user experience, the network needs to provide services that are tailored to the application requirements. It seems to be pretty easy. But how do we achieve that? One of the valid observations from the Cisco Application-Centric Infrastructure (ACI) announcement is clearly that not everything will become virtual. You need to support a mixed virtual, physical infrastructure in any case. That should also lead to specific architectural choices as specific functions need to be pushed into or kept in the physical network, as only there are you able to provide those services for all applications in a comprehensive, high-performance, and agile fashion.

But to assure those services, the network needs to know what applications exist and what they need.

The crux is that applications do not and should not know too much about the network, as I've noted before in discussing the right level of abstraction. But some network awareness for applications is necessary to provide a reliable service.

The proper demarcation line — and, so, the structure of the API, and the eventually business-oriented language that is supported there — is key to success. The network services are provisioned by the applications without the need to know a whole lot about the specifics. Done right, this results in agility; automation and orchestration; and better application delivery services, which are clearly the most important benefits of an SDN architecture. So, application awareness is achieved.

But is this sufficient? Probably not. Even looking at the ACI announcement, it calls out different data-plane options, and that is also my view of the world. To make sure that application awareness also exists in the data plane (and not only in the control plane), one needs to go further than most of today's SDN architectures. Those have been focused mostly on the large cloud data centers and not the enterprise data center, and they rely on a data plane that is based on commodity silicon. Those solutions do not provide the granularity required to cope with a large number of unique and dynamic application flows at the data-plane layer, so this limits their capabilities and scale.

In an enterprise network, this can be a critical function compared to a service-provider network that only provides connectivity services. Custom, flow-based ASICs do overcome this limitation and are key for a truly application-aware architecture at all layers. I wrote a another blog earlier this year that was flagged by SDxCentral as a "must read" about flows and the data plane for SDN.

But there is more to application awareness at the network data-plane layer. DPI and policy play a significant role in such an architecture. You can argue if the function needs to be local in a virtual switch (performance?), within a flow-based physical switch (performance!), or somewhere at a control layer working with a switch (physical or virtual), but the key is to be able to classify applications within the network and then apply policy to those application flows. And how the policy should look is again up to applications and business processes that typically sit outside of the network and sometimes the IT domain. And voilà: that is how everything comes together in a great architecture.