Intro to SDN - Part III
•
1 like•851 views
- The document discusses different definitions and implementations of software-defined networking (SDN). - Traditionally, SDN is defined by separating the network control and forwarding planes, with the control plane software located in a centralized controller. - However, some vendors implement SDN by only exposing proprietary APIs on network devices, leaving control plane functions in the devices. - True open SDN follows the OpenFlow standard to simplify devices and move all control functionality to external controllers, enabling network programmability.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Intro to SDN - Part III
Similar to Intro to SDN - Part III (20)
Recently uploaded
Recently uploaded (20)
Intro to SDN - Part III
- 1. Tallac Networks Webinar Series Software-Defined Networking Tallac Networks Confidential
- 2. About the Presenter • Chuck Black, Principal Software Architect and all- around good guy at Tallac Networks • 30+ years experience doing research and development in networks, network security, and network management Tallac Networks Confidential
- 3. SDN Intro: Part III Wait – who stole my SDN?! Tallac Networks Confidential
- 4. An Old Joke Question: How many Microsoft engineers does it take to screw in a light bulb? Answer: None. Bill Gates just declares “Darkness” to be an international standard. Tallac Networks Confidential
- 5. An Old Joke Revisited Question: How many Cisco engineers does it take to implement SDN? Answer: None. Cisco just declares their current solution to be the international SDN standard. Tallac Networks Confidential
- 6. Jumping on the SDN Bandwagon • “We’ve been doing SDN for years” • “We practically invented SDN” Tallac Networks Confidential
- 7. SDN Refresher Separate Control and Forwarding Planes Moving control functionality to centralized controller • Removing control software Controller from device Control Control • With SDN, the device handles the forwarding and data planes • With SDN, the controller Data Data hosts the control plane Forwarding Device Forwarding Tallac Networks Confidential
- 8. Redefinition of SDN Programmable API on Device Providing APIs to dynamically control devices • Much of the control Controller software remains in device Control Control • Controller can dynamically API API control devices via APIs Control Control • Meets some SDN goals for programmability, but not Data Data for openness or simplicity Device Forwarding Forwarding Tallac Networks Confidential
- 9. Open Networking via SDN App App App App App App App App Controller • Controller Simplified devices • All control functionality in Data controller Forwarding Data Data Forwarding • Fully distributed Forwarding enforcement, and easy to innovate Data and evolve Forwarding Data Forwarding Tallac Networks Confidential
- 10. Controller and RESTful API App App App App App App App App Controller What you get: Controller Proprietary API • Some network programmability • "Proprietary openness” • No device simplification Who: • Cisco, Alcatel- Lucent, Brocade* Tallac Networks Confidential
- 11. Networking Device Today • Proprietary, vendor-specific control-plane software residing in network device Network Device Network Device SOFTWARE SOFTWARE Services Services SNMP Agent SNMP Agent Web ACLs Web CLI QoS ACLs CLI QoS Routing Routing Security Security Virus Virus Spanning Spanning CONFIG Snooping Snooping Access Control Access Control CONFIG Throttling Throttling Tree Tree Low-level ASIC interface Low-level ASIC interface ASIC ASIC TCAM TCAM TCAM TCAM TCAM TCAM TCAM TCAM TCAM TCAM Tallac Networks Confidential
- 12. Networking Device with Openflow • SDN device: Move all that software off of the router or switch, up to the controller Network Device Network Device SOFTWARE SOFTWARE to Controller Openflow Openflow Low-level ASIC interface Low-level ASIC interface ASIC ASIC TCAM TCAM TCAM TCAM TCAM TCAM TCAM TCAM TCAM TCAM Tallac Networks Confidential
- 13. ”SDN”: APIs to non-Openflow devices • SDN device: Provide an API on top of the switch's existing configuration mechanisms Network Device Network Device RESTful API SOFTWARE RESTful API SOFTWARE Services Services SNMP Agent SNMP Agent Web ACLs Web CLI QoS ACLs CLI QoS Routing Routing Security Security Virus Virus Spanning Spanning CONFIG Snooping Snooping Access Control Access Control CONFIG Throttling Throttling Tree Tree Low-level ASIC interface Low-level ASIC interface ASIC ASIC TCAM TCAM TCAM TCAM TCAM TCAM TCAM TCAM TCAM TCAM Tallac Networks Confidential
- 14. Can’t Blame the Vendors • Taking advantage of the huge amount of hype around SDN today • APIs into devices to allow some software-based network control is good • Anything to alleviate some networking deficiencies in the datacenter is good Tallac Networks Confidential
- 15. SDN Litmus Test • To what extent does it foster openness and promote innovation in the network? • To what extent does it simplify the responsibilities of the network devices? • To what extent does it facilitate fast, dynamic, and agile network re- configuration? Tallac Networks Confidential
- 16. Redefining SDN? • Is Openflow not enough? Perhaps • Is merely putting APIs on devices enough? No Don’t throw the (Openflow) baby out with the bathwater Tallac Networks Confidential
- 17. SDN Definition Evolves... • 2008-2011 Open environment, separate control/data planes, mainly Openflow and some extensions • 2012 Academia, researchers, some vendors: Same as above Other vendors: Programmable APIs Other vendors: Virtualization and tunnels Other vendors: Open platform inside networking devices • 2013+ Stay tuned... Tallac Networks Confidential
- 18. SDN Intro: Almost there • Part IV: SDN, Schmesh-DN. Why should I care? Or, “Yawn. Boooring. Give me one good reason why I should care and not still punch you.” Tallac Networks Confidential
- 19. About Tallac Networks • Consulting and training services • SDN enterprise deployment solutions Contact us: o www.tallac.com o Tallac Networks 6528 Lonetree Blvd Rocklin, CA 95765 916.757.6350 Tallac Networks Confidential
Editor's Notes
- Hey, I’m Chuck Black, welcome to Tallac Networks Webinar Series on Software Defined Networks. Let’s get started!
- Before we begin, my name is indeed Chuck Black, principal software architect blah blah blah. Over 30 years of experience in networking blah blah blah. That’s a picture of me right before the Mayan Apocalypse.
- This is the third part of the SDN Introduction, which I’m calling “Wait – who stole my SDN?!”
- First let’s begin with an old joke, from back in the days when Microsoft and Bill Gates ruled the world. Question: How many Microsoft Engineers does it take to screw in a light bulb? Answer: None. Bill Gates just declares “Darkness” to be an international standard.
- Updating that joke a little bit for today’s topic: Question: How many Cisco engineers does it take to implement SDN? Answer: None. Cisco just declares their current solution to be the international SDN standard.
- It actually does feel this way, as more vendors come out with statements on SDN, as they pile onto the SDN bandwagon. Some have said that they’ve been doing SDN for years. Some have said that they’ve practically invented SDN. Are they telling the truth? Or are they coming up with a pitch that puts them into the frame regarding SDN?
- In order to understand this better, it might be helpful to take a refresher look at our definition of SDN from the previous sessions. Remember that the primary change taking place in the implementation of an SDN solution was the separation of the Control functionality, moving it off of the device. With SDN, the device only has responsibility for handing the lower-level data plane forwarding of packets. The controller hosts the more complicated control plane software
- With all of these companies jumping onto the bandwagon, SDN is being re-defined to mean something different. The idea, as promoted by many vendors, is to just provide APIs into their devices, in order to dynamically control them. Notice that much of the control software resides in the device. There is at least a controller on which software can run to dynamically control those devices via APIs This solution does meet some of the SDN goals for programmability. However, as you can see, it does not realize the goals of SDN in the areas of openness and simplicity.
- Looking at the broader picture, remember that an SDN network consists of simple devices responsible for forwarding, with centralized controller controlling policy and hosting all that complicated control plane software. And that controller presents an open interface for applications to come along and implement some of that control plane functionality in new and creative ways.
- However, with some of the newer definitions of SDN, you have just a controller and RESTful APIs on the devices. What you get is: Some network programmability via those APIs. A level of openness in that you have APIs to control the devices, but these APIs are proprietary. You could call it “proprietary openness”. And of course, you don’t have the level of device simplification that you get when you move all that control functionality up to the controller. Who is implementing this type of SDN? Right now, some of the major players who are advertising their past and current “SDN” implementations of this nature, are Cisco, Alcatel-Lucent, and Brocade. Brocade is starred because they actually are very active in implementing the more open version of SDN, implementing Openflow in their devices as well as providing this API-type of SDN.
- Just to drive the point home about the difference between our original definition of SDN, and this re-definition, recall this picture of a networking device, filled with all this control-type software…
- When you make this into an SDN device by implementing Openflow, we’ve effectively cleared all that control stuff out of the device and moved it up to the controller.
- With a purely API-based approach, little or no software may be removed from the device, making it nearly as heavyweight as today.
- So, looking at this re-definition of SDN, you can’t really blame the vendors. To a certain degree they have been caught on the outside looking in, and waiting for the SDN “fad” to pass away, which didn’t happen. What should they do? One think is to attempt to cash in on the hype surrounding SDN, which they can do easily via APIs And we should not dismiss the fact that those APIs do provide some value – being able to programmatically control a device from a centralized controller via reasonable APIs (e.g. not CLI or SNMP) is definitely helpful. Doing this does definitely alleviate some of the problems facing the networking side of datacenters today.
- How can you determine if what a vendor is calling “SDN” is really fulfilling the hopes and the promise of SDN? I’m sure you could come up with a litmus test also, but here is mine: To what extent does the solution foster openness and promote innovation in the network? To what extent does it simplify the responsibilities of the network devices? To what extent does it facilitate fast, dynamic, and agile network reconfiguration? Just looking at the list, you can probably figure out that the first two may run at counter-purposes to networking vendors today, while the third – fundamentally about datacenters – is absolutely something that must be addressed today.
- So, what shall we conclude about this idea of redefining SDN? Let’s answer a couple questions: Is Openflow not enough? Might there be a need for Openflow, plus more stuff? Yes, that’s probably true. Is merely putting APIs on devices enough? Based on SDN litmus tests such as the one on the previous slide, the answer is emphatically no. Some SDN re-definers have attempted to discredit Openflow because it cannot do everything yet. I would say, just because that may be true, let’s not throw out the Openflow baby with the bathwater… … perhaps that’s not the best picture I could have chosen. Let’s try another. There that’s much better.
- So just as networking needs to be more fluid and dynamic, we see that even the definition of SDN has recently become a bit fluid and dynamic itself. Just as a recap: In the early years, SDN meant an open environment, separate control and data plains, using mainly Openflow with some extensions. In this last year, researchers are academia are still working in this operational model of SDN. However, other vendors have come in and attempted to redefine SDN somewhat, to mean programmable APIs, and other to define it to mean a couple areas that we have not touched on yet (but will in a future session), the idea of virtualization, tunnels, and even the idea of opening up networking devices so that you can write software that runs inside them. Where will it go from here? Don’t touch that dial!
- Okay so now we are ¾ of the way done with “SDN Intro”. The next session will be around the topic of “Why should you care?” Hopefully I will give you at least one reason, and not feed your pugilistic tendencies…
- Again we are Tallac Networks, thanks for taking the time to listen! Hope to see you next time, and until then, this is Chuck Black saying goodbye. Goodbye!