Towards a Real Application-aware Network

Leo Caldarola

, Amine Choukir

, Davide Cuda

, Marco Dondero

, Domenico Ficara

Roberto Muccifora

, Libor Pol

and Antonio Triﬁlo

Cisco System Sarl, Rolle, Switzerland

Faculty of Information Technology, Brno University of Technology, Bo

zet

echova 2, 612 66 Brno, Czech Republic

Keywords:

Software Deﬁned Network, OnePK, OpenFlow, Application Awareness.

Abstract:

As the number of network services and applications increases, each one of them showing different require-

ments in terms of bandwidth and latency, it becomes critical for network operators to identify these applica-

tions. This paper builds up on the principles of Software Deﬁned Networking, proposing a novel Application-

Aware Network architecture, which is able to directly handle applications and their requirements; abstracting

the complexity of dealing with network ﬂows. Since metadata about applications are signalled either directly

from the endpoints or from application managers, the information is precise and the approach can also be

used for encrypted trafﬁc. The beneﬁts of the Application-Aware Approach for the network ﬂow management

is demonstrated in real network by two proof-of-concept services: aimed on quality of experience and load

balancing.

1 INTRODUCTION

The number of network services and applications is

constantly growing. As each application shows differ-

ent requirements in terms of bandwidth and latency,

it becomes critical for network operators to be able

to map trafﬁc to applications. This paper builds up

on the principles of Software Deﬁned Networking; it

proposes a novel Application-Aware Network archi-

tecture that is able to handle the requirements of dif-

ferent applications. The main feature of the architec-

ture is the abstraction from the complexity of dealing

directly with network ﬂows.

Getting the right insight into the different applica-

tions allows network operators to plan their network

capacity and policies to deliver the right quality of

service (QoS) satisfying the application requirements.

For example, applications such as VoIP and video

conferencing need low jitter and latency whereas

peer-to-peer ﬁle transfer require high throughput to

minimize the download time. In this context, devel-

oping ad-hoc solutions is not cost effective and lacks

ﬂexibility since a change in the trafﬁc requirements

might lead to a complete reconﬁguration of all mid-

dle boxes.

Currently, the predominant way of managing and

conﬁguring network services is on a per-network-

node and per-endpoint type basis, irrespective of the

commonalities that trafﬁc patterns exhibit. Another

painful point is the decentralised application prior-

ity/policy conﬁguration. A good example is the de-

ployment of a voice solution. The solution usually

require the deployment of a speciﬁc application man-

ager (e.g. SIP/H.323 call manager), which allows for

QoS setting such as DSCP marking to be conﬁgured

and pushed to the respective endpoints. However, net-

work administrators choose to trust or distrust the pri-

ority set by the endpoint depending on the type of

endpoint and the administrative domain they belong

to. A typical case is a hardware phone and a soft-

ware phone: despite both providing fundamentally

the same function and present the same requirements,

the trafﬁc originating from the software phone is usu-

ally distrusted as it runs on desktop PCs.

This conﬁguration and management model is er-

ror prone, not ﬂexible and cumbersome. Network

vendors proposed different solutions to make the net-

work application-aware, such as Medianet

, Appli-

cation Visibility and Control

or Junos Application

Aware

. A common characteristic of these solutions

http://www.cisco.com/web/solutions/trends/medianet/

index.html

http://www.cisco.com/c/en/us/products/routers/

avc control.html

http://www.juniper.net/us/en/products-services/network-

edge-services/service-control/junos-application-aware/

Caldarola L., Choukir A., Cuda D., Dondero M., Ficara D., Muccifora R., Pol

cák L. and Triﬁlo A..

Towards a Real Application-aware Network.

DOI: 10.5220/0005473800050012

In Proceedings of the 6th International Conference on Data Communication Networking (DCNET-2015), pages 5-12

ISBN: 978-989-758-112-0

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

is the decoupling of ﬂow identiﬁcation from ﬂow poli-

cies (prioritization, routing and others) through ap-

plication speciﬁc tags. These tags can be either ex-

plicitly signaled as in the case of Medianet or locally

produced by deep packet inspection as in the case

of the Junos Application Aware solution. Based on

the information about the requirements of the ﬂows

