• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Mrv wp-application-aware-networking
 

Mrv wp-application-aware-networking

on

  • 255 views

 

Statistics

Views

Total Views
255
Views on SlideShare
255
Embed Views
0

Actions

Likes
0
Downloads
9
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Mrv wp-application-aware-networking Mrv wp-application-aware-networking Document Transcript

    • White paper 1 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. 1 - CRM = Customer Relationship Management 2 - Global IT spending on Cloud Computing will reach $US109 billion in 2012 (Gartner - http://www.gartner.com/newsroom/id/2163616 ). 3 - Easynet study - May 2012 (http://www.easynet.com/gb/en/about/pressRelease.aspx?TertiaryNavID=783&PressReleaseID=1586)
    • 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. 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. Figure 2: The High-level Telco 2.0 Business Model 4 - See Enterprise Management Association (EMA) report at http://www.enterprisemanagement.com/web/ema_ac0113.php 5 - See http://www.stlpartners.com/telco2_index.php Protocol SMTP FTP TELNET NTPHTTP BGP 25 20/21 23 12380 179TCP/UDP Ports # Protocol How Do Protocols Relate to TCP/UDP Ports # ? Developers Retailers Goverment Media Advertisers Utilities Finance Core Services Assets and Capabilities New B2B Platform Services Millions of customers Thousands of Segments Hundreds of devices Upstream Customers Telco Downstream Customer
    • 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. 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. 6 - The network peer is where the wireline and wireless carriers connect to the Internet-Service-Providers (ISPs) 7 - See: http://policychargingcontrol.com/market-forecast-deep-packet-inspection eNodeB EPC DPI Internet Mobile Backhaul 6
    • 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. 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 Figure 5: The sFlow Model - Monitored Devices Send Sampled Frames to an sFlow Collector 8 - See www.sFlow.org 9 - Implemented on new generation OptiSwitch® Carrier Ethernet 2.0 Series (OS906G and OS940) Access Aggregation Core Peering ISP 1 ISP 2 BGP Multi Layer Access Device Dedicated DPI Chassis - 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 Network
    • 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. 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 : Internet NetFlow Exporter NetFlow Exporter NetFlow Exporter Queries Flow Storage Analysis Console Remote Site #2 Remote Site #1 LAN
    • 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. 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). Figure 9: Critical Applications Might Get Poor QoS Netflow sFlow Not sampling - analyzes every frame If there is no dedicated hardware it will be done on the CPU and leads to ~30% degradation in performance Provides the full story and can be used for network security purposes (implemented on most firewalls) Sampling Based Tapping Service Does not exhaust substantial resources from device (CPU or switching band- width) Good enough to know what your custom- ers are doing with their network Not adequate for detecting / handling with security breaches Web Surfing Video Conferencing
    • 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. Figure 10: Software/Hardware based Solution for the Next Phase into AAN Customer traffic Adding support for new protocols SDN View (from Service Management & Provisioning System) Offloading full flows to new engine Sampling to CPU Dedicated HW DPI Engine Software Solution Activated on Commercial off-the- shelf
    • 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. 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. MRV-WP-AAN Copyright © 2013 MRV Communications, Inc. All Rights Reserved. For more information contact info@mrv.com or visit www.mrv.com 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 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.