Back to home Menu

Ocedo’s Controller-based Network

September 7, 2015 - Posted in Technology Brief by

Networking is going through its biggest revolution

If you compare the way networks are run today to the way compute is run, it’s like comparing the stone age to today’s modern society. Network configurations use CLI and it’s a very manual culture. Server virtualization has led to huge efficiency gains, while the efficiency increase for networking has remained relatively flat. The box by box mentality drains resources and acts as a barrier to service insertion and product innovation.The number of administrators that manage switches today is the same as it was 10 years ago. Manual networking simply cannot meet today’s business requirements.

The general consensus is that the networking industry has fossilized. All elements of network infrastructure are vertically integrated. Vertically integrated systems lock and slow down innovation. Examine the case study of buying a switch from a vendor. They make the chip, operating system and decide on the features list, resulting in a monolithic box. Compare this process to the PC industry where you can mix different hardware and software vendors. Offering you additional design flexibility and a quicker “time-to-market”.

Until recently, the evolution of networking has been from Telnet to SSH. There was little innovation. But now, the industry has taken off with broad-scale adoption. Companies like Ocedo are employing the concepts of SDN to drive business and innovation. With the introduction of Software Defined Networking (SDN) and automation, Ocedo’s customers are experiencing similar efficiency gains present in compute environments.

Ocedo Adoption of SDN

The definition for SDN varies. Some define it as a Layer2/Layer 3 architecture with a “centralized controller” that controls the forwarding behaviour of distributed switches. Others define it as a “conceptual framework” in which networks are treated like abstractions.  

Ocedo’s adoption of SDN takes the best out of both definitions.They employ a central controller that abstracts the data plane, providing a singular configuration interface. Ocedos physical infrastructure is based on “white box switching” and open source operating systems, meaning they are not tied down to the long timeframes of standards release dates.

Network Abstraction


Virtual Networking

Ocedo’s architecture moves from an monolithic design to a virtual switching fabric. The data planes can be managed as a whole rather than as a set of loosely coupled independent devices. A virtual architecture appears to be real but it’s not; it’s created by multiple physical entities in dispersed geographic locations. The location of a device is irrelevant for its configuration.

To help understand this architecture, study the concept of First Hop Redundancy Protocols (FHRP) for Data Centre Interconnect (DCI) egress traffic flows. FHRP provide the appearance of a single data centre to hosts. The virtual router doesn’t exists as it’s actually represented by two physical devices in each data centre. The real routers are abstracted by the virtual routers.

Holistic View

Ocedo’s central controller provides a holistic and central view of the network. Central viewpoints represent a single interface between data plane forwarding and the orchestration system.

The real benefits of SDN derive from this. Google, the early adopters of SDN, employed the SDN framework just for the central viewpoint element. They wanted to make traffic engineering decisions based on holistic viewpoints. A central network view simplifies hard-to-solve problems that benefit from centralized visibility.

An holistic approach brings network agility to Ocedo’s infrastructure and allows them to roll out network changes quickly. The administrator does not have to manage switches individually or know the command syntax. The network can be fully designed within the controller canvas and once the design is agreed, changes are rolled out automatically with a single click. High level policy is entered with northbound interface, the controllers transaction layer converts this to lower level details for translation with its southbound protocols for actual device configuration.

Control Planes

SDN does not automatically mean centralised control plane. The SDN architecture comes in a number of forms. The control plane can be local to the forwarding devices, similar to Cumulus and Pica8. Or utilize a centralised control plane, such as Big Switch networks. Google employs a hybrid distributed/centralized model.

“Central policy engine does not mean a centralised control plane”

Control plane elements not only include routing protocols but also real-time sensitive protocols such as BPDU, LACP, and UDLD. Having these control plane protocols in a central point inhibits scalability. Early adopters of SDN started with central control planes and only got a scalable product when they deviated from the concept of central control plane and started to implement control-plane protocols locally.

This is relevant in other networking architectures. If we look outside the SDN-specific framework and examine Nexus 1000v architecture. It previously operated a centralised control plane (VSM) and multiple distributed forwarding planes (VEM). All control plane protocols such as IGMP snooping and Netflow operated in the VSM. This looked great in powerpoint but in real life it doesn’t work that well. The first problem they ran into was LACP and had to implement LACP offload to the VEM. They started to hit scalability problems and could only run 60 or so hosts. Eventually, they moved all control plane elements to the VEM and now they can run over 250 hosts. Even traditional centralized networks, such as Frame Relay and SDH/SONET has some local intelligence, as this is the only approach that can scale.

Ocedo understood the inefficiency of central control planes and implemented local control plane but still operated a central viewpoint. Local control points lets their architecture scale much better than some other SDN companies that have a central control plane.

Ocedo and Open Source

Bare metal switches are switches that are not locked into one specific vendor. They enable companies to buy a generic Ethernet switch without an operating system and install one of choice. A recent Stanford webinar from Guido Appenzeller envisioned it will be the standard in 10 years time. The concept of buying hardware from numerous vendors and implement your own software saves huge costs to the enterprise. Ocedo buy the switch hardware from Taiwan and run OpenWRT, a Linux based operating system with Open vSwitch (OvS). OpenWRT is based on the Linux kernel and removes the boundaries of proprietary firmware. OvS is a multilayer virtual switch that support numerous protocols and has many useful programmatic extensions. OpenWRT and OvS are both open source platforms.

The company philosophy believes in open source and they continually contribute to the opensource community. Ocedo architecture is an open source as it can be. It is very difficult to open up every part of your architecture. There are disincentives from vendors to implement open interfaces due to fear of commoditization. Also, with a standards approach there are time constraints for certain standards/features to be released. Open communities take time for features to become a standard. Not following to the specific standards allows you to ship the solution much quicker. In a rapidly changing environment, where technology is changing, it is very hard to follow the standards based model. Ocedo is not tied down to the standards framework and timeframes, enabling them to release features quickly, meeting customers expectations and requirements.

Standards Release Development


Incentives for Employing SDN

The incentives for employing SDN solutions are strong and the benefits of reduced CAPEX and OPEX are being passed by Ocedo to their customers. Ocedo is already helping a large variety of customers to achieve greater network agility and operations. For more information on how Ocedo can help your business, please visit the links.

– by Matthew Conran, Network Insight

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>