Software-Defined

Network Analytics and OpenFlow / SDN

by pmoyer on ‎01-29-2013 10:40 AM - last edited on ‎10-28-2013 09:42 PM by bcm1 (5,183 Views)

I’m going to chat about some very cool OpenFlow/SDN-related enhancements to Network Analytics. Network Analytics can mean many things to many different people, but the definition I’m going to base this discussion on is the one we use here at Brocade. We often refer to this capability as Network Telemetry and here is our definition taken directly from our website:

 

Network telemetry is used by organizations to monitor their networks for packet inspection and analysis, security intrusion and attack detection, intelligence-gathering, application performance management, and a wide range of other applications.

 

And further, Wikipedia defines telemetry as: “Telemetry is a technology that allows data measurements to be made at a distance. The word is derived from the Greek roots: tele = remote, and metron = measure.”

 

So, network telemetry solutions provide a remote network data monitoring capability. The monitored (eg. captured) data is then processed and analyzed, which provides all kinds of visibility into application data types and traffic flows; including availability and performance information. The resulting analysis of this data is then used for network and application optimization, service level agreement validation, various security related functions, and many other uses including identifying additional revenue and business opportunities.

 

12.jpg

 

This type of capability is becoming particularly important as Big Data becomes increasingly wide spread; basically, providing the ability to monitor and capture this data and then to analyze and make sense of this data for operational or business purposes.

 

Before discussing how OpenFlow & SDN can augment and improve this solution, I’ll briefly explain how network telemetry & analytic solutions function. To start with, this solution requires high-performance, high-density telemetry-capable network switches that are connected to the production network of an enterprise or service provider. These telemetry-capable switches operate in a passive manner; meaning that they are not integrated with the production switches and routers that are running L2 or L3 protocols in the network. The customer implements a network tap or port mirror capability in their network; with the telemetry switches being connected in a way to directly receive the production network traffic. In medium to large networks there could be tens or even hundreds of these telemetry switches attached to the network.

 

The network telemetry switches are then connected to analytics platforms of various sorts. Depending on the customers’ use case, these analytic platforms provide specialized capabilities to process and examine various types of applications (eg. VoIP analytics).

 

The analytics platforms run special applications that present and display the results of the analysis. Operators interact with the analysis software layer of the solution to interpret the results and to also determine, proactively and reactively, which types of traffic should be monitored based on a specific use case. The operator then “re-programs” the network telemetry switches to filter on different types of data or flows. This filtered data is sent to the analytics platforms for analysis. The capability to re-program the telemetry switches creates a closed-loop solution, fully controlled by the operator. The telemetry switches basically perform access control list (ACL) and policy-based routing (PBR) functions. The ACL-like functionality performs the traffic matching capability (eg. “what to monitor”), while the PBR-like functionality determines which ports to forward the monitored or replicated data out of (eg. “where to send it”). It should be noted that the telemetry switch must possess certain high-performance functions, such as line-rate ACL-like matching and line-rate traffic replication and forwarding. Hmmmm … the Brocade MLX platform happens to have these unique capabilities, but more on that later.

13.jpg

So that, in a nutshell, describes how a network telemetry & analytics solution works today. An operator determines which types of traffic is to be monitored and by interacting with the analysis application software, indirectly programs the network telemetry devices. This programming is typically done via command line interface (CLI) and/or scripts and could be quite cumbersome and complex, depending on the scale of the overall telemetry solution. It’s also not exactly a real-time system; as the operator needs to determine which type of configuration or script is required to be run in order to monitor a specific traffic type. The type of traffic to be monitored changes over time and could change in time intervals of hours or even minutes. This results in constant re-programing of the telemetry switches. The resulting configuration of the telemetry switches can become quite large and complex configuration files, which can result in a daunting operational and management challenge. This solution is in production in many large networks today and functions fine based on existing protocols and technologies.  But as I point out, there are some limitations in terms of real-time dynamics and configuration & script complexity.

 

So, what does OpenFlow & SDN have to do with network telemetry & analytics you ask? Well, the answer will soon be -- a lot!

 

But before I get into any specifics, I’d like to emphasize an area of SDN that holds quite a bit of promise but is often neglected. Most people think of SDN in terms of programming the network; in other words, pushing capabilities into the network. But equally important is unlocking and harvesting the intelligence and data that is available inside the network; in other words, pulling information from the network. It is this very critical latter capability that network telemetry & analytics provides.

 

As we know, OpenFlow provides a simple programmatic interface into the network. With that type of capability, OpenFlow appears to be the ideal protocol to replace the current CLI and script driven programming of the telemetry switches. As discussed, the current programmatic process entails configuring ACL-like functions to match and filter on specific types of traffic flows and PBR-like policies to determine which port(s) on the switch to forward that traffic out of. Why can’t OpenFlow be leveraged to do this instead? OpenFlow performs flow matching (eg. ACL-like functions) and also determines the forwarding behavior for those flows (eg. PBR-like functions). OpenFlow can not only be used to simplify the programming of the telemetry switches, but could do this in a much more dynamic manner. It would also drastically reduce the configuration file size and complexity of the telemetry switches. And couldn’t the analysis applications that operators interface with sit on top of an OpenFlow controller, instead of on top of the analytics platforms themselves?  If so, that in effect would create a Software Defined Networking capability that leverages OpenFlow for the programmatic interface.

 

 

 

Cool, huh? So, there you have it …

 

 

Today’s network telemetry & analytics solutions could indeed evolve into full OF/SDN solutions. This type of solution appears to be a perfect fit for leveraging the capabilities of OpenFlow. Think about replacing all the complex CLI and script driven programming of the telemetry switches with OpenFlow. How much simpler would that be? Not only is such a “southbound” programmatic interface like OpenFlow simpler and more dynamic in terms of real-time programming, but it’s also an industry standardized interface. Imagine that.

 

14.jpg

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Today, Brocade offers a very powerful and capable Network Telemetry & Analytics solution using our MLX platform, which is combined with a tightly integrated network analysis software suite from IBM. This partnership was developed specifically for this emerging area of network analytics. Here are some details of this integrated solution:

 

·       Brocade MLXe + IBM InfoSphere Streams is an end-to-end solution for advanced network telemetry, network intelligence or security applications

·       MLXe extracts and delivers real-time network data; IBM InfoSphere Streams analyzes the data, resulting in actionable insights

·       MLXe is a carrier class, high-performance, telco-grade platform; capable to filter, aggregate, and replicate network traffic at line-rate speeds

o   Provides network visibility for the purposes of monitoring, reporting, and analyzing traffic information and data

·       IBM InfoSphere Streams provides a state-of-the-art computing platform that enables companies to turn burgeoning data volumes into actionable informationand business decisions

o   A highly scalable, agile software infrastructure that enables in-motion analyticson a wide variety of data types at unprecedented volumes and speeds

 

With the emergence of the Software Defined Networking era, traditional solutions such as this will soon integrate technologies such as OpenFlow. These advanced solutions will provide more dynamic capabilities while also simplifying the operations and management of the network devices. SDN is not just about the dynamic programming of state into the network, but is also critical to extracting state from the network. So, stay tuned for news related to developments such as this in this exciting and emerging Software Defined Networking era!