I am currently setting up a testing SDN environment, so I am familiar with the sdn concept (separating the Control Plane from the Data Plane of a Switch).
Within my research I was often reading about VXLAN when there was talking of SDN.
Now I am a bit confused, because I understand VXLAN as a Tunneling Protocol and I dont know how this would be related to my idea of SDN.
Another question I would like to ask is: Would it be possible to Connect a Switch over several non-sdn Networks to a existing SDN Topology/ SDN Controller with the VXLAN Technology?
Thank you in advance
you should differenciate between SDN as a concept and VXLAN as a tunneling protocol.
The later used to tag packets and hence you can do some kind of seperation in layer-2. This technique helps with network slicing and have been used in flowvisor.
Forwarding traffic through non SDN network have been studied in many works. I suggest you to read the last one
Magneto: Unified Fine-grained Path Control in Legacy and OpenFlow Hybrid Networks
Good luck
Related
I'm completely new to the space and i have a project that i would like to complete, the project is basically: extracting sensor data in the form of MODBUS than sending the data out through CANBUS. i already have a mod-bus input and a can-bus output.
researching into MODBUS has been a bit confusing so sorry if these questions seem a bit stupid.
Is it possible to write code which can convert MODBUS to CANBUS? or will i need external hardware.
additionally, i'm looking to add a microprocessor to my dev board, is there anything in specific i should look for that would help with my modbus and canbus operations? or will any microprocessor work.
thank you
The basics of all data communication is the OSI model. Start there. Then you'll eventually find out that Modbus is an application layer protocol standard and CAN is a physical/data-link layer standard.
Therefore your question doesn't make any sense. You can't convert an application layer into a physical/data-link layer. You can however convert Modbus to some specific application tier protocol for CAN, such as for example CANopen, Device Net or J1939. Or a custom one.
The lowest layers underneath Modbus is UART and most likely RS-485. Possibly RS-232.
You will need a RS-485 or RS-232 transceiver between the Modbus sensor and your MCU. And you will need a CAN transceiver between your MCU and the CAN bus. Additionally, it is very strongly advised to pick a MCU with built-in CAN controller hardware.
Pick a target hardware that suits your project, don't pick some random dev board and then try to duct tape it with misc hardware to suit the project requirements.
However, the hardware is the easy part. Buying and configuring protocol stacks for whatever application protocols you are using is the hard and expensive part.
Also, there are lots of companies making gateways, so why re-invent the wheel. If you need to convert between for example Modbus and CANopen, these are both well-known industry standards. Consider just buying a gateway.
Currently I am studying about how exactly the bluetooth works and I came across the terms active and passive fingerprinting techniques. Could anybody explain these terms to me or give me some pointers to literature?
I don't know enough about Bluetooth to give a specific answer about fingerprinting it, however, your question seems general, so I'll try giving a general answer.
In general, passive techniques are techniques that don't require active participation in the network. So they can be done without sending packets or frames, just by listening. This means that passive techniques are very hard to detect, but are more limited.
In the case of Bluetooth, passive fingerprinting can probably be done by listening to beacon frames, or perhaps a conversation between two of more devices.
Active fingerprinting, on the other hand, requires you to send frames into the network, to device(s) being fingerprinted, and listening to the response(s).
I am confused between the following terms: OpenFlow, Open vSwitch, and Mininet. I want to understand the relationships between them. Kindly, can someone provide when and how to use each one of them?
Thank you.
Let me explain OpenFlow first. In traditional legacy network devices, the control decisions unit and the forwarding unit are tightly coupled (like switches, routers, etc., where both the control decisions like say, optimal route calculation and the forwarding occur in the same device). The hardware of these devices is made specifically for a particular task. They are not flexible enough to allow researchers to test new algorithms that they might come up with to solve any of the networking issues (say they have a better congestion-control algorithm for TCP!). This requires researchers to create their own custom hardware and have a whole new setup for each experiment.
It would be a lot better if commercial switch providers allowed more flexibility, thus allowing researchers to test their new idea on the same network without new hardware.
As per the white paper on OpenFlow, an OpenFlow switch allows this flexibility and OpenFlow is the protocol used to manage the switch (i.e., add/remove/modify flow entries, capture flow statistics, etc.,). The user program that uses OpenFlow to communicate with the OpenFlow switch is called the controller. There are various frameworks available for writing controller applications. Examples are Ryu are OpenDaylight.
SDN is based on this idea of de-coupling the control and forwarding unit (also called the data plane). Not only is this useful for researchers, but also for data centers, as it reduces the cost of changing hardware each time a change is required.
OpenVSwitch - The 'V' stand for Virtual. This is a "virtual" OpenFlow switch. Apart from OpenFlow, it also supports other switch management protocols.
Many people ask if an OpenFlow switch operates at layer 2 or layer 3. Note that there is no such concept here. In an OpenFlow switch, forwarding decisions can be taken based on MAC, IP, in-port, VLAN_ID, etc., So Please don't try to fit this into the OSI model.
Mininet is a network emulator. The user can create any kind of topology with multiple hosts and switches. The type of the switch could also be chosen.
OpenVSwitch is a software OpenFlow switch that can be controlled by a Controller
OpenFlow is the protocol through which your Controller communicates with its OpenFlow switch
Mininet is an emulator that emulates a network utilizing multiple instances of software switches
I am currently researching on SDN in mobile networks (LTE). for that i am looking for a simulator, need advise.
I have gone through NS3 and it appears as it supports Openflow Switches, but couldn't find documentation for that purpose. Need help in simulating SDN network in LTE. any suggestion/advise would be highly appreciated.
Thanks,
Shahzoob
NS-3 has a module called ofsoftswitch13 which might be quite helpful in your case. It implements controller entity as well as OF 13 protocol.
I did an undergraduate thesis on this topic and used Mininet and Ns-3 together using this project. We primarily did validity testing on this platform to determine it's accuracy and limitations (especially at scale). The wireless model is very good until a very clear performance degradation when the CPU usage reaches (100/n)% - where n is the number of available cores on the machine (for a single threaded implementation).
How exactly is isolation between data and control planes in sdn designed e.g when we assume that SDN is in a server?. And what about isolation in SDN switches between data and control ports?
SDN is a networking paradigm. A networking style. Before understanding SDN, we have to understand 2 things.
1.Data Plane: Data Path which actually forwards the packet or data from the input port to output port.
2.Control Plane: This has the logic of how to move the packet from input port to output port. Control Plane directs the data plane.
Pre SDN , the two planes data plane and control plane both were residing in the network devices like routers, switches, firewalls etc.
Now with SDN, the control plane and data plane has been separated i.e, Control Plane is moved out of the network devices and has been placed onto the central server. One SDN Controller can control many Network Elements. Granularity of the separation is left to the implementation.
To clarify SDN first imagine how traditional forwarding works
PC1 --- Router1 ----Router2-----Router3----PC2
For PC1 to reach PC2 it has to traverse through Router1, Router2 and Router3. Router 1 has information about its neighbors i.e router2. The same follows for other routers until it reaches PC2. If we observe the decision where to forward the packets is being taken by the routers at each step. The "Brain" is in the router which also acts as a device carrying the packets. This is analogous to our legs having its own brain to walk to a certain place.
In case of SDN the brain from each router is pulled up and put in one place. That is the controller or the control plane. Now the routers are just data/packets forwarding devices and hence are called switches in SDN. This is similar to how our brain works now. The brain decides how our legs and hands should move for us to reach a decision.
In SDN switch the switch talks to the control plane on virtual ports 6633 or 6653.
Hope this clarifies things.
Software Defined Network is a concept. When you say "when we assume that SDN is on a server?", I will say it's not a thing that you can just put somewhere, it's a concept. This concept is based on some explicit points. A good implementation of SDN will ensure the points below.
Control plane - data plane separation
Centralized point of control
Miscellaneous: network programmability, scalability etc.
When you try to look for isolation in the SDN concept, what you are basically looking for is point 1. Let me explain it a bit if that helps.
The major reason we started SDN was to bring in more robust and better programmability in the network. And one thing that was stopping us to do so is the distributed nature of network deployments. Bringing any change in network properties or behaviour required to explicitly go in and run some configurations in many router/switches in a deployment. That introduces all sorts of complexity and errors proneness.
For example, suppose we want packets from particular ip or ip mask to go through a special service function (e.g. firewall) which will decide the fate of the packet. Now, we will have to put this configuration into all the border routers or a group of devices that might receive the packet. In a big deployment, it can be a countless number of devices where we have to put this configuration to securely ensure the enforcement of the policy.
So, the idea of decoupling the network control from the data forwarding devices came along. This effectively means that we will have a dumb data forwarding service which can be controlled by a network controller or programmer. The data plane, which provides this data packet forwarding service, remains at router and switch level whereas the control plane might be and should be a separate physical entity. Conceptually, they are separated but it's not isolated.
One core benefit of SDN is that it enables the network control logic to be designed and operated on a global network view, as though it were a centralized application. Network control plane is thought to be a logically centralized application where we make the changes which will enforce our intended behaviour in the network.
In summary, what we basically do in SDN is, we take all those control-level business logic away from forwarding devices (means, physical and virtual switches and routers), and put them together in an application which we call controller and then we provide a way for the controller application to communicate and program changes in data plane forwarding devices. A good study to completely understand this architecture will be this: Understanding OpenFlow.
Long story short, isolation is a slightly wrong word to put between data plane and control plane. It's more like they were separated but dependent on each other. Without a control plane, forwarding devices are dumb, without the data plane, the control plane has nothing to control!
Hope this helped!
Conceptually, its not the implementation location that defines the separation(isolation), rather its because of the standard between control and data-plane (openflow for instance).
You can have both data and control planes on single server and they are separated as long as they talk through the standard interface.
The opposite case is also true, you can have control and data-plane physically separated, but if they are not through and standard interface, thats not SDN per se.
just go through ONF explanations:
https://www.opennetworking.org/software-defined-standards/overview/