gathered from these tags, network nodes can decide

the policies to be applied; in principle, this allows

for a smooth collaboration between the applications

and the network. However, today these solutions are

mainly vendor speciﬁc. The lack of standards leads to

poor or non-existing interoperability.

Recently, Software Deﬁned Network (SDN)

emerged (McKeown et al., 2008) as a new paradigm

based on the separation of the network control logic

from underlying physical routers and switches that

forward trafﬁc. In more details, SDN utilizes a cen-

tralized controller which exposes network functional-

ities through a set of well-deﬁned APIs for services

built on top of the controller. The combination of

those two elements allows network operators and ser-

vice providers to simplify network management op-

erations giving them the possibility to offer new ser-

vices to their customers. However, SDN based ser-

vices have no insight on the relations between ﬂows

produced by the same application. Indeed, they still

refer to trafﬁc through its speciﬁc network protocol

ﬁelds.

The major contribution of this paper is the pro-

posal of the Application-Aware Network (AAN). The

AAN network extends the controlled-network bound-

aries to include endpoints. Its core building block

is the Application-Aware Controller (AAC) that com-

bines different sources of information such as the net-

work endpoints, hints extracted from the signaling

packets and application managers (e.g.: a SIP gate-

way) to provide a uniform view of the application run-

ning through the network.

We evaluated the feasibility of the AAN approach

with a testbed composed of real routers, in which the

AAC was orchestrated by two application-aware ser-

vices. Finally, the paper discusses how AAC can re-

duce the complexity of deploying a new network ser-

vice while reducing their time to market.

This paper is organized as follows. Section 2 elab-

orates on application awareness in todays networks.

Section 3 describes the details of the AAN architec-

ture. The feasibility of the AAN is shown in Section

4 and Section 5 highlights the major beneﬁts of the

AAN approach. Finally, Section 6 concludes the pa-

per and discusses possible extensions.

2 APPLICATION AWARENESS

TODAY

Historically application awareness used heuristics

(Dainotti et al., 2012; Bendrath, 2009), which in-

spect and infer ﬂow characteristics. Heuristics may

be based on port ranges (Fraleigh et al., 2003), IP

subnetting (special network subnets for speciﬁc ap-

plications, e.g. phones), or deep packet inspection

(DPI) (Moore and Papagiannaki, 2005), e.g. applica-

tion level gateway. Port based solutions suffer (Moore

and Papagiannaki, 2005) from port overloading and

inconsistent port usage. IP subnetting solutions are

error prone and result in network management has-

sle. DPI is computationally expensive and becomes

a challenge with the wider adoption of encrypted sig-

naling and secured trafﬁc. In addition, DPI-provided

insights are hardly shared between network nodes on

the path of the ﬂow.

Recently Cisco introduced Medianet (Wilkins,

2011): a solution that makes the network aware of

the application trafﬁc that it is carrying. In more de-

tails, Medianet endpoints leverage a proprietary mid-

dle layer (namely, Media Service Interface or MSI) to

advertise ﬂows Metadata (MD) tags, e.g. application

name, trafﬁc type, media type and business impor-

tance. Network devices such as routers and switches

take local decisions to handle the advertised ﬂows in

the desired way.

2.1 Current Limitations of the

Distributed Solution

To distribute Metadata tags along the path of a ﬂow

to different network nodes, an on-path signalling pro-

tocol such as RSVP needs to be used. This poses a

number of challenges, some of which are exposed be-

low:

• To be able to consume and leverage the MD tags,

software (and potentially hardware) of network

nodes needs to be upgraded. This entail a higher

operational and development cost. It also in-

creases the time to market and slows the adoption

of application-aware features.

• The presence of middle boxes, such as ﬁrewall,

NAT, transcoder, proxies or load balancers, can

affect on-path signalling. Indeed, because middle

boxes usually receive one input ﬂow and regener-

ate it into one or more output ﬂows, MD signaling

has to be replicated/re-generated as well.

• The endpoint sourcing the ﬂow and any network

node along the path can contribute to the MD tags

characterising the ﬂow. This poses a consistency

DCNET2015-InternationalConferenceonDataCommunicationNetworking

problem as different node along the path get a dif-

