Category Archives: Software Defined Network

To the land of plenty.. Moving towards high-performance cluster management

blogging1

“Jevons Paradox” is the proposition that as technology progresses (invention->innovation->diffusion), the increase in efficiency with which a resource is used tends to increase the rate of consumption of that resource.

As much as cloud operators continue to increase the population of hardware assets, it has become an increasingly difficult problem to efficiently utilize those resources effectively as demand grows. This has huge implications in the longevity of these multi-million dollar cloud warehouses highlighting the need to make better decisions on resource allocation and assignment.

Into the light..

Some promising work comes from Christine Delimitrou described in her paper “Quasar: Resource-Efficient and QoS-Aware Cluster Management

Quasar is a follow-up to the work on Paragon, a system to leverage collaborative filtering to characterize (classify) applications in terms of heterogeneity and potential for interference. Quasar establishes a set of interfaces which expand upon Paragons’ classifier.  These interfaces allow for choices to be made in scaling such as the amount of resources per server or the amount of servers per workload. Both Paragon and Quasar use offline sampling (profiling) instead of relying on some explicit characteristics but Quasar goes further in applying jointly handling resource allocation and assignment. Quasar is part of a broader set of cluster management platforms such as Omega, Borg, Mesos, which are being used in production in some of the largest web properties on the Internet.

Quasar exports a high level interfere to meet different performance constraints such as:

  • Latency critical workloads use a combination of QPS (Queries Per Second) and latency
  • Distributed frameworks use execution time
  • Single and Multi-threaded applications can use IPS (Instructions Per Second)

This work has a lot of promise given the increasing demand for efficient allocation of infrastructure resources. There continues to be an iterative cycle between application developers and infrastructure teams to mitigate the risk of failure while increasing utilization. But how does one decide which variables and how many must be used to decide on which resources to assign?

Large shops like Facebook,Twitter and Google have been experimenting with cluster scheduling for years. Systems like Omega grew out of the complexity of managing flexible scheduling with ever increasing linear complexity spawned from their explosive growth. As reported in the Quasar paper, sophisticated frameworks like Borg and Mesos have a hard time driving more than 20% aggregate CPU utilization and can under estimate resource reservations by 5x and over estimate reservations by as much as 10x. Its important to note that these numbers are at the high-end with a majority of cloud data centers and enterprise customers experiencing only a fraction of the available capacity they have invested in.

As can be seen by the following graphic, Not only are jobs completing faster with the Quasar scheduler but CPU utilization is increasingly higher which could increase the usefulness of a data center by several years having dramatic cost savings for the large web-scale data centers.

blogging2

It is no secret in todays “application centric economy” that huge benefits can be obtained through application/infrastructure cooperation. Chip designs have followed the path of adding transistors to deal with complex problems such as matrix multiplication, stream processing, virtualization and high-speed I/O. infrastructure vendors have started to focus on the shifting operational models which have manifested in areas such as cloud computing, DevOps, Network Virtualization and Software Defined Networking.

The allocation and assignment of resources becomes a critical decision point which must be reacted to not in human scale but in machine scale.. The dominant force here centers around “Reactive Design” and the need for operational stability.

But who is responsible for coordinating resources, resolving shared resource conflicts in a highly dynamic environment?

Send in the Conductor.. blogging3

Orchestration describes the automated arrangement, coordination, and management of complex computer systems, middleware, and services that are used to align business or operational request with applications, data and infrastructure within a management domain [ref].

Orchestration can be broken into roughly 9 categories including: Allocation, Assignment, Scheduling, Visualization, Monitoring, Modeling,  Discovery, Packaging and Deployment.

These become fundamental building blocks for building distributed systems and allows us to talk about these functions with a clear set of vocabulary.

Allocation: Determining the appropriate resources to satisfy the performance objective at the lowest cost

Assignment: The process of selecting the appropriate resources which satisfy the resource allocation

Scheduling: Enables an allocated resource to be configured automatically for application use, manages the resource(s) for the duration of the task to secure compliance and restores the resource to its original state for future use

Visualization: The process of rendering information related to service availability, performance and security

Monitoring: Provides visibility into the state of resources and notifies applications and infrastructure management serves of changes in state

Discovery: The realization of a resource or service through observation, active probing or enrollment

Modeling: Describes available resources and their capabilities, dependencies, behaviors and relationships as a policy. Can also be used to describe composition of resources and services (i.e. happens-before relationships)

Packaging: The process of collecting all artifacts and dependancies into a portable container which can be transferred across resources. This packaging might also encapsulate existing state for instance in live migrations.

Deployment: Code and data need to be instantiated into a system in order for the scheduler to reserve resources. Delivering the packages mentioned above across resources requires coordination as to not overwhelm the network during updates.

When driving for high-performance for customers and high-efficiency for operators resource allocation and assignment become critical decision processes in the orchestration system. Quasar provides an interface which can directly relate to emerging Promise Theory allowing developers to declare scalability policies which express performance constraints allowing Quasar to search through the available option space to best fit the constraints with the available resources..

But what about the network?

