Network infrastructure design requires separating forest from trees

It is when network architects step away from the details governing network protocols that operating models will evolve, argues Keith Townsend.

Is conventional network infrastructure design nothing more than a "bag of protocols"? That's what University of California, Berkeley, Prof. Scott Shenker seems to be saying. Shenker, a network expert, co-founder of Nicira and a leading proponent of software-defined networking (SDN), argues that unlike almost every other discipline in computer science, networking and network scaling have remained tightly woven to its underlying protocols and standards opposed to embracing abstraction.

His statements notwithstanding, I believe it's important to identify exactly where in the large discipline of networking Shenker is specifically referring. After all, we already see abstraction as it applies to the relationship of machine-to-machine communication. The Open Systems Interconnection model is an abstraction of its own. Application developers, for example, do not need to recreate the functions of TCP for flow control or IP for machine-to-machine communication each time they write a chat application. Indeed, they can rely on the abstracted concepts the protocol stack provides.

Why introduce abstraction to these levels of networking?

Instead, I believe Shenker's argument centers on how data flows from one network to another network, and the underlying dependency on the physical network. And I constantly hear questions asking why there is any further need to introduce abstraction to these levels of networking.

We've been so far down in the weeds of the technology we've lost sight of the forest for the trees.

If you look at networking's core protocols themselves, there is a lot of science behind the creation and improvement of the technology. The Border Gateway Protocol (BGP), for example, has been the foundation that keeps networks interconnected on the Internet. It's been extant almost as long as there have been routers, and it has proved to be a scalable solution. What's more, the industry has consistently discovered ways to bypass scaling limitations the protocol itself imposes. Case in point: When the routing table was becoming too large to reasonably be stored in a router's memory, the industry leveraged route summarization to help solve the route table overhead issue. So, what's Shenker's point? If the industry consistently solves the technical hurdles it confronts, then why change for the sake of changing?

I think it's important to state the actual problem abstraction is trying to solve. And that problem is, "I don't know." Which is literally the problem. We've been so far down in the weeds of the technology we've lost sight of the forest for the trees. This post provides a great non-tech view of using abstraction to solve problems. In a nutshell, abstraction allows us to better use our critical thinking skills to look at a problem from a much higher level without getting caught up in the details. Solving the problem of a routing table's sizes is staying in the trees. Full SDN looks to eliminate routing limitations as an issue while in theory providing a framework for a more capable network.

Is SDN the ultimate solution?

So does this mean that SDN is the solution to the lack of abstraction in networking? No. Just like route summarization, SDN is a solution to a specific problem within networking but a solution that uses an abstraction methodology. The network control plane is just one specific area of abstraction that's being tackled by using SDN. Yet there's the device level to consider as well. We no longer associate, in a one-to-one relationship, Windows and Linux server workloads to physical pieces of hardware. Today, a "Web server" is no longer a physical thing; it's a concept. By taking these once-physical constructs and "virtualizing," or better yet abstracting them, we are able to improve operations and create new service models, such as Infrastructure-as-a-Service-based private or public clouds.

Virtual appliances are an extension of this capability. Virtual appliances can run on a public cloud infrastructure as well as they could on a white box in a rack in your data center because of their abstraction from the physical hardware. To that end, installing an entire content management system can be as simple as downloading an appliance and importing it into your cloud manager's virtualization cluster.

It is when we are able to step away from the details and minutiae that comprise network protocols -- and consistently create abstractions to these complex systems -- that we will create new products and operating models. We just can't see them at this point because we are so consumed with our protocols.

This was first published in August 2013

Dig deeper on Network Design

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

1 comment

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchSDN

SearchEnterpriseWAN

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close