ferent view of the ﬂow.

• Resource consumption on the different network

nodes and the bandwidth consumed by the on-

path signalling: Each ﬂow comes with a set of

MD tags describing the ﬂow and each node needs

to store the MD tags so that different features on

the network node can act upon them.

The centralised nature of SDN overcomes or miti-

gates all those problems.

2.2 Application Awareness in SDN

The usage of Software Deﬁned Network technol-

ogy to enable Application-Aware Networks is a fairly

novel concept in both industry and academia. Jarschel

et al. (Jarschel et al., 2013) showed a QoS boosting

application that monitor the Youtube streaming expe-

rience. If certain quality thresholds are crossed, the

application requests the BigSwitch SDN controller to

enforce a routing change for the affected Youtube net-

work ﬂows.

Solutions such as that of Insieme (Application

Visibility and Control) also combine Application

Awareness and SDN: DataCenter deployment and

management of applications, databases and their traf-

ﬁc is uniﬁed through a unique controller that is driv-

able with a set of APIs. Similarly, PlumGrid

pro-

vides network abstraction for data-centers with com-

parable promises to those of Insieme. Curtis et al.

(Curtis et al., 2011) propose new ways to provide

ﬂow scheduling in Data Centers through OpenFlow.

Das et al. (Das et al., 2011) adopt OpenFlow to dy-

namically aggregate ﬂows according to ﬂow proper-

ties such as bandwidth, latency, jitter; thus providing

different levels of QoS to applications. In the same

spirit of using OpenFlow to aggregate trafﬁc accord-

ing to application knowledge, Zhang et al. (Zhang

et al., 2013) propose an extension to the OpenFlow

protocol to enable application optimization in Opti-

cal Burst Switching networks. Finally, Bredel et al.

(Bredel et al., 2013) show a viable way to coordinate

Trafﬁc-Engineering for trafﬁc generated by scientiﬁc

collaborations like the CERN’s LHC.

The work we present in this paper is similar to

that of Jarschel et al. (Jarschel et al., 2013). However,

our approach is suited for a broader range of appli-

cations. In addition, we adopt carrier-grade IOS-XR

hardware and Medianet, application-aware feature de-

veloped by Cisco.

http://plumgrid.com

3 APPLICATION-AWARE

NETWORK ARCHITECTURE

Controllers manage routers and switches in an SDN

network via a southbound interface, whereas ser-

vices (SDN applications) instruct controllers via a

northbound interface. Unfortunately, all current SDN

southbound protocols such as OpenFlow or OnePK

limit the amount of information exposed to a con-

troller and consequently to SDN services: only ba-

sic network indicators and metrics are available. The

controller does not have information about the appli-

cations that produce the ﬂows or about the relations

between ﬂows (e.g. the relation between a SIP control

channel and associated RTP streams).

Network endpoints, such as PCs running the appli-

cations or application managers (AMs), i.e. the server

applications, are a reliable source of information as

they produce or handle the trafﬁc. Therefore, a ser-

vice that can utilize these additional pieces of infor-

mation can achieve better ﬂow handling than an SDN

service leveraging only the network indicators. Ap-

plication awareness allows for instance:

• To develop an AAN service extending network

Quality of Service capabilities to match business-

critical applications to ﬂows and assign higher pri-

orities to them;

• To precisely reserve network bandwidth accord-

ing to the expected trafﬁc rate of the ﬂows gener-

ated by speciﬁc applications;

• To deploy application-dependent dynamic service

chaining, i.e., routing of speciﬁc application ﬂows

through speciﬁc network services (e.g.: IPS/IDS,

ﬁrewall, load-balancing or caching).

Application-Aware Networking (AAN) extends

SDN to route ﬂows in the network in a more effec-

tive or desirable way. Effectively, AAN extends the

controlled-network by endpoints, end user applica-

tions and AMs. Figure 1 depicts the building blocks

of AAN which are then described in details in the fol-

lowing subsections.

Our major contribution is in the abstraction on

handling the network ﬂows separately. Instead, AAN

recognizes the relations between different ﬂows orig-

inating from the same application. In this way, it is

possible to handle trafﬁc of the same application in a

consistant manner. In addition, an application can tag

