Time for a New Network Engine: Start Running on a Software-Defined Network

Time for a New Network Engine: Start Running on a Software-Defined Network

I grew up on a wheat farm in the 70s. I spent much of my teens and early 20s working on farm machinery, before starting my career in software and computer technology. I learned distributor caps, points, carburetors, plugs, etc. to be able to tune up an engine to get it run well. I still have a timing light and dwell meter to be able to work on my old Studebaker. However, I don’t work on my modern vehicles—I have a trustworthy mechanic with the tools to interact with the onboard computer systems.

Engines have progressed a long way since the 70s. I had a 1979 Hurst/Olds Cutlass, one of the top factory muscle cars of the late 70s. Engine was rated at 170 HP and got 12 MPG on a good day. A 2014 Mustang GT500 has 662 HP and gets 24 MPG, or almost four times the HP and twice the mileage.  Aerodynamics has some effect, but the big difference is engine technology (plus modern transmissions, but bear with my analogy for a few more paragraphs).

OEM (original equipment manufacturer) and aftermarket parts companies proposed many components to try to improve the good old 70s V8 engines. Distributors and points were replaced by electronic ignition systems, providing more accurate spark and reduced component deterioration. Carburetors were replaced by throttle body fuel injectors that eliminated the bowls and floats and provided better fuel delivery. These components helped but weren’t capable of delivering orders of magnitude improvement required to deliver horsepower to a mileage conscious consumer (or government agencies).

Modern engines are a marvel of computer technology. The fundamentals of the internal combustion engine haven’t changed: compress a mixture of air and fuel, introduce a spark, convert the explosion to mechanical energy, exhaust the spent fuel, and repeat. Now, computers do a better job of tuning the engine than I could ever dream of and tuning is performed constantly, adjusting the engine for atmospherics, load, fuel quality, terrain, driver style, etc. to maximize efficiency.

The networking industry is at a similar place today as engine designers were in the 80s. We’re trying to modernize the 90s network technology by adding Software-Defined Network (SDN) controllers. As requirements for network services evolved, network manufacturers created protocols (some open, some proprietary) to deliver the services. The result is a stack of network protocols that present a very complex management challenge.

I read a book in my teens (Danny Dunn and the Homework Machine, Abrashkin and Williams, 1958) about a student who programmed a NASA computer to do his math homework. The student’s math teacher found out about the program. The student assumed he was going to fail the class because he didn’t do his own homework. However, the teacher said the student had to understand more about how to solve the math problems to program the computer than was required to do the problems. This story has stuck with me for 40+ years because of the underlying truth: You have to understand a problem very well to be able to automate a solution.

I don’t claim to be a network admin, but I know several. They tell me managing the full network stack is as much art as it is science. Put a half-dozen network experts around a table with an endless supply of beer, and the beer will run out before they come to a consensus on how to best architect and operate a complex network. If they can’t agree how to manage a network, how can there be an agreement on the best way to automate it?

If auto manufacturers had tried to computerize a carburetor and dynamically adjust timing by putting a step motor on the distributer, we’d still be driving sub-200 HP performance cars with poor reliability and complex service requirements. To significantly improve the network, we need to start by simplifying the network. This doesn’t mean that we need an entirely new network paradigm. Engine designers maintained the core hardware design with pistons, valves, cam- and crank-shafts (though some people did play with a rotary engine concept). The basic network is fine—cabling, switches, Ethernet, TCP/IP, etc. However, the delivery of upper level services needs to be greatly simplified to achieve the promise of a significantly improved network.

But what’s meant by “improved network”? Engine designers were driven to improve the engine efficiency to get more power from a unit of fuel. But I’m sure there were other secondary goals, such as improved reliability that allowed vehicle manufacturers to offer much longer product warrantees. So what are the goals of an improved network?

  • Security:

    Data security is top of mind (and front of newspapers) today. Complexity is an antagonist of safety. Complex environments provide too many attack surfaces and make it very easy for well-intentioned maintenance to accidentally open a back door to your data.

  • Flexibility:

    Complex environments are hard to change. It used to be that provisioning a server took weeks and configuring the network took minutes. With virtualization, a server can be provisioned in minutes, but a VLAN takes weeks to create (safely).

  • Resiliency:

    In the 7×24 connected world, taking minutes to hours to recover from a network component failure isn’t acceptable.

  • Manageability:

    This is somewhat a self-fulfilling statement. Less complex environments are simpler to understand and simpler to manage effectively.

Avaya’s SDN Fx™ Architecture, based on SPB or Shortest Path Bridging (802.1aq), provides an alternative to the traditional network protocol stack for L2/L3 unicast and multicast network services. SPB has several attributes that make it a much better engine to drive the requirements of modern networks.

  • Provisioned at the edge:

    Network services are defined on the access switches, turning the core of network into a vehicle for date transfer, which is never touched. (See point No. 3 in Top 10 things you need to know about Avaya Fabric Connect.)

  • Hyper-segmentation:

    SPB supports 16 million virtual networks, so every service can have its own virtual network segment, a key to providing network level data security. (For more information, see Avaya Chief Technologist of SDA Jean Turgeon’s three-part blog on network segmentation. Read about hyper-segmentation, native stealth and elasticity.)

  • Very fast re-convergence:

    SPB identifies all possible paths through the network and selects the best path. If a path disappears, the next best path is already determined and chosen in a couple of hundred milliseconds or less. (See point No. 7 in Top 10 things you need to know about Avaya Fabric Connect.)

  • Internet of Things (IoT) support:

    SPB works equally well connecting racks of virtualized compute infrastructure as connecting Wireless Access Points (WAPs), CCTV cameras, sensors, controls, phones, etc. See the blog Security and the IoT: Where to Start, How to Solve for more information.

One benefit that engine designers had that network engineers don’t have is the new model year. Consumers don’t expect to take their old car into the dealer and get an engine upgrade. They take their car in to get an entirely new car. Network engineers are expected to upgrade the network by replacing parts, usually while the network is still running. Avaya’s Fabric Extend allows SPB to be deployed by simply replacing the edge switches and utilizing your existing core network. Spanning the core of the network doesn’t provide all of the benefits of a full fabric deployment, but does provide a means to execute a rolling fabric conversion, kind-of-like upgrading the carburetor while the car is running.