“Your network is in my way..”

blogging4

Everyone in the network industry is aware of James Hamilton’s observation that network technologies have long become inefficient and overly complex. SDN has driven this conversation to the forefront challenging foundational principals of the Internet such as decentralization and the end-to-end principal. The current protocol stack has a number of problems known as far back as the initial ARPAnet designs over 40 yrs ago. The Internet has become more  complex due to the distributed nature of application design and the need for location independance.

When it comes to network interference we have different opportunities to optimize for resource constraints including:

  • Path selection – Optimized to minimize distance (propagation delay)
  • Congestion and Flow Control – Optimized to maximize bandwidth
  • Error Control – Optimized to minimize loss
  • Scheduling – Optimized to maximize queue fairness amongst competing flows

This would seem to be plenty to deal with network interference except for the problem that not all flows are necessarily equal. For instance a trading application might need market data to take priority over backup replication. VOIP traffic needs to be prioritized over streaming downloads.

Unfortunately as much as we would like to have a way to map priorities across the network, the current environment makes it difficult to achieve in practice. This usually falls within the purview of Traffic Engineering and incorporates different methods for describing, distributing and acting upon flow policies either for admission control or filtering.

In a recent GIGAOM survey operators categorized Network Optimization as the leading use-case for SDN, NFV and OpenSource which might be another way of saying that we need a facility to characterize inter-process communication in a way which can be fed back into our orchestration systems to make proper resource allocation and assignment decisions.

blogging5

As the industry moves through technological change (S-Curve), a rapid innovation cycle will result in many failures until we reach the point of wide adoption (diffusion). Many have speculated on the timelines but it is still far from proven how well customers will adopt not only the change that comes from technology but also the change in organizational structure, skill sets and policy.

Stack Wars and the Rise of the SDN Republic

Recently there is much insanity formed around the “SDN disruption” and the new “Stack Wars” its time to sit back and look what is going on.

The “Stack Wars” are in full swing ensnaring AMZN, VMW, MSFT, and  GOOG. With the recent aquisition of Nicira by VMWare the “Platform Wars” have exploded into an all out fight for the entire stack.  VMWare continues its dominance according to one survey suggesting a 24% lead over the next largest competitor OpenStack.  But VMWare  has yet to differentiate beyond the enterprise.

VMWare recently fired another shot from their Death Star publishing a new open source tool chain for release engineering, deployment and lifecycle management of large scale distributed services. Cloud Foundry BOSH opens up the world of poly-cloud services. According to  Steve Herrod latest post:

Cloud Foundry’s goal is to be the “Linux of the cloud.” Just as Linux provides a high degree of application portability across different hardware, Cloud Foundry provides a high level of application portability across different clouds and different cloud infrastructure. Steve Herrod, CTO VMware

So what about the EMC created and Maritz lead Project Zephyr, Both Tucci and Maritz are  tuned into the expanding market for insfrastructure and platform services expected to grow a combined $26.5B by 2016 , they must start to build a reputation outside of the Enterprise and go after the same Consumer IT market Amazon has been so successful in capturing.

OpenStack and Cloud.com have yet to prove their scalability and operational robustness under fire (although RACK is desperate to make Essex a success). Others are following suit recently RedHat finally pledged to the OpenStack initiative but there are still major issues in governance and fragile source based which I feel still make it a questionable platform to build your business on.

We must not forget about the >1M server Google and the massively scalable Amazon  coming downstream from Consumer IT  into the Enterprise (AMZN certainly has been going after the enterprise but not as a unification of public/private resource pools). If Larry Page and Jeff Bezos wise up they will start to offer their orchestration and management tools to use within enterprises and expand into poly-cloud control. This can benefit their bottom line  with a simple agreement of guaranteed public cloud usage which can easily be justified based on todays cloud sprawl. Having seamless access to secured and QOS aware Enterprise along with the scalability and platform richness of public clouds will shift the power to one of these heavyweights who might complete the “Death Star” and capture the “Linux of the Cloud” trophy.

SDN Disruption

In our core domain, there is a significant amount of confusion about what problems need to be solved and where. For instance having a rich set of API’s to manage infrastructure is simply a matter of economies of scale. Without lowering the average cost per unit (in terms of operations, robustness, flexibility, etc..) by means of automation, you are simply carrying an anchor around all day slowing your business. But is this SDN?

VMWare has moved into the world of SDN through the acquisition of Nicira.  VMware has been successful at virtualizing compute, storage and now networking. This can be considered the trifecta necessary to capture the ” control points” enabling them to be first in developing a unified Abstract Binary Interface to all infrastructure components. Those of you familiar with the Linux Standard Base or Single Unix Specification would recognize why this is extremely valuable in building the cloud operating system.

Each of their control points provide added value to build upon for instance the VM association to location, policy, metrics, QOS guarantees, etc.. These are incredibly valuable as is the network binding (mac->port->IP). With this information the owner can control any resource anywhere regardless of the network, operating system or the hypervisor..

Value of the Physical Network

So what about the role of the physical network.. We have heard many leaders discuss this in the context of commoditized switches, merchant silicon and proprietary fabrics.