each ﬂow for a speciﬁc class of trafﬁc. Consequently,

the AAN can distinguish trafﬁc classes of a single ap-

plication with different ﬂow handling requirements,

e.g. a video stream and a stream with text metadata.

TowardsaRealApplication-awareNetwork

Application

manager(s)

SDN Control Plane

Application aware

controller

AA-Endpoints

Endpoints

Network

Application aware

service(s)

Figure 1: High level architecture of Application-Aware Net-

work.

3.1 Network

In general, AAN is a hybrid network where SDN

and non-SDN nodes coexist. SDN nodes constitute

an overlay network interconnected by non-SDN net-

work nodes. These SDN nodes are the points where

network controlling services can provision resources

and enforce policies, adapt to the application require-

ments and provide feedback to the controller(s).

In this paper, we focus only on AANs constituted

entirely of SDN nodes. We leave the speciﬁcation of

the interaction between SDN and non-SDN nodes for

future research.

3.2 SDN Control Plane

We do not assume any speciﬁc SDN controller. How-

ever, we assume that the controller provides at least

basic OpenFlow functionalities, i.e., it is able to pro-

vide visibility and statistic about the ﬂows crossing

the SDN nodes and support basic actions to set QoS

or select the output interface.

3.3 Endpoints and Application-aware

Endpoints

In this paper, the word endpoint stands for an enduser

device running applications. All endpoints commu-

nicate with the application manager (AM), which is

responsible of managing the application logic, for in-

stance, establishing calls or provide information about

the user location.

Application-Aware endpoints (AA-endpoints) are

equipped with a middle layer that allows them to di-

rectly communicate with the Application-Aware Con-

troller (AAC). AA-endpoints export to the AAC in-

formation such as the established ﬂows and applica-

tion statistics. Furthermore, AA-endpoints export ad-

ditional information such as the endpoint status (e.g.,

memory or CPU utilization) and type (e.g., smart-

phone or desktop device).

3.4 Application Manager

AMs (e.g., the Microsoft Exchange Server, Microsoft

Lync or Cisco Uniﬁed Communications Manager for

VoIP, VMWare’s VSphere and OpenStack) are an-

other source of information about application ﬂows.

A general trend is to move AMs toward cloud solu-

tions coupled with provisioning of APIs to advertise

and control ﬂows.

3.5 Application-aware Controller and

Services

AAC controls application-aware handling of the SDN

network. From the perspective of the SDN con-

troller(s), AAC is an SDN application. Nevertheless,

AAC uses additional sources of information: AMs,

AA-endpoints, or in general, any other source of in-

formation about ﬂows. This ﬂow information may in-

clude application name, trafﬁc class, business priority

and other attributes.

AAC correlates the ﬂow information attributes

and passes them to application-aware services (AA-

services). An AA-service inserts application policies

to the database. AAC transforms these policies into

SDN rules and conﬁgures the SDN controller(s).

Hence, the AAC abstracts the complexity of han-

dling ﬂows of a single application in a consistent man-

ner. AA-services deal directly with applications in-

stead of the separate network ﬂows.

The AAC provides a consolidated and coherent

view of the applications and their ﬂows, merging the

information gathered from different sources. As dif-

ferent sources of ﬂow information may provide differ-

ent information, it is the responsibility of the AAC to

merge the information consistently. AAC does so in

accordance to the reliability of the source, e.g. infor-

mation learnt from DPI engine are less reliable than

information provided by an AM.

In addition to reliability, each metadata source op-

erates with a speciﬁc trust model to prevent the pos-

sibility of an injection of false metadata. Therefore,

the interface between AM or AA-Endpoints and the

AAC should employ a two-way authentication mech-

anisms. In our experiments, we used Medianet au-

thentication model (Cisco Systems, 2013), which pro-

vides two-way authentication.

Examples of AA-services are QoS policies, load

balancing, routing, ﬁrewalls etc. Section 4 considers

AA-services in detail.

DCNET2015-InternationalConferenceonDataCommunicationNetworking

4 TESTBED AND USE CASES

This section presents the testbed for AAN realised in

our laboratory. The goal of the testbed was to evaluate

the time frame required to integrate AAN with real

hardware. We ran Cisco ASR 9000 routers running

