One things many articles on SDN have in common is, the fact that they are littered with technical terms It is often simpler to glance through these terms, to ease the understanding of the concepts elucidated to in further text.
control plane: It is a logical plane where the execution decisions are taken at a higher level, like taking routing decisions. i.e. it is the brain of the network
data plane: It is the logical plane where actual execution is done at the lower lever, like forwarding packets based on forwarding table. i.e. where the actual function is carried out, is implemented.
mininet: It is a simulator for SDN networks. It is an upgrade over NetSim where we could simulate simple networks via GUI help. In mininet, we have openFlow and SDN support. Simulation environment is set up by writing code and not via GUI.
POX: It is a python framework for configuring a controller. In it every network entity, i.e. 'web server, router, switch' is an component. We create components to introduce entities in our network to be simulated.
OpenFlow: it is a very popular protocol used to communicate between a controlling server and a OpenFlow enabled switch. Using API of OpenFlow, we communicate between server which runs control plane and the actual switches which implement data plane. It is also used to communicate between switches.
dpctl: it is a utility by which we can control the flow aspects for a single switch. It is used for debugging and experimenting with the flow table of the switch. It comes along with openFlow.
note- Incidentally, there is a quick start guide wherein in a virtual box, you import a ovsk format virtual disk which has pre-installed mininet with pox. For more information, look here
Historically, the Data Plane and Control Plane are usually implemented within a single physical device, whether it be a router/ switch or any other layer 3 device. This meant that all network devices literally came in a box, with all their functionality built on a single physical machine. If someone had to change/tweak some functionality, he had to manually configure the specific machine.
However, in the modern era, it would certainly be advantageous if we could implement a little something called separation of concerns. This is achieved by physically separating the Data and Control planes.
This leads to a situation where the control plane controls several devices via a controller, and each device just implements the data plane.
This thinking is exactly what gave rise to the concept of Software Defined Networking, a move to design networks which are dynamic, flexible, more secure and can be controlled centrally. Notionally although this is a fairly new term, in essence its principal have already been applied via various previous protocols.
Even now many people are not sure exactly what SDN entails , including yours truly, but it understanding its functionality separately and combining the pieces bottom up would surely give us a decent idea.
a introductory link, which illucidate the manner in which SDN are used, as well as its underlying benifits is this.
However using a single controller is unfeasible with large number of hosts. Hence we come up with multiple controllers, each connected to separate set of hosts, but behaving as one big logical controller.
control plane: It is a logical plane where the execution decisions are taken at a higher level, like taking routing decisions. i.e. it is the brain of the network
data plane: It is the logical plane where actual execution is done at the lower lever, like forwarding packets based on forwarding table. i.e. where the actual function is carried out, is implemented.
mininet: It is a simulator for SDN networks. It is an upgrade over NetSim where we could simulate simple networks via GUI help. In mininet, we have openFlow and SDN support. Simulation environment is set up by writing code and not via GUI.
POX: It is a python framework for configuring a controller. In it every network entity, i.e. 'web server, router, switch' is an component. We create components to introduce entities in our network to be simulated.
OpenFlow: it is a very popular protocol used to communicate between a controlling server and a OpenFlow enabled switch. Using API of OpenFlow, we communicate between server which runs control plane and the actual switches which implement data plane. It is also used to communicate between switches.
dpctl: it is a utility by which we can control the flow aspects for a single switch. It is used for debugging and experimenting with the flow table of the switch. It comes along with openFlow.
Historically, the Data Plane and Control Plane are usually implemented within a single physical device, whether it be a router/ switch or any other layer 3 device. This meant that all network devices literally came in a box, with all their functionality built on a single physical machine. If someone had to change/tweak some functionality, he had to manually configure the specific machine.
However, in the modern era, it would certainly be advantageous if we could implement a little something called separation of concerns. This is achieved by physically separating the Data and Control planes.
This leads to a situation where the control plane controls several devices via a controller, and each device just implements the data plane.
This thinking is exactly what gave rise to the concept of Software Defined Networking, a move to design networks which are dynamic, flexible, more secure and can be controlled centrally. Notionally although this is a fairly new term, in essence its principal have already been applied via various previous protocols.
Even now many people are not sure exactly what SDN entails , including yours truly, but it understanding its functionality separately and combining the pieces bottom up would surely give us a decent idea.
a introductory link, which illucidate the manner in which SDN are used, as well as its underlying benifits is this.
However using a single controller is unfeasible with large number of hosts. Hence we come up with multiple controllers, each connected to separate set of hosts, but behaving as one big logical controller.