There are significant challenges in optimizing networks especially data centers which require a mixed set of services and tenants such as  Unified Multi-Service Data Centers. There is a need for efficient topologies which maximize bi-sectional bandwidth, reduce the overhead in cabling and reduce operational complexity. The network fabric should work as well for benign traffic as it does for permutation traffic (i.e. many-to-one scenarios familiar to partition aggregate application patterns).

If I can’t utilize the full capacity of the network and be assured that I have properly scheduled workloads during permutation traffic interactions than certainly the physical network becomes an increasingly important design point. This requires changes to topology, flow control, routing and possibly the protocol architecture in order to arbitrate amongst the competing flows while maintaining low variance in delay and robustness to failures.

Realistically, the shift to 10GE network fabrics and host ports provide better scalability and to date application designers have yet to fully exploit distributed processing which means the data center traffic matrix is still fairly sparse.

As we move into the future, and workloads become more dense, one could argue that the physical network has a lot more it can accomplish. For instance ALL Fat-Tree architectures limit the available capacity of the network to the min-cut bi-sectional bandwidth. This means that overall throughput is limited to 50% of total capacity (Note: that is an ideal throughput because routing and flow control limit capacity further). The question for data center designers is will you pay for a network which they can only utilize a subset of 50% of the capacity they purchased? Well I certainly would be looking for options that would improve my cost model and this is an area which we haven’t yet found the secret sauce..

The reality is the way we architect networks today are far more efficient and offer more capacity than ever before. Load dependant bottlenecks show up way before you can exhaust the resources of the network which basically support the argument of network virtualization to reduce the amount of churn (i.e. state management) in the physical network allowing it to be more robust and reliable and predictable.

SDN to the Rescue?

The main problem today is the exhaustive manual effort in configuring all of the dependancies, dials, protocols and having to think about how things physically lay down together from the wiring to the VLAN associations, security policies etc.. This has become too cumbersome and impossible to reason about which is why overlays look so attractive. You no longer can codify or teach the network on a whiteboard, even representing all the different configuration noise on Visio’s are extremely complex and you still can’t reason holistically about network continuity, security and access control.

Reasoning about the network and applying formal verification testing before changes will allow networks to be much more predictable with much less complexity and failures. Todays switches and routers which require knowledge of complex data structures, different algorithmic complexities and interrelated dependancies cause a chain reaction of combinatorial issues. Between the link-layer and inter-domain routing there are many interactions which can go haywire and current techniques like static-analysis don’t cover the quadratic state explosion problem which exists in todays infrastructure software.

As far as SDN, its only a matter of time before the TCAM manufactures catch up to the requirements being forged in the ONF. Nick McKeown made a point in his SIGCOMM 2012 keynote that in a few short years we will power efficient TCAM’s with 100s of thousands of entries and multiple table support. Given that this is the primary bottleneck to complete the SDN ABI we will most likely see SDN become a very strong alternative to todays mix bag of control plane protocols. To be honest, rightly so.. This is not necessarily our fault but an artifact of the flawed protocol model developed at a  time where getting a character across the screen on a terminal was considered a huge step forward. This is most certainly not the world we live in anymore and unfortunately the specializations which have been built up to deal with this model are quickly being challenged..

Network Mechanics to Network Conductors

I get a general sense that the latest incarnation of network evolution (i.e. SDN) is becoming a way of expressing the frustration with dealing with a complex set of problems, which have yet to be solved. One of the things you have to ask yourself, as a network professional is “What do I really understand about the fundamentals of networking and how do I put that to use in the post-PC data hungry world?”

For years the best way to understand networking was to lug out your Network General Sniffer and watch the interaction of messages flowing across the screen. We had basic signals such as connection management; we had a general understanding of the traffic matrix by interrogating the network addresses, which we compared to our spreadsheets and some heuristics about flows. We leveraged the emerging SNMP standard to first collect traffic statistics into our pre-RRD datastores and presented pretty graphs of utilization to understand demand. Soon we had some expert systems, which would track the various protocol state transpiring between hosts and interpreting the results.

Scaling the data center meant learning about aggregation/distribution, the ratio of local traffic from remote. At the time most network engineers were taught the 80/20 rule i.e. 80% of the traffic stays local and only 20% is remote. This was a direct play on our centralized compute models, mainframes and the fact that most people were still using terminal based computing and sneakernet. It became the foundation of network design, which reflected this by oversubscribing capacity higher in the tree (i.e. Core, Distribution, Edge design).

Network automation was still in its infancy; you would use a floppy disk to update the firmware and operating system. Upgrading a Cisco router meant getting your terminal configured with the appropriate Xmodem/Zmodem settings and waiting hours while your data was serialized down a modem from the Cisco CCO BBS site.

Soon we were leveraging scripting languages like Expect and Perl to handle the complexity of managing network state across all the configuration files. Once you could use the SNMP private MIB to read and write a device configuration you could make global changes in an instant and repopulate the configurations across the world. In some ways this was all a step backwards from the advancing telecommunications control system present in the day, it was still a very closed and proprietary world leaving customers no choice but to adopt some complex and monolithic management applications.