IOS-XR 5.1.1 that provides OpenFlow support as the

SDN switches in the testbed.

To evaluate the feature velocity and applicability

of AAN, we decided to use both Pox

and Open Day-

light

as SDN controllers. To demonstrate the idea,

we implemented AA-services for QoS management

and load balancing, both of which beneﬁts from the

application-aware approach.

The testbed (depicted in the Figure 2) is composed

of different types of endpoint devices and applica-

tions, including both proprietary and open sources de-

vices. Two Cisco phones and two Jabber clients are

registered with a Cisco Uniﬁed Communication Man-

ager and adopted SIP to establish audio/video ses-

sions. Phones and Jabber clients make video calls,

thus each producing two media network ﬂows for

each call: audio and video. In addition, a video and

audio stream were multiplexed in a single network

ﬂow from a server to a VLC

client. Jabber and VLC

have been enhanced with the adoption of the MSI

library (Cisco Systems, 2013), thus becoming AA-

endpoints.

Jabber 1 Jabber 2

IP Phone 1

IP Phone 2

Cisco Unified

Communications

Manager

Cisco Unified

Presence

Server

VLC Client VLC Server

ASR 9000-1 ASR 9000-2

Application Aware Service,

AAN/SDN Controller

ASR 9000-3 ASR 9000-4

Figure 2: Topology used in our testbed.

The application-aware control plane is detailed in

the Figure 3. Three sources of information about

applications and their ﬂows are present: AMs, AA-

endpoints, and session parsers that gathered addi-

tional information from packets passed from the SDN

controller.

http://www.noxrepo.org/pox/about-pox/

http://www.opendaylight.org/

http://www.videolan.org/vlc/index.html

SDN Controller

(POX/Open Daylight)

Session

Parsers

Database

Endpoint

manager

Application Aware Controller

Endpoints

Application Aware Service

Application

Managers

Figure 3: Application-aware control plane in the testbed.

The ASR 9000 routers are instructed (via Open-

Flow) to punt SIP packets coming from the Cisco IP

phones and the Jabber clients to the SDN controller.

Those SIP packets are then passed to a Session Parser

(SP) module, basically a DPI engine. Because Cisco

phones are conﬁgured not to encrypt signaling trafﬁc,

their SIP packets are then parsed by the SP module.

The SP module, in turn, collects SIP session details

and pushes them to the common database thus map-

ping network ﬂow details to application.

Jabber ﬂows are instead announced by MSI to the

AA-Endpoint manager that, similarly to SP, stores the

Jabber application to network ﬂows mapping into the

common database. The same mechanism is adopted

for the VLC client that announces the RTP ﬂows car-

rying the video and audio through MSI to AAC.

Because information gathered from all sorts of

sources is stored in the same database, the produc-

tion and the consumption of the information is decou-

pled. Normalisation is then applied on all the acquired

data, according to the degree of reliability and com-

pleteness of the sources. For example, SIP packets

generated by Jabber clients are not only advertised by

MSI but also by the SP module (if they are not en-

crypted). This happens because the SIP packets are

punted to the SDN controller and handled to the SP

module. Therefore normalisation enables for merging

of the information coming from both sources, giving

higher priority to the information provided by MSI as

it is more reliable.

The testbed AAC treats the sources of information

according to the following priorities:

• Application managers are operated by network

administrators and are the most reliable source.

Information about both encrypted and unen-

crypted trafﬁc is visible. They cover only the ap-

plications provided inside the testbed.

• AA-Endpoints have a little bit lower reliability as

the endpoint can provide false information as a

result of a virus infection or malicious tamper-

ing with MSI library. Nevertheless, MSI signals

TowardsaRealApplication-awareNetwork

information about relations between ﬂows. AA-

Endpoints also provide information about both

encrypted and unencrypted trafﬁc.

• SP is the less reliable source as it cannot decrypt

encrypted ﬂows and there is a risk of false positive

or false negative identiﬁcation of a protocol.

The rest of this section describes AA-services

tested in our testbed.

4.1 QoS Management

To demonstrate the beneﬁts of AAN, we built a ser-

vice that leverages the AAC in order to assign a

QoS policy to enduser applications detected in the

