Application-Aware Networking White Paper

White paper
Application-Aware Networking at A Glance
OVERVIEW
Application-Aware Networking (AAN) designates a set of tools and solutions for boosting utilization of network resources based
on customer demand through applications such as CRM systems (e.g. Salesforce.com) and video conferencing systems (e.g., Skype,
MS Lync, etc.). Although in the past relatively dumb networks may have sufficed in coping with customer demands, but this is no
longer the case today. As more and more applications migrate into the cloud and best-effort Quality Of Service (QoS) is no longer a
satisfactory solution, a new breed of intelligent networks is required. In addition, as service providers (SPs) see their revenues shrink
and an increasing number of business slip to application providers or Over-The-Top (OTT) players, a new strategy is needed that
enables them to regain their position in the market.
This strategy calls for the adoption of new business models that require deeper analysis of protocol stacks. In this white paper we
provide a detailed description of the changing network environment that sheds light on AAN. We also describe a set of tools for
monitoring customer applications, compare the merits of each tool, explain how one controls resources based on this knowledge,
and eventually show how all of this relates to the new trend of Software-Defined-Networking (SDN).
WHAT IS APPLICATION-AWARE NETWORKING ?
Application awareness is a broad term that has different meanings for different network appliances. Some appliances, such as
firewalls, WAN optimizers, and application-delivery controllers are application aware by definition and implement various actions on
transferred application data. Even these appliances have changed their “awareness” level significantly in the past 10 to 15 years as they
are now looking deeper into the protocol stack in order to make the right decisions and take the appropriate actions.
The term Deep-Packet-Inspection (DPI), associated with Application Awareness, describes the actual technical functionalities
performed in AAN. However, the term is usually used in a much broader context and it describes a broader set of functionalities than
the one we’ll address in this paper. In the world of Layer 1 – Layer 3 transport services, Application Awareness refers to the set of tools
service providers and enterprises can use to optimize network resources and meet the actual performance requirements (bandwidth,
delay, jitter, etc.) of the overlay applications. A good example of such optimization is the use of dedicated hardware queues and a
choice of the shortest path for mission critical, delay-sensitive, financial applications such as algorithmic trading.
Another good example is the provisioning of high-priority Service Levels Agreements (SLAs) for video conferencing as opposed to
medium and low-priority SLAs for email exchanges or standard CRM1 systems, such as Salesforce.com.
Carrier-Ethernet devices, such as MRV’s OptiSwitch® series, are deployed by service providers to deliver business services.
Accordingly, they will mainly facilitate the transfer of business applications and not private consumer applications. Typical
business applications would include: Salesforce.com, Microsoft 365, Oracle cloud applications, SAP cloud applications, Microsoft
Lync, Skype, and so on. In the past, these applications resided within the enterprise LAN. However, with the massive transition to
cloud-based services2 virtually all application traffic will traverse WAN links beyond the LAN. A new study, conducted at the end of
2012, shows that 82% of European organizations suffer from application performance problems3 caused mainly by data transfer
bottlenecks and unpredictability on the WAN.
The market trends and difficulties noted above, together with the requirement of business-critical applications4 , create new
opportunities for service providers in delivering dedicated application-based services. Ten years ago, providing such services might
have been as simple as providing Layer 4 visibility. If a router could inspect the TCP/UDP port destination, it could have made an
educated guess about the nature of the application and apply the appropriate QoS policy.
CRM = Customer Relationship Management
Global IT spending on Cloud Computing will reach $US109 billion in 2012 (Gartner - http://www.gartner.com/newsroom/id/2163616 ).
3Easynet study - May 2012 (http://www.easynet.com/gb/en/about/pressRelease.aspx?TertiaryNavID=783&PressReleaseID=1586)
12-
1
White paper
With the same information, a firewall could decide whether to allow or deny traffic. If traffic was headed to TCP Port 80, for
example, it was pretty clear that it was HTTP traffic and typically received only best-effort QoS. Today, as we mentioned above,
best effort isn’t good enough and knowing the Layer 4 port is inconclusive. Why? Simply because in today’s networking world,
hundreds of applications can run over the same TCP/UDP port. Only by getting more detailed information about each application
can a network element make the proper decisions and take the appropriate actions.
How Do Protocols Relate to TCP/UDP Ports # ?
Protocol
HTTP
SMTP
FTP
TELNET
NTP
BGP
TCP/UDP
Ports #
80
25
20/21
23
123
179
Protocol
Figure 1: Recognizing Protocols and Applications
WHY IS APPLICATION-AWARE NETWORKING IMPORTANT ?
AAN is not a new concept. It regained momentum in the last few years due to several emerging technological and market trends.
First, from the commercial and market perspective, the ruling business model that separates the application providers (Netflix,
Yahoo, Google, Amazon, Salesforce.com, etc.) from the service providers that own the network infrastructure turned out to be
a big problem for the service provider. Application providers have been increasing revenues by monetizing the major network
infrastructure investment made by the service providers.
Application-awareness enables service providers to regain control over their network resources and take back some of the power
the OTTs have gained and put it back into the hands of the actual owners of network infrastructures. New business models, widely
known as Telco 2.05 , are based on intelligent networks that collect and maintain information about the applications using the
network resources. As a result, network resources can be optimized to suit the exact needs of the applications. This enables service
providers to monetize their investments in network infrastructure by offering end-customers and OTTs new tailored services.
Upstream
Customers
Telco
Developers
Retailers
Goverment
Media
Advertisers
Utilities
Finance
Core
Services
Assets and
Capabilities
New B2B
Platform
Services
Downstream
Customer
Millions of
customers
Thousands
of
Segments
Hundreds
of devices
Figure 2: The High-level Telco 2.0 Business Model
45-
See Enterprise Management Association (EMA) report at http://www.enterprisemanagement.com/web/ema_ac0113.php
See http://www.stlpartners.com/telco2_index.php
White paper
Another trend that stirs up market discussion on application awareness is network appliance convergence. As service providers
seek to reduce their capital and operational spending, the attempt to converge various departments in the organization and
to build a leaner and easier-to-manage network becomes one of their primary goals. As a result, telecom equipment vendors
are bringing new and more powerful platforms to market that support the convergence of services. Packet Optical Transport
Platforms (POTP) that facilitate the convergence of L1 to L3 services in a single platform is one such example. New routers that
support firewalling and WAN optimization services are another example that offers a huge advantage. These routers closely
integrate all these services in a single application-aware device that can pass specific applications to the firewall, or can optimize
(throttle) the delivery of certain applications across the WAN.
HOW COMPLICATED IS THE TRANSITION TO APPLICATION-AWARE NETWORKING ?
While application awareness for Layers 4-7 already exist within appliances focused on applications, such intelligence in basic OSI
layer network elements is obviously missing. Incorporating intelligence there is a challenging task for both the telecom equipment
vendors and the service providers that are about to deploy them.
First, from the engineering perspective, transport devices are optimized for L1-L3 forwarding and do not have the proper
hardware to perform line-rate forwarding while examining applications. Proper application-aware devices might need a dedicated
hardware engine to perform DPI actions while maintaining a reasonable level of device performance. So far, the additional
hardware cost led the industry to incorporate DPI engines only in large core devices that are less sensitive to increasing cost versus
multi-layer access devices that are more cost effective to produce. We will later show, however, that incorporating such engines
within the multi-layer access device is actually the best and most cost effective way to build modern and intelligent networks.
Second, even after new application-aware multi-layer access devices have been developed, transport departments within service
providers need to overcome their own set of obstacles in order to deploy and use these appliances properly. They must acquire
the needed technical skill-set and become familiar with the various applications used by their customers. They also need to
become familiar with the performance requirements of these applications. And last but not least, service providers must adopt
new business models that justify the investments needed to transition to application-aware networking.
WHERE SHOULD SERVICE PROVIDERS IMPLEMENT THEIR DEEP PACKET INSPECTION FUNCTIONS?
DPI technologies have existed for around 15 years. Most of the vendors associated with this market have built large and dedicated
DPI chassis that are usually deployed in the network core and peer6 segments.
Internet
EPC
DPI
eNodeB
Mobile Backhaul
6
Figure 3: A Common Deployment Scenario of a DPI function in LTE Backhaul
The benefit of placing such appliances in these strategic network locations is usually associated with simple management as
such network locations require less devices to manage than in locating multiple devices in aggregation and access segments.
Yet the need to place large DPI dedicated appliances in a provider core might explain why the DPI market is not as large as we
expect a 15 year old industry to be (the market was found to garner around $600 million USD by the end of 20127). In addition,
placing DPI devices at the network peering points also creates technical difficulties as a lot of traffic passing to and from the ISPs
is asymmetric. Often this asymmetry causes these DPI platforms to see only partial flows and to encounter difficulties in analyzing
them. These processing difficulties arise even before QoS policies are applied in processing.
67-
The network peer is where the wireline and wireless carriers connect to the Internet-Service-Providers (ISPs)
See: http://policychargingcontrol.com/market-forecast-deep-packet-inspection
White paper
The alternative for deploying expensive DPI-dedicated platforms in the core is to incorporate relevant DPI engines in access
platforms such as multi-layer access devices. For the purpose of providing the right end-to-end QoS for business applications
passing to and from the enterprise, DPI supporting multi-layer access devices is the right way forward. First, multi-layer access
devices are exposed to all traffic entering and leaving the enterprise and thus asymmetric flows are no longer an issue. Second,
CPEs are the enterprise gateway to the service provider; they place application frames in the right queues and perform the right
DSCP or L2 priority-bits marking for end-to-end QoS policies.
Access
Aggregation
Core
Peering
ISP 1
BGP
ISP 2
Dedicated DPI Chassis
Multi Layer Access Device
- Full clarity of customer traffic
- Existing appliances
- Cheaper Solution
- Relevant to all business models
- Large and expensive devices
- Problems of Asymmetric traffic
- Doesn’t support all business models
Figure 4: Placing QoS Enforcing DPI Engines in Scattered Locations of the Network
TWO BASIC PROTOCOLS FOR APPLICATION MONITORING
There are two industry-accepted protocols for application monitoring which is usually considered a first phase toward AAN.
These are sFlow, an IETF (RFC 3176) standard, and promoted by the sFlow consortium8 , and Netflow, a Cisco Systems proprietary
protocol that has also become an IETF standard (RFC 3954). The latest version of sFlow is v59 and that of Netflow is v10.
sFlow randomly samples network packets and sends these samples to an outside sFlow Collector that functions as the monitoring
station. For the purpose of monitoring actual usage of various applications and statistical analysis of network utilization, a
uniformly distributed sampling method such as sFlow is considered accurate and robust enough to cope with high bandwidth
services.
sFlow defines two different sampling mechanisms:
• Packet-based sampling: Samples one packet out of a specified fixed number of packets
• Time-based sampling: Samples one packet every specified time interval
Network
Figure 5: The sFlow Model - Monitored Devices Send Sampled Frames to an sFlow Collector
89-
See www.sFlow.org
Implemented on new generation OptiSwitch® Carrier Ethernet 2.0 Series (OS906G and OS940)
White paper
sFlow frames sent from the sFlow supporting Network Elements to the sFlow collector are UDP packets destined to the specified
host and UDP port (by default, this is port 6343). The lack of reliability in the UDP transport mechanism does not significantly affect
the accuracy of the measurements obtained from an sFlow agent. Each sFlow datagram provides information about the sFlow
version, the originating device’s IP address, a sequence number, the number of samples it contains and one or more frames and/or
counter samples.
Similar to sFlow, NetFlow also collects traffic frames and later exports a statistics summary of the analyzed flow via a standard
NetFlow record which is also a set of UDP frames (usually destined to port 2055). The Netflow system is also comprised of a
Netflow client (or Exporter) and a NetFlow Collector, typically, a server that does the actual traffic analysis.
Internet
Remote
Site #2
NetFlow
Exporter
Remote
Site #1
NetFlow
Exporter
NetFlow
Exporter
LAN
Queries
Flow
Storage
Analysis
Console
Figure 6: The NetFlow Model - Monitored Devices Send Flow Summaries to Flow Collectors
Figure 7: sFlow Collector Showing what Applications are Running in the Network
THE DIFFERENCE BETWEEN SFLOW AND NETFLOW
The most important fact to recognize is that unlike sFlow, Netflow is not based on a sampling technology. Its monitoring
methodology is based on receiving and analyzing every frame in the packet flow. This enables Netflow to provide the “full-story”
behind the flow and thus better recognize security threats as well. Moreover, as Netflow captures the first frames of each flow, it
can easily recognize the user’s applications that are several times harder to recognize than when frames are captured in the middle
of the flow. The need to capture full wire-speed traffic will have severe implications on the performance and design of the Netflow
supporting systems :
White paper
1. Unlike sFlow systems in which the collectors (usually servers) are doing all the traffic flow analysis and the clients simply send
the original frames wrapped in sFlow PDUs, Netflow implementations put much more responsibility on the Netflow clients (usually
routers). The clients analyze packet flows and send the collectors Netflow PDUs with data portraying the used applications and
associated statistics and not the original customers’ frames.
2. Without dedicated hardware engines, the Netflow clients (the routers) will have roughly 30% degradation in performance due
to the above described implementation and the need to inspect the entire traffic flow. Though a Netflow supporting system
can offload traffic to a hardware-based DPI engine in order to avoid degraded performance, that doesn’t mean the engine is
necessarely cost-effective.
3. The effect on performance usually forces service providers to incorporate Netflow systems only for low-speed services (having
bandwidth in the range 10Mbps to 100Mpbs). These low speeds are usually common in L3 services and are no longer sold by
service providers for L2 services.
Netflow
sFlow
Not sampling - analyzes every frame
Sampling Based Tapping Service
If there is no dedicated hardware it will
be done on the CPU and leads to ~30%
degradation in performance
Does not exhaust substantial resources
from device (CPU or switching bandwidth)
Provides the full story and can be used
for network security purposes
(implemented on most firewalls)
Good enough to know what your customers are doing with their network
Not adequate for detecting / handling
with security breaches
Figure 8: Netflow vs. sFlow
FROM SFLOW/NETFLOW TO A COMPLETE AAN AND HOW IT IS ALL CONNECTED TO SDN
As mentioned before, since most applications today cannot be identified or correctly prioritized y standard TCP/UDP ports, critical
applications (for instance, Lync video conferencing) might get poor QoS in competing for the same resources as other non-critical
applications (for instance, standard web surfing).
Web
Surfing
Video Conferencing
Figure 9: Critical Applications Might Get Poor QoS
White paper
Therefore, the real motivation behind AAN is to provide each application its actual desired transport characteristics, or more
formally, to enable service providers to set QoS parameters to the application flows, to dynamically manage bandwidth
consumption of every application,and perhaps even to choose optimal routes between application clients and their respective
servers.
sFlow and Netflow are both monitoring standards. As such, they can only be considered a first phase toward AAN. As a sampling
mechanism, sFlow cannot provide a solution to the problem we just described. At most, it can only be part of such a solution. In
order to guarantee certain QoS to specific applications, the system must access all frames belonging to the application flow.
Though Netflow complies with this last requirement, it still needs to be associated with a marking mechanism that has an adverse
effect on the already problematic performance issue we described in the previous section.
To really achieve the goal described above without significantly impacting traffic performance there are two feasible solutions:
A A hardware based solution: Adding a hardware-based DPI engine to the deployed multi-layer access device.
Once this functionality is activated, traffic passing through the standard switching-fabric of the device will be directed to this
engine. The emergence of multi-core CPUs capable of transferring multiple 1GE and 10GE traffic are considered a perfect fit
for DPI functionality. These CPUs are de-facto programmable and thus support for new applications can easily be added
without the need to perform forklift upgrades to the hardware.
B A software-based solution: Using mainly heuristics and algorithms, the solution uses sFlow for sampling the customer data
and uses heuristics to better recognize the used application and to identify recurring patterns within the flows’ frames.
Software Defined Networking (SDN) is not the scope of this white-paper. However, we may note that the term indicates a
movement toward software-programmable or software-replaceable network elements. The first approach proposes the use of
programmable multi-core CPUs to which an outside server can connect and download newly supported applications (a new
ERP application, a new e-commerce application, etc.). The second approach can benefit from SDN in two ways. First, by enabling
outside appliances to add new protocol recognition and new pattern recognition algorithms to the local CPU via software
upgrade. Second, by actually running those algorithms on an outside server separate from the forwarding machine.
Dedicated HW
DPI Engine
Offloading full
flows to new
engine
Sampling to CPU
Software
Solution
Activated on Commercial
off-the- shelf
Customer traffic
Adding support
for new protocols
SDN View (from Service Management & Provisioning System)
Figure 10: Software/Hardware based Solution for the Next Phase into AAN
White paper
MRV APPROACH TO AAN
MRV’s approach to AAN solution is implemented through a cost effective solution without forklift upgrades.
MRV’s solution is based on three pillars including:
1- A multi-layer access device (OptiSwitch® Series);
2- A Linux-based Operating System (Master-OS™ control plane software);
3- Orchestration software (Pro-Vision® service provisioning and management system) that enables visibility into multiple
layers across the network, application awareness and sophisticated analytics that help service providers to monetize their
network infrastructure assets.
MRV’s approach to AAN solution provides a software programmable multi-layer access devices which is one of MRV’s SDN solution
components.
MRV’s comprehensive solution is one of the key ingredients for the new networking paradigm of intelligent and Flexible networks
including virtualization, programmability & control, layer convergence, and application awareness.
SUMMARY
In this white paper we provided a detailed explanation about Application Aware Networking. We started with a short description
of the term in the context of network elements that usually provide standard L1 to L3 transport services. We outlined the rationale
behind the transition from simple dumb forwarding to application-aware forwarding is so critical to the service provider’s survival
and yet why this is not a simple transition from both the technical and business perspectives.
We provided a broad view on the various benefits and drawbacks of placing DPI appliances in different locations of the network
and emphasized our belief that locating such appliances at the edge of the service providerís network is the right strategy. We
then moved to describe the two most common standards for monitoring application usage by customers: sFlow and Netflow, and
provided a detailed comparison between the two.
We proceeded with a description of two alternative techniques for actually providing application-based QoS - a software solution
that utilizes heuristics in order to fill the required gaps in common switching fabrics and a programmable hardware solution that
supports DPI with wire-speed forwarding and remains programmable enough for upgrades of new supported applications.
We concluded with a description of MRV’s innovative and unique approach to AAN solution that is implemented through a cost
effective solution without forklift upgrades.
MRV’s approach to AAN solution provides a software programmable multi-layer access devices which is one of MRV’s SDN solution
components.
MRV’s comprehensive solution is one of the key ingredients for the new networking paradigm of intelligent and Flexible networks
including virtualization, programmability & control, layer convergence, and application awareness.
MRV operates worldwide sales and service offices across four continents.
Contact us at info@mrv.com
MRV Communications
Corporate Headquarters
300 Apollo Drive
Chelmsford, MA 01824
www.mrv.com
For more information contact info@mrv.com or visit www.mrv.com
All statements, technical information and recommendations related to the products herein are based upon information believed to be reliable or accurate. However, the
accuracy or completeness thereof is not guaranteed, and no responsibility is assumed for any inaccuracies. Please contact MRV Communications for more information.
MRV Communications and the MRV Communications logo are trademarks of MRV Communications, Inc. Other trademarks are the property of their respective holders.
The OptiSwitch®, Master-OS™ and Pro-Vision® Trademarks and MRV Company Logo are the sole and exclusive property of MRV Communications.
All other trademarks and logos mentioned in this white paper are the property of their respective owners.
MRV-WP-AAN
Copyright © 2013 MRV Communications, Inc. All Rights Reserved.