So its 2012 and we are not much better at dealing with all of the challenges in running such a complex system as the network. IETF finally got its act together and delivered a more robust management framework through an application protocol called NetConf and an information modeling definition called YANG. Finally you can divorce the information model from the data transfer protocol and allow for a cleaner representation of the network configuration. But is this as far as we need to go? Why is SDN so interesting and what is it telling us about the still very complex problems with building, and operating networks?

As the title of the blog suggests, I think something can be said for the expertise required to manage complex systems. Question becomes, are you going to stay being a mechanic and worrying about some low-level details or are you going to be the pilot? Is it valuable to your employer for you to understand the low-level semantics of a specific implementation or rise above by creating proper interfaces to manipulate the state of the network through a reusable interface?

With information becoming more valuable than most commodities it will take a shift in mindset to move from low-level addressing concerns to traffic analysis, modeling and control. Understanding where the most important data is, how to connect to it and avoid interference will become much more important than understanding protocols.

So how does SDN contribute to this and how do we get from the complex set of tasks of setting up and operating networks to more of a fly-by-wire approach? How do we go from managing a huge set of dials and instruments to managing resources like a symphony?

The first thing to recognize is you can’t solve this problem in the network by itself!!. For years application developer’s expectations of the network were of infinite capacity and zero latency. They perceived that the flow-control capability in the network would suffice giving them ample room to pummel the network with data. Locality was far behind even an after-thought because they were developing on local machines unaware of the impact of crossing network boundaries. Networking guys use terms like latency, jitter, bandwidth, over-subscription, congestion, broadcast storms, flooding while application developer’s talk in terms of consistency, user experience, accuracy and availability.

The second thing to recognize is the network might need to be stripped down and built back up from scratch in order to further deal with its scaling challenges. In my eyes this is the clearest benefit to SDN as it highlights some of the major challenges in building and running networks. Experimenting with a complex system is disastrous; in order to break new ground it must be decomposed into its simplest form but certainly no simpler as Einstein would say. Its possible that OpenFlow has gone this route and must be redesigned into a workable set of primitive functions which can be leveraged not just through a centralized controller model but also to adapt new Operating Systems and protocols to leverage the hardware.

There is much debate over what the “best” model is here and what the objectives are. Since most networking is basically a “craft” and not a science there are those who strive to maintain the existing methodologies and mechanisms and simply open up a generalized interface to improve control. Others might see this as a mistake as if you reproduce the current broken layering model you are bound to run into a new set of challenges down the line which may require another patch, protocol or fix to solve.

Maybe an approach of looking back at the fundamentals of networking, what has been learned through the course of history, how other protocols behave and a reflective look at our industry would be valuable. How do you deal properly with connection management, data transfer efficiency, flow control? How do you leverage proper encapsulations and hierarchy to scale efficiently? What should management look like and how do you separate mechanism from policy and deliver hop-by-hop QOS?

Summary

In some regards the move towards Software Defined Network is an outcry of the frustration in managing an ever, complex set of interrelated components. Data centers have become huge information factories; servers themselves have become cluster of computers and our data hungry applications require massive amounts of parallel computing driving even more demand into the network. We could continue to take a ill-suited feature-driven approach to networking or we could take the opportunity to recognize what are the architectural principals to networking which would turn it from a craft to a science (not withstanding the argument on true science).

Networking Guy’s, Just don’t understand software

Before I begin my rant, let me just say my first router was a WellFleet CN with a VME Bus and my first Cisco router was an AGS+.. I have been around long enough to see DecNet, IPX, IP, SNA, Vines and a few others running across my enterprise network while troubleshooting 8228 MAU’s beaconing in the wiring closets and watching NETBEUI “Name in Conflict” packets take down a 10’000 node RSRB network.

Its 2012 and gone are the days when network engineers need to juggle multiple protocol behaviors such as IPX GetNearestServer, IP PMTU bugs in Windows NT 3.5.. or trying to find enough room in your UMB to fit all your network ODI drivers without crashing Windows.

Its a new age, and as we look back at almost 40 years since the inception of the Internet and almost 20 years since TCP/IP was created, we are at the inflection point of unprecedented change fueled by the need to share data, anytime, anywhere on any device.

The motivation for my writing this entry comes from some very interesting points of view from my distinguished ex-colleague Brad Hedlund entitled “Dodging Open Protocols with open software“. In his post he tries to dissect both the intentions and impact of a new breed of networking players such as Nicira on the world of standardized protocols.

The point here isn’t to blow a standards dodger whistle, but rather to observe that, perhaps, a significant shift is underway when it comes to the relevance and role of “protocols” in building next generation virtual data center networks.  Yes, we will always need protocols to define the underlying link level and data path properties of the physical network — and those haven’t changed much and are pretty well understood today.

The “shift in relevance and role of protocols”  is attributed not necessarily at what we know as the IETF/IEEE based networking stack and all the wonderful protocols which make up our communications framework, but in a new breed of protocols necessary to support SDN.