network. In two weeks, we were able to develop

the AAC and the QoS management AA-service from

scratch. Network administrators can inﬂuence the

network behaviour and assign priorities to speciﬁc

business critical applications (Choukir et al., 2013).

AAN allows to set up the priorities in a convenient

and network-wide consistent manner.

4.2 Path Load Balancing

The following experiments (Pol

ak, 2014) focused on

routing and path load balancing. The goal of this AA-

service was to show that it is possible to operate the

AAN network even if not all ﬂows are recognized by

the AAC.

Two sets of applications were operated in the

testbed: 1) those running on AA-endpoints and

2) those that initiated ﬂows that were not advertised

to the AAC, i.e. those that created background trafﬁc.

The aim of the AA-service was to load balance the

trafﬁc of the business-critical applications across all

possible paths between the source and destination. In

case the AA-service detected that a link carrying pri-

ority trafﬁc was congested, the AA-service automati-

cally rerouted the trafﬁc to links with sparse capacity.

Hence, even if the link was congested because of traf-

ﬁc from legacy endpoints (that were not application-

aware), the AAN architecture allowed to ensure that

the priority trafﬁc reaches its destination without un-

necessary retransmits.

4.3 Other Services

The presented QoS management and load balancing

service is just an example of how network manage-

ment can be made easy when the network can iden-

tify and directly handle applications rather than ﬂows.

Our approach can be applied to any network feature

by custom services providing path computation, rout-

ing, etc. The underlying infrastructure that gives ap-

plication awareness remains the same.

5 CONSIDERATIONS

In this section, we compare the AAN to a classical

distributed network and to an SDN network without

application awareness. Moreover, we describe a pos-

sible behaviour of an AAN in typical network scenar-

ios.

5.1 Evaluation

Being built on top of an SDN network, the AAN

maintains the main advantages of the SDN architec-

ture while reducing the complexity of applying the

correct policies to related ﬂows (typically belonging

to a single application).

When expressing a policy, a combination of ﬂow

characteristics is used to determine the trafﬁc for

which the policy is enforced. The combination of

these characteristics deﬁnes a class of trafﬁc (a.k.a.

class-map). IP addresses, port numbers and applica-

tion names are examples of such characteristics. We

deﬁne the complexity as the number of network nodes

where a class-map must be explicitly declared multi-

plied by the number of entries in the policy itself. Let

us consider a network of N nodes with the number

of applications denoted as A, each application carry-

ing F different ﬂows in average. The total number of

rules or policies conﬁgured and managed in the net-

work may be evaluated in the following way:

• In a conventional network, a rule has to be dis-

tributed for each ﬂow of each application on ev-

ery network node. Therefore, the total complexity

can be evaluated as A × F × N.

• In case of an application-aware distributed net-

work (AA-distributed network), for instance

Metadata-aware network, the complexity reduces

to A × N since the network can deal directly with

applications instead of ﬂows.

• In SDN, the controller (or the set of cooperating

controllers) abstracts the complexity of program-

ming each node separately. However, a rule for

each ﬂow must be explicitly declared; thus, the

total complexity in this case becomes A ×F.

• In AAN, application policies are handled in a

straightforward manner since the complexity with

ﬂows is abstracted by the AAC; thus, the number

of class-maps that need to be speciﬁed reduces to

A, the number of applications.

DCNET2015-InternationalConferenceonDataCommunicationNetworking

Table 1: Comparison of available solutions to enforce policies for speciﬁc applications.

Conventional AA-Distributed SDN AAN

Policy complexity A ×F ×N A × N A × F A

Feature Velocity Slow Slow Fast Fast

Consistent behavior No No Yes Yes

Operational cost High Medium Low Lowest

Feature velocity in distributed environments de-

pends on the number of different operating systems

and different hardware platforms to be supported. In

the case of SDN and AAN, the decoupling of the

capabilities exposed by the network platforms and

the ﬂow characteristics allows for an increased ve-

locity in delivering application-aware features. This

is achieved through writing software (service) once

rather than integrating software into different net-

work platforms. Hence, the feature velocity of SDN

and AAN is fast compared to conventional or AA-

distributed networks.

The control plane abstraction ensures that there is

