Mike Fratto

Network Computing Editor


Upcoming Events

Where the Cloud Touches Down: Simplifying Data Center Infrastructure Management

Thursday, July 25, 2013
10:00 AM PT/1:00 PM ET

In most data centers, DCIM rests on a shaky foundation of manual record keeping and scattered documentation. OpManager replaces data center documentation with a single repository for data, QRCodes for asset tracking, accurate 3D mapping of asset locations, and a configuration management database (CMDB). In this webcast, sponsored by ManageEngine, you will see how a real-world datacenter mapping stored in racktables gets imported into OpManager, which then provides a 3D visualization of where assets actually are. You'll also see how the QR Code generator helps you make the link between real assets and the monitoring world, and how the layered CMDB provides a single point of view for all your configuration data.

Register Now!

A Network Computing Webinar:
SDN First Steps

Thursday, August 8, 2013
11:00 AM PT / 2:00 PM ET

This webinar will help attendees understand the overall concept of SDN and its benefits, describe the different conceptual approaches to SDN, and examine the various technologies, both proprietary and open source, that are emerging. It will also help users decide whether SDN makes sense in their environment, and outline the first steps IT can take for testing SDN technologies.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up

See more from this blogger

Searching for an SDN Definition: What Is Software-Defined Networking?

This week at Interop, the term software-defined networking (SDN) was used in such varying contexts that I wondered if it was going to go the route of terms like cloud, NAC, APT and any other catchy phrase that smells of hype. Why? Once a term is used to mean anything, it means nothing. Many of the clouderati complain that cloud presentations start with a cloud definition. They're sick of hearing it, but the need to constantly define cloud means it has lost any relevant meaning.

Case in point: I had the opportunity to talk with Allwyn Sequeira, VMware's CTO of security and VP of security and network solutions, about what the company is doing in networking. It's neat stuff and I'll write more later, but toward the end he said VMware's virtual networking is a software-defined network--to which I said it wasn't. The dynamics of networking in virtualized scenarios are interesting and require unique products and features to support app and VM mobility, hybrid scenarios and the like. Someone (I don't remember who) said on Monday's SDN workshop that if the networking vendors don't solve virtual networking problems, VMware will. For better or worse, VMware is working the problem and apparently trying to co-opt the term SDN along the way (or maybe signaling future plans).

More Insights

Webcasts

More >>

White Papers

More >>

Reports

More >>

When I think about what makes an SDN unique from networking or virtual networking, it hinges on the word defined. Sure, Cisco's IOS or Juniper's JunOS are software systems that implement algorithms and routing protocols to define the paths through the network, but is that enough to satisfy the requirements of software-defined networking? If you think yes, they why do we have the term SDN (which I don't think was created by marketers)? If we have a new term, it ought to indicate something new, right? If you think not, then we have to define what makes SDN different from what networking does today.

The Open Networking Foundation (ONF)--the organization shepherding the OpenFlow specification through to standards--is at the forefront of SDN. Its SDN definition, published in "Software-Defined Networking: The New Norm for Networks," focuses on three key features:

  • Separation of the control plane from the data plane
  • A centralized controller and view of the network
  • Programmability of the network by external applications

The report says, "Software defined networking (SDN) is an emerging network architecture where network control is decoupled from forwarding and is directly programmable. Network intelligence is (logically) centralized in software-based SDN controllers, which maintain a global view of the network."

The Open Networking Summit's graphic to the left illustrates the separation argument very well. On the left, individual devices form a map of the network in cooperation with their neighbors, and then populate their forwarding engines with paths through the network. It's how networks have worked, and they work well. On the right, an SDN separates the control plane--the purple rectangles on top--from the forwarding devices on the bottom.

The centralized view and the separation of the control plane and the data plane means that the SDN controller can create a physical topology--I'm not using the term L2 topology on purpose, since that implies more than the physical topology--of how nodes are connected and, based on some combination of algorithms, create paths through the network. Finally, the paths are programmed into the devices' forwarding engines. That allows the SDN controller to better manage traffic flows across the entire network and react to changes quicker and more intelligently. How well the controller defines those paths is, of course, critical to the operation of an SDN.

That brings us to programmability. SDN abstracts the network much like an OS abstracts the applications from that hardware. The ONF white paper above has this graphic depicting the abstractions:

Why would you want to program the network? Think about the ways that we perform tasks today, like enforcing quality of service. If we have two apps--a file transfer that needs capacity and an interactive app like VoIP that needs low, consistent latency--we use QoS marking to tell the network to treat the packets differently and, when congestion occurs, which ones to queue up and drop first. It works OK, but when the network is congested, performance suffers.

If you have multiple paths through the network, wouldn't it be useful to be able to, in real time, move that file traffic to a path that has capacity but perhaps has more hops? Doing so would open more capacity for the latency-dependent traffic and, in the end, both applications get better performance.

Consider a security context where you want to ensure that a set of users can only access a set of resources. You can do it with firewalls, access control lists and user identity, but that integration works only with a subset of pre-integrated products. With an SDN, you could enforce access control in your network. Naturally, you need a common protocol to do that, and OpenFlow is one example, but it is not the only way to implement an SDN.

It's important to remember these distinctions between an SDN and virtual networking because network overlays such as VXLAN or NVGRE have distinct advantages, such as hiding layers of addressing between the physical and virtual network, providing better mobility for entire groups of servers and services to different locations regardless of the underlying L2 network, and creating adjacency of virtual hosts in the virtual network, regardless of their physical location. Doing networking in software doesn't make it a software-defined network.

VMware's virtual network is a software virtual network. VMware's virtual networking doesn't have the other hallmarks of SDN, such as separation of the control plane from the data plane, which are still combined in the virtual and physical switches. It also doesn't have the programmability of forwarding paths, such as the ability to directly determine the path a flow will take in the network. It's companies like Big Switch, Contextream, Embrane, NEC and Nicira that are bringing those features to the market.

I'm using VMware as an example, but there are and will be other vendors, particularly in networking, that will try to co-opt SDN to mean everything from simple overlays to API/SDK-enabled configuration control, which does not define the network but simplifies hardware management.

Mike Fratto is editor of Network Computing. You can email him, follow him on Twitter, or join the Network Computing group on LinkedIN. He's not as grumpy as he seems.


Related Reading


Network Computing encourages readers to engage in spirited, healthy debate, including taking us to task. However, Network Computing moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. Network Computing further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | Please read our commenting policy.
 
Vendor Comparisons
Network Computing’s Vendor Comparisons provide extensive details on products and services, including downloadable feature matrices. Our categories include:

Research and Reports

Network Computing: April 2013



TechWeb Careers