Sidebar: Lets just go back a second and clarify the definition of SDN. Some define Software Defined Networking in terms of control plane, data plane separation, which clearly has been influenced by the work on OpenFlow.

So the shift that we see in networking which is towards more programmability and the fact that we need new ways to invoke actions and carry state is at the crux of this shift..

However, with the possibility of open source software facilitating the data path not only in hypervisor virtual switches, but many other network devices, what then will be the role of the “protocol”? And what role will a standards body have in such case when the pace of software development far exceeds that of protocol standardization.”

Ok so this is the heart of it.. “what then will be the role of the “protocol”? And what role will a standards body have in such case when the pace of software development far exceeds that of protocol standardization.”

I think the problem here is not necessarily the semantics of the word “protocol” (for this is just a contract which two parties agree upon), but the fact that there is a loosely defined role in how this “contract” will be standardized to promote an open networking ecosystem.

Generally standardization only comes when there is sufficiently understood and tested software which provide the specific implementation of that standard. Its very hard to get a protocol specification completely right without testing it in some way..

Sidebar: If you actually go back in history you will find that TCP/IP was not a standard.. The INWG was the governing standards body of the day in defining the international standard which was supposed to be INWG 96 but because the team at Berkley got TCP up into BSD Unix, well now its history..I wrote a bit about it here: http://garyberger.net/?p=295.

With that in mind, take a closer look at the Open vSwitch documentation, dig deep, and what you’ll find is that there are other means of controlling the configuration of the Open vSwitch, other than the OpenFlow protocol.

When it comes to OVS its very important not to confuse interface and implementation. Since OVS in a classical form just a switch, you operate it through helper routines to manipulate the state management layer in the internal datastore called OVSDB and interact with the OS. This is no different than say a CLI on a Cisco router. Most of the manipulation in the management plane will probably be exposed through JSON-RPC (Guessing here) through a high-level REST interface.

What you must understand about OVS when related to control plane/data plane separation or  “flow-based network control” is you are essentially changing the behavior from a standardized switch based on local state to a distributed forwarding engine coordinated with global state.

From OVS:

The Open vSwitch kernel module allows flexible userspace control over flow-level packet processing on selected network devices. It can be used to implement a plain Ethernet switch, network device bonding, VLAN processing, network access control, flow-based network control, and so on.

Clearly since we are in the realm of control plane/data-plane separation we need to have a protocol (i.e. contract) which is agreed upon when communicating intent. This is where OpenFlow comes in..

Now unfortunately OpenFlow is still a very nascent technology and is continuing to evolve but Nicira wants to solve a problem. They want to abstract the physical network address structure in the same way that we abstract the memory address space with VMM’s (see Networking doesn’t need VMWARE but it does need better abstractions). In order to do this they needed to jump ahead of the standards bodies (in this case the ONF) and adopt some workable solutions.

For instance, OVS is not 100% compliant with OpenFlow 1.0 but has contributed to better models which will appear soon in the 1.2 specification. OVS uses an augmented PACKET_IN format and matching rules