a single set of policies applied to all SDN switches in

the network. In comparison, the cumbersome man-

agement of consistent rules on each node might re-

sult in inconsistent conﬁguration and unpredictable

behaviour of the network. Therefore, the operator has

to maintain N conﬁgurations.

In a conventional deployment, the policy com-

plexity often results to a high number of class-map

rules. The class-map rules has to be managed directly

on the network nodes in consistent manner. Main-

tenance of the consistency incorporates high opera-

tional costs accompanied with with slow feature ve-

locity. Despite lower complexity of AA-distributed

deployment, it still requires medium operational costs

as it requires big effort to maintain consistent be-

haviour. The decoupling of control and data plane

and the abstracted complexity of the network lowers

the operation costs of both SDN and AAN. Neverthe-

less, AAN additionally treats application ﬂows in a

consistent manner.

The comparison is summarized in Table 1.

5.2 Typical Scenarios

Let us consider some speciﬁc scenarios to illustrate

the beneﬁts deriving from the deployment of an AAN.

5.2.1 Network Congestion

Although congestion of a link is easy to detect in a

distributed network, none or few network technolo-

gies exist to react and reroute ﬂows in a timely way.

With SDN, the controller can immediately re-

route the trafﬁc depending on the network data as

queue occupancy or interface load increase. How-

ever, the information available to an SDN controller

are limited to the transport layer.

Compared to an SDN network, AAN offers two

main advantages. Firstly, the routing operations can

be based on application requirements; thus all ﬂows

of a single application are handled in a consistent way

without the complexity of matching ﬂows by the SDN

application. The second, and more signiﬁcant advan-

tage, is that the AAC can potentially access applica-

tion speciﬁc metrics and eventually, it can detect the

looming suffering of an application in advance.

5.2.2 Topology Change

In the event of a topology change that impacts the path

of ﬂows with speciﬁc requirements, a regular Medi-

anet solution requires a new distribution of Medianet

tagging in the new path. If the change reoccurs with

some frequency because of physical impairments, it

can result in a ﬂapping behavior and degraded qual-

ity. AAC with complete network and application view

can instead choose a stable path that avoids the above-

mentioned issues.

5.2.3 Application Policy Change

In a Medianet network, whenever application require-

ments change, the new requirements are pushed by

administrator to the network devices through conﬁg-

uration. Administrator has to foresee possible prob-

lems in advance so that the change targets only af-

fected devices; and avoids changes to unrelated trafﬁc

so that a single change does not trigger an avalanche

of changes. In AAN, the new application require-

ments are enforced on all affected devices by the

AAC, which has the complete view of all ﬂows and

their paths.

5.3 Migration

As AAN raises several requirements on AA-

endpoints, it is not expected that the migration is in-

stant and straightforward. Instead, several progressive

steps can ease AAN deployment.

Firstly, plug-ins to critical application managers

can advertise instantly information about ﬂows of all

hosts related to the speciﬁc application. As discussed

TowardsaRealApplication-awareNetwork

in Section 4, the beneﬁts of AAN may be utilised even

if the metadata are available for only a limited num-

ber of ﬂows. Hence it is not necessary to migrate all

endpoints to leverage the beneﬁts of AAN.

In case it is not possible to deploy a plug-in for

a business critical application, unreliable DPI-based

source of information or similar techniques can pro-

vide some information about ﬂows in the network.

Finally, IETF aims to establish Application En-

abled Open Networking working group (IETF, 2014).

The current charter proposal includes standardisa-

tion of Metadata signaling. Once standardized, the

amount of applications supporting Metadata signal-

ing should raise, and consequently, the deployment of

AAN for arbitrary application should be easier.

6 CONCLUSION

User expectations of network applications quality are

high even for multimedia streaming. The ever grow-

ing number of applications communicating through

the network environment highlights the need for

constructing networks that are capable of achieving

application-level control of trafﬁc to ensure appropri-

ate QoE. Traditional means of ensuring appropriate

QoS for applications, such as DPI, have a high com-

plexity and operational costs while the behaviour is

not consistent across the whole network. SDN-based

approach, on the other hand, provides consistent be-

haviour and fast feature velocity but it does not auto-

