Introduction to SDN Softwaredefined Networking

this video is an introduction to Software Defined Networking or Sdn the video starts with the statement of the primary goal of Sdn after that it will cover a simple three layer model of an operating system this will serve as an analogy for Sdn which will be covered next then I'll take a closer look at some of the details of the Sdn components as well as cover a high-level example of packet flow across an Sdn network after this I'll discuss availability and scalability in an Sdn network finally I'll look at how an Sdn network compares to today's traditional networks for more detail on Sdn I recommend the I Triple E paper software-defined networking a comprehensive survey this video sources material from that paper including the operating system analogy coming up in a moment the big picture for Sdn the main goal of Sdn is for the network to be open and programmable if an organization requires a specific type of network behavior it can develop or install an application to do what it needs these applications may be for common networking functions for example traffic engineering and security there will also be Sdn applications for functionality that hasn't been thought of today and will be introduced in the future at the core of Sdn is creating an environment where this kind of flexibility exists and the network can evolve at the speed of software the operating system model to enhance the understanding of software-defined networking it can help to look at something that is already well understood an operating system on a common desktop computer this will serve as an analogy to help understand Sdn at a high level we can break down a desktop computer OS into three basic layers first there is the operating system itself the operating system acts as a middleman managing access from applications to underlying hardware the OS also comes with core services to aid in this process the operating system is responsible for managing system Hardware on the lower level for example CPU storage memory and network interfaces instead of calling it the lower level we can also say to south of the OS above the operating system or on the north side are the applications the ability to develop or add-in move applications makes a system a flexible one that can be customized to your specific needs whether that is gaming design engineering and so on the Sdn model for the Sdn model this will look quite similar to the operating system model just discussed instead of the operating system the middle layer for Sdn is the network operating system or nós this is also commonly called an SDN controller the network operating system will typically have core services to aid in its job of interfacing with network nodes and for providing a programmable interface to the network applications on the south side instead of hardware like the processor storage memory we have network forwarding devices forwarding devices receive packets take actions on those packets and update counters types of actions include simply dropping the packet modifying packet headers and sending packets out a single port or out multiple ports the instructions for how to handle packets originated with the Sdn controller like the desktop model on the top or the north side there are applications now we can just call them Network applications just like applications on top of a standard OS these applications can serve many purposes but of course with Sdn they are all Network focused packet flow what happens when a packet arrives at an SDM controlled forwarding device the forming device will parse the packet headers and it either already knows what to do with the packet or it queries the network operating system the network applications on the SDN controller determine what action to take on the packet and push this information down to the forwarding device using the Sdn controller as a translator the forwarding device will then take the assigned action on the packet whether that's modifying headers dropping it telling the packet somewhere and so on the following device will usually also cache instructions so that future packets don't require checking with the Sdn controller the same process continues device by device until the packet leaves the Sdn network to a destination into a different Sdn region or into a traditional non Sdn Network future packets of the same type can take a fast path with no need to contact the Sdn controller based cashed entries learn the first time this will last until flow entries on forwarding devices expire due to timer's running out the result so what has been achieved for this model there is a logically centralized network operating system or Sdn controller the controller has a global view of all Network forwarding devices below it and as a way to communicate packet forwarding instructions to them the controller can then create an abstraction or simplified view of the network to network applications which use this information to make key decisions about how to implement Network policies for example a network security application probably doesn't care about all the possible paths between points in the network and for hit the Sdn controller might provide an abstraction of the entire network as a single large switch SD n components deeper dive in this section I'll provide some more detail about the Sdn model and its components forwarding devices again at the lowest layer are the forwarding devices these can be traditional hardware switches as long as you support a programmable interface like open flow or they can be software switches like open V switch Hardware switches can usually be expected to support higher performance while software switches provide greater flexibility for new behaviors the southbound interface the Sdn controller needs a way to communicate with network forwarding devices types of information that needs to be communicated includes packet handling instructions alerts of packet arrivals on network nodes notifications of status changes like links going up or down and providing statistics information like flow counters all this happens over the southbound interface the most talked about protocol for Sdn on the southbound interface is the open flow for packet handling instructions to learn more about open flow you can go to the open networking foundation org you can also watch my introduction to open flow video on my youtube channel complementary to open flow is the o vs DB protocol which is a network management protocol used to manage network device configurations an open V switch and is also being adopted by some hardware based switches the network operating system the network operating system is commonly referred to as an SDN controller controllers typically will run with core services examples include a topology service and inventory service a statistic service and a host tracker a topology service determines how forwarding devices are connected to one another and builds what's known as a topology graph this might work for example by instructing a switch to send lldp packets or other specialized packets and discovering where they arrive an inventory service is used to track all Sdn enable devices and record basic information about them for example what version of open flow and what capabilities they support a statistics service can be employed for reading counter information off of flow editing devices like traffic counters on flows interfaces and flow tables a host tracker will discover where IP address as a MAC addresses of hosts are located on the network typically by intercepting packets in the network or perhaps in coordination with a VM scheduling platform application interfaces the Sdn controller will provide application interfaces for network applications to hook into the Sdn controller should provide a simplified abstraction of the underlying network infrastructure as noted earlier it is often sufficient for the entire network fabric to be represented as a single large switch for an application there can be native plugins co-located with controllers and using a programming Loic language based api like java then there is the northbound interface this is commonly a restful interface which allows the use of standard HTTP calls directed towards the controller to control network behavior and gather information collected by core services there is also much discussion in the community about coming to a standardized northbound interface to aid on the goal of rapid innovation network applications and portability between different controllers today this type of standardization does not exist network applications network applications can serve a wide range of disciplines as noted earlier with Sdn providing a programmable abstraction of the network fabric network applications can affect B whatever an organization requires in the context of controlling network behavior and implementing network policies the network as an elastic resource the presence of an Sdn network enables slicing up the network differently for different workloads this slicing can occur at different layers for example on the southbound side classifications of traffic can be directed to entirely separate Sdn controllers on the northbound side different traffic types can be handled by different network applications or be treated differently by a single application this environment enables the network to be treated like a resource to be shared by different tenants or workloads each unique tenant or workload can then use the network in different ways this is much more like the way compute resources are handed out as an elastic resource and cloud infrastructures today fault tolerance and scalability this video is not about Sdn architectures however I did want to briefly highlight an important concept commonly an SDN controller is referred to as being logically centralized it is important to understand how this is different from saying it is physically centralized in a production network you would not depend on a single physical Sdn controller this will leave a single point of failure for the entire network additionally there could be scaling limitations there are different ways to make sure the Sdn network is both highly available and scalable one is clustering or teaming this is nothing new in areas like database servers the idea is to have a cluster of systems that can load balanced workloads instead of a single system this provides high availability since one or more systems can go down and there are still active functional systems this also provides scalability as multiple systems can handle requests additionally the narrow can be separated out into different regions with each region's traffic handled by a regional Sdn controller different regions can then communicate information between one another as needed using an east-west protocol finally Sdn controllers might be designed in hierarchy there may be high-level controllers with high levels of abstraction and lower level controllers underneath closer to the network forwarding devices traditional Network Devices the last part of this video will look at traditional Network Devices and what has changed from the traditional in an Sdn world traditional network nodes have a data plane and a control plane both contained within a single physical system the job of the data plane is to handle packets a-line rate in Hardware based on information stored in tables the FIB alphab and mac tables execution instructions in the data plane originated in the control plane the control plane is sometimes referred to as the network nodes brain the network node uses the control plane to communicate with other nodes in the network by running distributed protocols like bgp MPLS and OSPF so the control plane handles the complexity and is where network policies are enforced the control plane determines how individual packet types should be handled and pushes this information down to the fast path and the harbour based data plane what are the differences from the Sdn ecosystem discussed earlier first traditional network nodes are proprietary locked boxes the control plane is chained to the data plane and both are coupled together in a single network node there is no direct access into the behavior of the data plan to implement network policies network operators have to think in terms of what is available in the control plane already in other words what feature sets the device includes operators most often configure the device through a command-line interface if a new kind of network behavior is required options can be limited another disadvantage of a traditional network compared to an STI network is each network node is configured individually so a network operator is not dealing with just a single point of configuration in a data center for example there could be tens or hundreds of nodes to reconfigure to implement new policies each of these nodes has its own control plane and all these control planes must communicate using distributed protocols this traditional Network paradigm is typically complex and that times can lend itself to configuration errors as stated earlier by contrast with an STM network there is a logically centralized controller with a global view of the entire network as a result of the centralized control there are not the complexities of handling distributed protocols and configuring policies on hundreds of nodes however it is important to note that we can expect significant complexity to be present in the architecture of the Sdn controller itself to accomplish all of its goals that wraps up this introduction to stn I hope you found it helpful to get a clearer grasp with some of the core STM concepts if you'd like to see more videos like this please subscribe to this channel also if you'd like to contact me directly you can do so through WWE linked ENCOM /i n slash David Muller once again for an in-depth look at Sdn I recommend the I Triple E paper Software Defined Networking a comprehensive survey which I'll provide a link to in the video description