Get Started on SDN and Cisco ONE: Learn from Our New Technical White Paper

If you were to believe the industry press, you could easily be forgiven for thinking that many companies across the world were rolling software defined networking (SDN) technologies into their networks today.  I’m part of Cisco’s Services team and my colleagues across the world are the experts in helping you all design and deploy networks.  If there is a large or complex leading (or bleeding!) edge network out there being designed, you can place a safe bet that someone from the Cisco Services team is involved helping our customers achieve their targets.  If you’re involved in deploying any type of high technology equipment, you’ll appreciate that there is a world of difference between selling, demoing, and actually making it all work in your environment when it comes to new technology. Our team are in the latter camp.

So what are our consultants telling me about SDN in the real world?  Excluding a few notable high profile cases (usually involving hyper-scale data centers) they are not seeing – as yet, to be honest – many early deployments.  However they are seeing a growing number of customers interest in learning about and evaluating SDN related technologies – including Cisco ONE, NFV and in particular Application Centric Infrastructure (ACI).  And they are providing some early feedback on the use cases of SDN that customers are most interested in.  They are all clear, however, on this point: this is the time to learn what SDN and Cisco ONE can do for your network in the future.

So how do you get started in SDN?  Let me outline 5 key steps to help you get started.  I’ll also point you to a technical white paper written by Mitch Mitchiner and Reema Prasad, two of our Customer Solutions Architects in Cisco Services, two of our experts responsible for making all of this work for you, your team and your business.  I also recommend you check out the video link I’ve provided, for an excellent live demo of Cisco ONE technology, first presented at Cisco Live last year.  This video gives a live demo of latency-based routing, one of the use cases described in Mitch and Reema’s paper.

https://www.youtube.com/watch?v=tp7Y7OiuwJk

Step 1: Focus on Use Cases

To get started on SDN, many people will dive into the technology, the protocols and so on.  However I would recommend you first learn about SDN by reading up on the “use cases” -i.e. focus on what SDN can do for your network , what problems can SDN solve for you and so on.  Once you have formed an idea on the potential benefits for your network, you can then evaluate the technology options more objectively.

Let me first comment on the term “use case”, which is all too often bandied about without proper understanding in my view. (While Wikipedia has a fairly high level definition of this term, for me, the TechTarget definition is more useful).   Someone told me a while back that their SDN use case was “to use low cost switches”.   This really isn’t a proper use case.  “Use them to do what?” was my response.  Turns out he needed his network to do all that it did today – and cost of infrastructure wasn’t as much a use case as it was a constraint and/or objective.   You may also have read my previous blog on the December 2012 SDN Conference in London – where I watched a demo of SDN being used to “fix” a poorly performing network application. I believe you’ll get more bang for the buck if you use SDN strategically, and not as a band aid!  So make sure you consider use cases from a business value perspective.

Here is a quick summary of a few of the use cases that you can find discussed in various articles (SDN Central has some good discussions around OpenFlow and NFV in particular – but don’t forget about network APIs and ACI) and books. Please note that this is intended to provide an introduction only, and not be an exhaustive list!

1. Bandwidth Calendaring – time-based bandwidth manipulation, in order to modify bandwidth characteristics to more closely match traffic patterns, service demands and disruptions
2. Topology as a Service – ability to configure on-demand network topologies in a much more ad-hoc manner than is possible today
3. Network path optimization on demand – this could be very powerful for big data applications, for example to modify network flows to support more rapid results from a data virtualization app
4. “Input traffic monitoring – trigger action” type use cases:  e.g. developing enhanced firewall/network security features, development of new intrusion detection (IDS) features
5. Custom packet encryption to increase security
6. Latency based routing – use link with lowest latency, attractive for financial institutions in particular
7. Enabling network “slicing” – can save you having 2 networks, for example one for admin staff and one for network research (as you may have in a university, for example)
8.  QoS/ACL provisioning and compliance checks – basically checking both ends of a link for integrity in configuration.  Could also be applied to tunnels and other network constructs

You can learn more on SDN use cases in Mitch Mitchiner and Reema Prasad’s paper which discusses Software Defined Networking and Use Cases.  While the authors have written this for public sector (including defence) organizations, I personally think this paper is an excellent pragmatic “getting started” learning guide to SDN and more importantly what you can use SDN for so I’d recommend it to anyone!  It’s a technical white paper, including code examples – so well worth a read.  

 Step 2: Understand the Technology Options

Again you may be forgiven for assuming that SDN == OpenFlow.  There are several technology options that deliver the benefits of network programmability and SDN: for example, network APIs, Cisco Application Centric Infrastructure, network virtualization, network function virtualization and OpenFlow.  Learn about them all.  Don’t trust a vendor who only offers one of these – you may miss the technology that best satisfies your business use cases!

Step 3: Consider your SDN Partner(s)

Which SDN vendor(s) will you work with? – at the device level, at the controller level, at the apps layer, and the network services layer.  Evaluate them not just based upon technology capabilities, but also based upon their technical support services and professional services.  After all, it’s you that needs to get this new solution up and running – you may benefit from help along the way, so don’t ignore the design and technical troubleshooting services you may need.  In a future blog, I’ll give you a template to help you evaluate your SDN partner across all of these capabilities.

Step 4: Consider your SDN Adoption Strategy

Why not work with an expert to help define your SDN strategy?   We in Cisco Services offer our customers Cisco ONE Strategy & Analysis Services – I blogged about these previously – which will help you map out your options, with the help of one of our Cisco ONE and ACI experts.

Step 5: Try it out – Run a Pilot

Finally, before you decide on a specific use case and set of technology options – TRY THEM OUT!!  Run a pilot, a validation exercise – don’t just jump straight to a vendor commitment and production deployment until you fully understand the deployment challenges and systems integration work required.  We in Cisco Services can help you run a comprehensive pilot, where you get the chance to test out the appropriate technology option applied to the use case(s) that are of most relevance to your business goals, in order to give you a much better idea of what a full production deployment would require.  And this will be the subject of my next blog!

To close then, on the subject of use cases as I discussed above, what SDN use cases could be most valuable to your organization?  What do you want SDN to do for your network?  Why not add a comment to the blog here, I’ve love to hear from you.  And if you are not yet at the stage of understanding key use cases, feel free to add that in too – you won’t be alone!  And don’t forget to check out our  Software Defined Networking and Use Cases technical white paper.