matically treat related ﬂows in a consistent way.

This paper presented a novel paradigm of

Application-Aware Network (AAN) based on indus-

try and open standards. The solution we presented

achieves a number of major goals:

• AAN improves ﬁnal user QoE based on the feed-

back from applications received through MSI,

• AAN brings application awareness to Cisco IOS-

XR routers such as ASR 9000,

• AAN extends network to include endpoints and

endpoint applications,

• AAN brings fast application velocity (the whole

project has been developed within two weeks),

• AAN enables application-based policy enforce-

ment.

Future extensions and improvement of this work

are under consideration and development. Among

these, we are investigating the ability to provide hints

to the application mediator through MSI and addi-

tional abstraction levels that can help in solving con-

tention and inconsistencies between applications in

the network.

REFERENCES

Bendrath, R. (2009). Global technology trends and national

regulation: Explaining variation in the governance of

deep packet inspection. Technical report, Delft Uni-

versity of Technology. Paper originally prepared for

the International Studies Annual Convention.

Bredel, M., Barczyk, A., and Newman, H. (2013).

Application-aware trafﬁc engineering for wide area

networks using openﬂow. In SuperComputing Con-

ference, Emerging Technologies.

Choukir, A., Caldarola, L., Cuda, D., Dondero, M.,

Ficara, D., Muccifora, R., Pol

ak, L., and Triﬁlo, A.

(2013). Towards a real application aware network.

http://youtu.be/QHYPhAhIwVw.

Cisco Systems (2013). Cisco MSI Deployment Guide.

http://www.cisco.com/web/solutions/medianet/docs/

Cisco MSI Installation Guide.pdf.

Curtis, A. R., Kim, W., and Yalagandula, P. (2011). Ma-

hout: low-overhead datacenter trafﬁc management us-

ing end-host-based elephant detection. In IEEE IN-

FOCOM.

Dainotti, A., Pescape, A., and Claffy, K. (2012). Issues

and future directions in trafﬁc classiﬁcation. Network,

IEEE, 26(1):35–40.

Das, S., Yiakoumis, Y., Parulkar, G., and McKeown, N.

(2011). Application-aware aggregation and trafﬁc en-

gineering in a converged packet-circuit network. In

Optical Fiber Communication Conference and Expo-

sition (OFC/NFOEC) and the National Fiber Optic

Engineers Conference.

Fraleigh, C., Moon, S., Lyles, B., Cotton, C., Khan, M.,

Moll, D., Rockell, R., Seely, T., and Diot, S. (2003).

Packet-level trafﬁc measurements from the sprint ip

backbone. Network, IEEE, 17(6):6–16.

IETF (2014). Application Enabled Open Network-

ing (AEON). https://sites.google.com/site/

aeonsignalling/.

Jarschel, M., Wamser, F., Hohn, T., Zinner, T., and Tran-

Gia, P. (2013). SDN-based Application-Aware Net-

working on the Example of YouTube Video Stream-

ing. In European Workshop on Software Deﬁned Net-

works.

McKeown, N., Anderson, T., Balakrishnan, H., Parulkar,

G., Peterson, L., Rexford, J., Shenker, S., and Turner,

J. (2008). Openﬂow: Enabling innovation in cam-

pus networks. SIGCOMM Comput. Commun. Rev.,

38(2):69–74.

Moore, A. W. and Papagiannaki, K. (2005). Toward the

accurate identiﬁcation of network applications. In

Dovrolis, C., editor, Passive and Active Network Mea-

surement, volume 3431 of Lecture Notes in Computer

Science, pages 41–54. Springer Berlin Heidelberg.

Pol

ak, L. (2014). Integration of SDN and Medianet Meta-

data. http://youtu.be/CqDYn4-DKn8.

Wilkins, S. (2011). Designing for Cisco Internetwork So-

lutions (DESGN) Foundation Learning Guide (CCDA

DESGN 640-864). Pearson Education.

Zhang, D., Mai, S., Guo, H., TakehiroTsuritani, Wu, J., and

Morita, I. (2013). Openﬂow-based control plane for

the application-aware lobs network. In OptoElectron-

ics and Communications Conference.

DCNET2015-InternationalConferenceonDataCommunicationNetworking