/* NXT_PACKET_IN (analogous to OFPT_PACKET_IN).
*
* The NXT_PACKET_IN format is intended to model the OpenFlow-1.2 PACKET_IN
* with some minor tweaks. Most notably NXT_PACKET_IN includes the cookie of
* the rule which triggered the NXT_PACKET_IN message, and the match fields are
* in NXM format.

Summary:

Open Source networking is nothing new, you have XORP, Zebra, Quagga, OpenSourceRouting.org, Vyatta and standard bridging services built into Linux.

Just like with TCP/IP if there is value in OpenFlow or whatever its derivatives are we will see some form of standardization. OVS is licensed under Apache 2, so if you want to fork it go ahead thats the beauty of software. In the mean time I wouldn’t worry so much about these control protocols, they will change over time no doubt and good software developers will encapsulate the implementations and publish easy to use interfaces.

What I think people should be asking is not so much about the protocols (they all suck in their own way because distributed computing is really, really hard) but what can we do once we have exposed the dataplane in all its bits to solve some very nasty and complex challenges with the Internet?.

Networking doesn’t need VMWARE but it does need better abstractions

Lately there has been a lot of talk around the network and the corresponding conflation of terms and hyperbole around “Network Virtualization including Nypervisor, Software Defined Networking, Network Abstraction Layer, SDN, OpenFlow, etc.

Recently a blog entry entitled “Networking Needs a VMWare (Part 1: Address Virtualization)” appeared on Martin Casado’s blog which tries to make a case for comparing the memory virtualization capability in today’s modern hypervisors to network virtualization.

This sort of left an uneasy feeling in fully describing why we are seeing this activity in the network domain specifically to deal with the broken address architecture. This post is to try and bring some clarity to this and to maybe dig deeper into the root causes or problems in networking which have led us to this point.

The synopsis in the blog goes like:

One of the key strengths of a hypervisor lies in its insertion of a completely new address space below the guest OS’s view of what it believes to be the physical address space. And while there are several possible ways to interpose on network address space to achieve some form of virtualization, encapsulation provides the closest analog to the hierarchical memory virtualization used in compute. It does so by taking advantage of the hierarchy inherent in the physical topology, and allowing both the virtual and physical address spaces to support complete forwarding and addressing models. However, like memory virtualization’s page table, encapsulation requires maintenance of the address mappings (rules to tunnel mappings). The interface for doing so should be open, and a good candidate for that interface is OpenFlow.

The author of the blog post is trying to describe a well-known aphorism by David Wheeler, which states: “All problems in computer science can be solved by another level of indirection”. This statement is at the heart of “virtualization” as well as other references in communications layering, computer architecture and programming models.

Sidebar OSI Model

Lots of networking professionals like to refer to the 7-layer OSI model when talking about network abstractions. The problem is the OSI model was never adopted; in addition most OSI engineers agree that the top 3-layers of the OSI (Application, Presentation and Session) belongs in “one” application layer. We utilize a derivative of that model which is essentially the four-layers representative in the TCP/IP model.

Lets first try and define what an address is and then what is meant by encapsulation being careful not to conflate these two important yet independent terms.

Addressing and Naming

The first thing to recognize is that the Internet is comprised of two name spaces, what we call the Domain Name System and the Internet Address Space. These turn out to be just synonyms for each other in the context of addressing with different scope. Generally we can describe an address space as consisting of a name space with a set of identifiers within a given scope.

An address-space in a modern computer system is location-dependent but hardware-independent thanks to the virtual memory manager and “memory virtualization”. The objective of course is to present a logical address space which is larger than the physical memory space in order to give the illusion to each process that it owns the entire physical address space. This is a very important indirection mechanism, if we didn’t have this, applications would have to share a much smaller set of available memory. Does anyone remember DOS?

“Another problem with TCP/IP is that the real name of an application is not the text form that humans type; it’s an IP address and its well-known port number. As if an application name were a macro for a jump point through a well-known low memory address. – Professor John Day”

Binding a service, which needs to be re-locatable to a location-dependent address, is why we have such problems with mobility today (in fact we may even conclude that we are missing a layer).  Given the size and failure rates of today’s modern data-centers this problem also impacts the reliability of the services and applications consumers are so dependent on in todays web-scale companies.

So while this is a very important part of OS design, its completely different from how the Internet works because the address system we use today has no such indirection without breaking the architecture (i.e. NATS, Load Balancers, etc).

If this is true, is the IP address system currently used on the Internet “location-dependent”?  Well actually IP addresses were distributed as a “location-independent” name, not an address.  There are current attempts to correct this such as LISP, HIP as well as “BeyondIP” solutions such as RINA.

 So it turns out the root of the problem in relation to addressing is that we don’t have the right level of indirection because according to Saltzer and Day, we need a “location-independent” name to identify the application or service but all we have is a location-dependent address which is just a symbolic name!.

What is encapsulation?

Object Oriented Programming refers to encapsulation as a pattern by which [“the object’s data is contained and hidden in the object and access to it restricted to members of that class”]. In networking we use encapsulation to define the different layers of the protocol stack, which, as we know “hides” the data from members not in the Layer, in this way the protocol model forms the “hour-glass” shape minimizing the interface and encapsulating the implementation.

Sidebar Leaky Abstractions

Of course this isn’t completely true as the current protocol model of TCP/IP is subject to a “leaky-abstraction”. For instance there is no reason for the TCP logic to dive into the IP frame to read the TOS data structure, doing so would be a “Layer Violation” but we know that TCP reaches into IP to compute the pseudo header checksum. This rule can be dismissed if we think of TCP/IP as actually one layer as it was before 1978. But the reality of the broken address architecture leads to the “middle boxes” which must violate the layers in order to rewrite the appropriate structures to stitch back together the connection.

So how does encapsulation help?

In networking we use encapsulations all the time..

 We essentially encapsulate the data structures which need to be isolated (the invariants) with some other tag, header, etc. in order to hide the implementation. So in 802.1Q we use the C-TAG to denote a broadcast domain or VLAN, in VXLAN we encapsulate the host within a completely new IP shell in order to “bridge” it across without leaking the protocol primitives necessary for the host stack to process within a hypervisors stack.

From the blog.. “encapsulation provides the closest analog to the hierarchical memory virtualization in compute”

So in the context of a “hierarchy” yes we encapsulate to hide but not for the same reasons we have memory hierarchies (i.e. SRAM(cache) and DRAM). This generalization is where the blog post goes south.

So really what is the root of the problem and how is SDN an approach to solve it?

From an earlier statement we need a “location-independent” name to identify the application or service but all we have is a location-dependent address which is just a symbolic name!. If we go back to Saltzer we see that’s only part of the problem as we need a few more address/names and the binding services to accomplish that.

 One interesting example to this is the implementation of Serval from Mike Freedman at Princeton University. Serval actually breaks the binding between the application/service name and the inter-networking address..(Although there are deeper problems then this since we seem to be missing a network layer somewhere). Serval accomplishes this through the manipulation of forwarding tables via OpenFlow although it can be adapted to use any programmable interface if one exists. Another example is the NDN Project led by Van Jacobson

In summary

Yes it is unfair to conflate “Network Virtualization” with “OS Virtualization” as they deal with a different level of abstraction, state and purpose. Just as hypervisors were invented to “simulate” a hardware platform there is the need to “simulate” or abstract the network in order to build higher-level services and simplify the interface (not necessarily the implementation). In fact a case can be made that “OS Virtualization” may eventually diminish in importance as we find better mechanisms for dealing with isolation and protection of the host stack while network virtualization will extend beyond the existing solutions and even existing protocols allowing us to take on a new set of challenges. This is what makes SDN so important; not the implementation but the interface. Once we have this interface, which is protocol independent, we can start to look at fixing the really hard problems in networking in a large scale way..

NodeFlow: An OpenFlow Controller Node Style

In less you’ve been under a rock lately, you might have heard something about Software Defined Networks, OpenFlow, Network Virtualization and Control Plane/Data Plane separation.

Some of the reasons for the interest might be:

  • Evolution of the system architecture as a whole (Network, NIC, PCIE, QPI, CPU, Memory) along with X86_64 instructions, OS, drivers, software and applications have allowed for many services to run on a single host including network services. Extending the network domain into the host allows for customizable tagging, classification, load balancing and routing, with the utopia being ubiquitous control of logical and physical by a combination if in-protocol state, forwarding tables and a distributed control system.
  • Non-experimental network pathologies, which are causing havoc with large-scale systems. Turns out there are some very “real” problems, which were never part of Ethernet and TCP/IP design space and software allows us to experiment with different ideas on how to solve these problems.
  • Leveraging a possibly untapped design space in order to be differential,  leap frog competition or disrupt the marketplace

So what is OpenFlow? Well according to the Open Networking Foundation:

OpenFlow is an open standard that enables researchers to run experimental protocols in the campus networks we use every day”

This paradigm shift into the guts of the network might be better explained by a surgical assessment of the network core, its protocol structure, the devices, which deal with enrollment, classification, multiplexing/demultiplexing, flow control and routing but this will be a post for another day.

In the meantime the “network” has evolved into a first class citizen amongst infrastructure architects, software developers and consumers alike. No, I am not talking about the Social Network by big boy Zuck, but the fact that networks are finding them selves ingrained in almost anything not nailed down. This so called “Internet of Things” tells us that soon the network will be stitched into our lives through the air and into our clothes.

There are many arguments about the value of OpenFlow and SDN, but to find the benefits and use-cases the network domain experts may find the current toolsets and platforms a bit impenetrable. The current controller implementations are written in a combination of C, Python and Java and because of the “asynchronous” nature of the OF protocol, additional libraries have to be leveraged including Twisted and NIO which make it more difficult to understand exactly what is going on.

To that end I introduce NodeFlow, an OpenFlow controller written in pure JavaScript for Node.JS.  Node.JS provides an asynchronous library over JavaScript for server side programming which is perfect for writing network based applications (ones that don’t require an excessive amount of CPU).

NodeFlow is actually a very simple program and relies heavily on a protocol interpreter called OFLIB-NODE written by Zoltan LaJos Kis. I have a forked version of this library (see below) which have been tested with OpenFlow version 1.0.

Sidebar: A note on OpenFlow

Even though the Open Networking Forum has ratified the 1.2 protocol specification, we have yet to see a reference design which allows developers to experiment. In order to get a grasp of the programming model and data structures to this end I have concentrated on the most common implementation of OpenFlow 1.0. in OpenVSwitch.

Sidebar: Why Node.JS

Node.JS has become one of the most watched repos in GitHub and is headed up by the brilliant guys at Joyent. Anyone interested should check out Bryan Cantrill’s presentation  Building a Real-Time Cloud Analytics Service with Node.js

Setting up the development environment

Leveraging OpenVSwitch and tools such as MiniNet, anyone can create a simulated network environment within their own local machine. Instructions on how to setup the development environment can be seen here Download and Get Started with Mininet

Code review

We first setup the network server with a simple call to net.createServer, which we provide the port and address to listen on. The address and port are configured through a separate start script.

NodeFlowServer.prototype.start = function(address, port) {
var self = this

var socket = []
var server = net.createServer()

server.listen(port, address, function(err, result) {
util.log("NodeFlow Controller listening on " + address + ':' + port)
self.emit('started', { "Config": server.address() })
})

The next step provides the event listeners for socket maintenance, creates a unique sessionID from which we can keep track of each of the different switch connections and our main event process loop which is called every time we receive data on our socket channel. We use a stream library to buffer the data and return us the OpenFlow decoded message in the msgs object. We make a simple check on the message structure and then pass it on for further processing.


server.on('connection', function(socket) {
    socket.setNoDelay(noDelay = true)
    var sessionID = socket.remoteAddress + ":" + socket.remotePort
    sessions[sessionID] = new sessionKeeper(socket)
    util.log("Connection from : " + sessionID)

socket.on('data', function(data) {
    var msgs = switchStream.process(data);
    msgs.forEach(function(msg) {
    if (msg.hasOwnProperty('message')) {
         self._processMessage(msg, sessionID)
    } else {
         util.log('Error: Message is unparseable')
         console.dir(data)
   }
})

In the last section we leverage Node.JS EventEmitters to trigger our logic using anonymous callbacks. These event handlers wait for the specific event to happen and then trigger processing. We handle three specific events just for this initial release: ‘OFPT_PACKET_IN which is the main event to listen on for PACKET_IN events, and ‘SENDPACKET’ which simply encodes and sends our OF message on the wire.


self.on('OFPT_PACKET_IN', function(obj) {
 var packet = decode.decodeethernet(obj.message.body.data, 0)
 nfutils.do_l2_learning(obj, packet)
 self._forward_l2_packet(obj, packet)

})
 self.on('SENDPACKET', function(obj) {
 nfutils.sendPacket(obj.type, obj.packet.outmessage, obj.packet.sessionID)
 })

The “Hello World” of OpenFlow controllers simply provide a learning bridge function. Here below is the implementation, which is fundamentally a Python port of NOX Pyswitch.


do_l2_learning: function(obj, packet) {
 self = this

var dl_src = packet.shost
 var dl_dst = packet.dhost
 var in_port = obj.message.body.in_port
 var dpid = obj.dpid

if (dl_src == 'ff:ff:ff:ff:ff:ff') {
 return
 }

if (!l2table.hasOwnProperty(dpid)) {
 l2table[dpid] = new Object() //create object
 }
if (l2table[dpid].hasOwnProperty(dl_src)) {
 var dst = l2table[dpid][dl_src]
     if (dst != in_port) {
       util.log("MAC has moved from " + dst + " to " + in_port)
     } else {
          return
     }
} else {
     util.log("learned mac " + dl_src + " port : " + in_port)
     l2table[dpid][dl_src] = in_port
}
 if (debug) {
     console.dir(l2table)
 }

}

Alright, so seriously why the big deal.. There are other implementations which do the same thing, so why is NodeFlow so interesting. Well if we look at setting up a Flow Modification, which is what gets instantiated in the switch-forwarding table, you see we can see every element in JSON notation thanks to the OFLIB-NODE Library. This is very important as deciphering the TLV based protocol from a normative reference can be dizzying at best.


setFlowModPacket: function(obj, packet, in_port, out_port) {

var dl_dst = packet.dhost
var dl_src = packet.shost
var flow = self.extractFlow(packet)

flow.in_port = in_port

return {
 message: {
   version: 0x01,
     header: {
       type: 'OFPT_FLOW_MOD',
       xid: obj.message.header.xid
     },
     body: {
       command: 'OFPFC_ADD',
       hard_timeout: 0,
       idle_timeout: 100,
       priority: 0x8000,
       buffer_id: obj.message.body.buffer_id,
       out_port: 'OFPP_NONE',
       flags: ['OFPFF_SEND_FLOW_REM'],
       match: {
         header: {
         type: 'OFPMT_STANDARD'
         },
         body: {
           'wildcards': 0,
           'in_port': flow.in_port,
           'dl_src': flow.dl_src,
           'dl_dst': flow.dl_dst,
           'dl_vlan': flow.dl_vlan,
           'dl_vlan_pcp': flow.dl_vlan_pcp,
           'dl_type': flow.dl_type,
           'nw_proto': flow.nw_proto,
           'nw_src': flow.nw_src,
           'nw_dst': flow.nw_dst,
           'tp_src': flow.tp_src,
           'tp_dst': flow.tp_dst,
         },
       },
       actions: {
         header: {
           type: 'OFPAT_OUTPUT'
         },
         body: {
           port: out_port
         }
       }

    }
 }

Performance and Benchmarking

So I used Cbench to compare NOX vs. NodeFlow and here are the results.

NOX [./nox_core -i ptcp: pytutorial]

NOX c++ [./nox_core -i ptcp: switch]:

NodeFlow [running with Debug: False]:

C based Controller:

As you can see from the numbers NodeFlow can handle almost 2X what NOX can do and is much more deterministic. Maxing out at 4600 rsp/sec is not shabby on a VirtualBox VM on my Mac Air!

Summary

At just under 500 LOC this prototype implementation of an OF controller is orders of magnitude less than comparable systems. Leveraging JavaScript and the high performance V8 engine allows for network architects to experiment with various SDN features without the need to deal with all of the boilerplate code required for setting up event driven programming. Hope someone gets inspired by this and takes a closer look at Node.JS for network programming.

So how do I get NodeFlow?

NodeFlow is an experimental system available at GitHub: git://github.com/gaberger/NodeFLow.git along with my fork of the OFLIB-NODE libraries here: git://github.com/gaberger/oflib-node.git. If you would like to contribute or have any questions please contact me via Twitter @gbatcisco

Special thanks to Zoltan LaJos Kis for his great OFLIB-NODE library for which this work couldn’t have been done and Matthew Ranney for his network decoder library node-pcap.