Software Defined Networking (SDN) is the biggest buzzword in networking today. At the Open Networking Summit (ONS), it became clear that it’s more than just a buzzword. Here’s a quick primer on what you need to think about if you’re considering implmenting SDN.
What is SDN?
SDN is a method for injecting agility into your network. While technically it’s “decoupling the control plane from the data plane (or forwarding plane)”, what SDN does is collect configuration from the network elements into a central controller, then make central decisions on how each network element should forward data around the network. What sets this apart from a decent Element Management System (EMS) is an Application Programming Interface (API), allowing integration and automation – connections to other programs which also react to the network state and tell the controller what changes to make.
Centralized decisions have two advantages over classic decentralized network forwarding: there is a more complete view of the network so decisions can arguably be made with better data, and there is no reconvergence delay on network elements when something in the network changes. In classic routing, if a link or segment goes down (or needs to be taken down), it takes time (usually just under a minute) for the updated routing information to be forwarded to all affected routers. While recovery is automatic, it’s slow. There’s a similar problem in classic switching: switches track MAC address location based on ingress (where did I see this come from?) and then naively assume that’s the direction to forward traffic to that device – which is no longer true if the MAC address moves due to vMotion, etc. While there are methods for switches to inform each other of MAC address locations (TRILL, SPB, etc), there’s not a lot of widespread adoption, especially given the rise of overlays with central controllers (which is a flavor of SDN).
Do I need new hardware?
Early discussions of SDN were all about OpenFlow, and created buzz about reactive forwarding – if a switch saw a new session, it would poll the controller and ask what to do. That required switch hardware changes to support the new protocol and new behavior. However, two things have happened since: first, enough time has passed that a lot more switches now support OpenFlow, and the switches you got in your recent hardware refresh cycles may be SDN-compatible; and second, the concept of SDN has expanded well beyond OpenFlow.
The poster child of SDN in the enterprise is the OpenDaylight controller (ODL), which is built to support a wide variety of hardware and a wide variety of protocols. I spent a day at ONS in the ODL developer track, which went into detail on getting ODL running, the changes in the new Lithium release, etc. ODL’s southbound communications channel (to the devices) is based on “yang models”, which are plugins to tell ODL how to communicate with each device. It might feel like SNMP MIBs – a bit of a nuisance to upload the specific file(s), but reliable once it’s running. Examples include BGP, SNMP, NETCONF, and more specialized protocols like LISP, I2RS, and TL1. That means that ODL may even provide functionality for equipment that wasn’t built with SDN in mind.
Note that ODL is certainly not the only SDN controller, and not even the only open source SDN controller. At ONS, there was also a lot of attention on ONOS (Open Networking Operating System), an open source controller perceived as focusing on service provider needs.
What does SDN do for me?
SDN really shines when it enables external integration and/or automation. The most prominent use case for SDN is integration with orchestration. In cloud or other hyper-virtualized environments, VMs can be created and retired as-needed, which leads to high churn of MAC addresses. Additionally, if those nodes are horizontally scaled and multi-tiered, each node will have a specific set of requirements for network reachability in 3 directions: North (towards the user), South (deeper into the app), and East/West (peer nodes). This is very much the use case for ODL’s integration with OpenStack. In the VMware world, similar functionality comes from NSX. The key aspect here is that the orchestration sends messages to the SDN controller to make real-time changes the the network configuration – a VM (MAC address forwarding entry) with specific reachability aspects (ACLs) has been created, retired, or moved – and appropriate changes happen automatically in every NE which needs reconfiguration to keep traffic flowing smoothly.
Other use cases are emerging in uncommon areas. One session at ONS focused on SDN in optical transport networking, which historically has required so much manual configuration that connections were often just initially configured and then never changed. Optical transport makes very high speed forwarding decisions within the core by switching at layer 1: routers forward at layer 3 (IP address), switches forward at layer 2 (MAC address or, arguably, MPLS tags), and optical forwards at layer 1 (one of many wavelengths of light being carried in parallel in the fiber). Ultra high speed and low latency comes with the cost of essentially using circuit switching intead of packet switching, so there’s no easy way for any given switch to re-route if a link goes down. Using SDN in this environment makes three important differences: first, end-end provisioning is easy, since the SDN controller has broad network visibility; second, the SDN controller can be integrated into circuit monitoring, so it can automatically fix a broken circuit by reprogramming the optical switches with a different path; and third, the circuits can be dynamically adjusted with different traffic parameters (e.g. bandwidth, sensitivity to latency) based on custmer requests. That leads to lower setup/change time, higher reliability , and emerging services like “bandwidth on demand”. An early example is Pacnet in Southeast Asia, which in November 2014 starting offering a customer portal for operations like doubling their bandwidth for the next hour. That kind of WAN flexibility allows new use cases like additional bandwidth for offsite backups, or on-demand bandwidth for database migrations.
So, is SDN right for me?
The best answer for this question came from a Keynote Panel at ONS: “SDN in Enterprises”. The presenters shared their experiences in their various states of deployment. SDN makes perfect sense for new cloud deployments, especially since there’s an opportunity for a green field network deployment, and a well defined space to learn while preventing new and unknown problems from interfering with established business. However, for a large enterprise with lots of legacy applications, the apps themselves don’t have a lot of agility, so there’s not a lot of return in investing to make the network react to changes. The conclusion I reached is that SDN is most valuable in situations where network configuration changes are the biggest blocker to business. From a business perspective, SDN has to save money, and that only happens where the business computing services are already agile. SDN is only right for your network if it solves a problem that exists today.
For more information, the keynote speeches and panels at ONS were all live-streamed, and are available to view online. The thematic organization of the panels makes it easy to figure out which one(s) are most relevant for your environment. If it looks like SDN will have value for your network, the videos are a great place to start learning more. If it sounds like SDN is right for your network, ONS is a great place to bring your questions.
About The Author
Jim Macleod is a packet geek and product manager. His blog can be found at http://shewfig.blogspot.com and followed on Twitter as @Shewfig.
