SDN architecture understanding - sdn

I am very new to SDN and want to know just a basic understanding of it so that I can explain to some simple what it is. From what I know that the architecture is broken into the three layers. The infrastructure layer is just the switches and routers, and other devices that makes up a network. The controller layer maps how the devices are connected and how forwarding of packets should be sent from one device to another. For the controller layer to actually do the work in mapping and knowing how to forward the packets, the application layer provides the logic to do so and this is the layer where you create your network application in certain programming language like Python. Did I get a basic understanding of how SDN layers work?

We need to understand few terms before going to SDN.
Control Plane: The plane that determines where to send traffic
Data Plane: The plane that executes these decisions and forwards traffic
Management Plane: Element of a system that configures, monitors, and provides management, monitoring and configuration services to, all layers of the network stack and other parts of the system
Traditional Network Devices:
Control Plane, Management Plane and Data Plane reside on device itself.
Each device has its own brain and disconnected from each other and uses all sorts of protocols to stay connected.
Yet such protocols are complex and levels of resiliency to control action of such protocols also complex.
Think of traditional network as the type of network that is more prone to failure due to multiple disconnected brains not working together with one another.
SDN: (Decoupling hardware from Software)
SDN architecture is divided into 3 layers
Application Layer
Control Layer
Infrastructure Layer
Infrastructure Layer:
Consist of Network Devices which contains Data Plane and work on Open Flow Protocol or you can say uses Open Flow API to communicate.
Control Layer:
Consist of Control Plane and Management Plane.
Application Layer:
In this layer user can get an overview of Devices and see Topology.
Link between Application and Control Layer is generally called NorthBound Interface
Link between Control Layer and Infrastructure is called SouthBound Interface
Benefit of SDN:
Decoupling Control and Data planes involves leaving the data plane with network hardware and moving the control plane into a software layer.
By abstracting the network from the hardware, policies no longer have to be executed on the hardware itself.
Instead, the use of a centralized software application functioning as the control plane makes network virtualization possible.

You may find useful this: SDN Layer Architecture

Related

Classifying USB Protocol in the OSI Model

Im having a hard time Categorizing the USB Protocol in the layers of the OSI Model model.
Im guess there are 7 layers to begin with. These are the Informations i believe that corresponds to the layers:
7. Application (Software)
- Application specific
- Additional Drivers / Protocols
6. Presentation (Software)
- Application specific
- OS
5. Session (Software)
- Power mode regulation
- Configuration
4. Transport (Hardware)
- Split data into Frames
3. Network (Hardware)
- Client Adress 1 - 127
- Endpoints
2. Link (Hardware)
- CRC 5 Checksum for tokens
- CRC 16 Checksum for data packets
1. Physical (Hardware)
- Differential voltages (D-, D+)
- NRZI
- USB Plug
Is this correct so far?
How do hubs work? i believe they can "select" between clients just like an ethernet switch. doesn't that mean there the Master hast to send 2 addresses in every packet. One for the next immediate communication partner like Mac address and one for the Destination address like IP address ?
Maybe there are Usb Masters amongst us, who can send OUT Packages to this post, to help me out ;) I would be Very happy to send an ACK response :)
haha okay enough puns
When I taught these subjects, my students agreed with me that as they learned, and used, more precise words, it was easier for them to find answers to their questions. I could be wrong, but I think viewing USB through the OSI 7-layer model will be a little easier if you change "USB Protocol" to the more precise, USB specification.
The USB specifications include multiple protocols spread across multiple layers. The Physical layer includes specifications for things such as connectors, cables, power, and shielding.
The logical functions of USB protocols do not map perfectly onto the OSI model. Some protocols span two or three layers of the OSI model. But, it's possible to see which parts of which protocols fit in which layers. If the protocol is only concerned about signals between two nodes that are physically connected directly to each other, then it is the Data Link layer.
The Network layer is only about managing the bus when there are at least three nodes on the bus, such as identifying the nodes (addressing) and deciding where to send a packet (routing).
The Transport layer usually asks and answers the question, "Can you hear me now?" Or, you can think of it as analogous to using a ton of tracking numbers on the DHL website to track an order that has tons of packages. It is important between two nodes that are not directly physically connected to each other. The Data Link layer asks similar questions, but those questions are typically focused on individual signals (i.e., packets). The Transport layer does more sophisticated things such as putting packets in a specific order, dividing and combining packets, and tracking which packets in a set of packets were sent or received.
In USB, determining which node can use which part of the bus at what time is very important. Those protocols (mostly?) correspond to the Session layer.
I don't think any aspect of any USB specification corresponds with the Presentation or Application layers.
The USB-IF specification for USB4 includes their conceptual model for the USB functional stack. See section 2.2.1.
Good luck!
Hubs work on the First Layer. They just connect all the ports' pins together.

Example applications that use the OpenThread stack to communicate

I have been playing around with OpenThead for about a month and I have set up two TI CC2538s in an OpenThread network, currently, I can send pings between them and modify the network parameters using the CLI, but they aren't capable of much else.
I would like to develop an application for them that is capable of transmitting some form of data using the OpenThread stack, maybe something simple at first like transmitting a block of text, however, I am not really sure where to start with this, are there any example applications that I could use as a starting point?
For application layers that sit directly on top of OpenThread, Nordic has released some examples in their nRF5 SDK for Thread.
Also note that Thread (and OpenThread) implement an IPv6 link capable of transporting vanilla IPv6 datagrams. As a result, you could run other transport protocols like TCP. However, UDP is often recommended due to relatively high loss rates and latency variance that is common to low-power, wireless mesh networks.

Isolation in SDN planes

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/

Need some explanation about Software-defined networking (SDN)

Can anyone give me an example of data plane and control plane in the 'traditional' model i.e when SDN does not apply.
I understand how SDN works, but I don't really know about the traditional model.
In SDN, the data plane and control plane are divided, so how are the data plane and control planes organized in the 'traditional' model?
In a traditional network device, the Control Plane has the L3 route processor and the L2 switch processor CPUs, which “control” the packet or data flow. Some of the different packets the control plane handles are a variety of traffic, including BPDUs, routing updates, HSRP, CDP, CEF, process-switched packets, ARP, and management traffic such as SSH, SNMP, RADIUS. All of these are processed by the router or switch’s control plane. The Data Plane (or Forwarding Plane) deals with anything that goes “through” the router/switch and not “to” the router/switch. As you can imagine there are many vendors each with their own flavor of how to best control the logic of the decision making, and also how to best handle packet flow and throughput. But the common factor here is that both the control and data planes exist on the same device, as opposed to being decoupled from each other as in SDN.
Well, first off, this is what i understand so far.
Data and Control Plane. Lets talk about traditional networking. You have multiple routers linked together. Now the routing is not static i.e. there is no fixed path to reach one computer to another in the world. The path keeps on changing depending on various parameters like hop counts / congestion / etc. So how is this dynamic nature achieved? There are routing algorithms and other mechanisms at play which decide which path to choose. Now all this decision making process form the control plane. The "brain" part in router that sends/receives packets destined for INTERMEDIATE ROUTERS ONLY and not some terminal computer connected to Internet form the control plane.
As for data plane that is actually what forwards / routes the packet to the dynamic path.
So simply put, in a traditional switch/router, the propreitory software LOCAL TO EACH ROUTER / SWITCH which is deciding the routing decision and FILLING the Switch/Router forwarding table forms the Control Plane and the FORWARDING TABLES ENTRIES ITSELF would be the data plane.
Let's say you and I are in charge of public transportation for a small city.
Before we send bus drivers out, we need to have a plan.
Control Plane = Learning what we will do
Our planning stage, which includes learning which paths the buses will take, is similar to the control plane in the network. We haven't picked up people yet, nor have we dropped them off, but we do know the paths and stops due to our plan. The control plane is primarily about the learning of routes.
In a routed network, this planning and learning can be done through static routes, where we train the router about remote networks, and how to get there. We also can use dynamic routing protocols, like RIP, OSPF and EIGRP to allow the routers to train each other regarding how to reach remote networks. This is all the control plane.
Data Plane = Actualy moving the packets based on what we learned.
Now, after the routers know how to route for remote networks, along comes a customers packet and BAM! this is were the data plane begins. The data plane is the actual movement of the customers data packets over the transit path. (We learned the path to use in the control plane stage earlier).
Let's say you and I are in charge of public transportation for a small city.
Before we send bus drivers out, we need to have a plan.
Control Plane = Learning what we will do
Our planning stage, which includes learning which paths the buses will take, is similar to the control plane in the network. We haven't picked up people yet, nor have we dropped them off, but we do know the paths and stops due to our plan. The control plane is primarily about the learning of routes.
In a routed network, this planning and learning can be done through static routes, where we train the router about remote networks, and how to get there. We also can use dynamic routing protocols, like RIP, OSPF and EIGRP to allow the routers to train each other regarding how to reach remote networks. This is all the control plane.
Data Plane = Actualy moving the packets based on what we learned.
Now, after the routers know how to route for remote networks, along comes a customers packet and BAM! this is were the data plane begins. The data plane is the actual movement of the customers data packets over the transit path. (We learned the path to use in the control plane stage earlier).

Where does VISA go on the OSI stack?

I am looking at putting together a communications protocol for an embedded application, but I don't know much about high-level communications such as TCP/IP, etc. I'm more used to dealing with bits and bytes on I²C and SPI, etc.
Someone has suggested that I use a VISA (virtual instrument software architecture) I/O API with SCPI (standard commands for programmable instruments) command syntax. What layer would these sit at on the OSI model? I'm thinking VISA would be application and SCPI presentation?
Someone else has suggested using SSH, again as I'm not sure what layer VISA/SCPI sits at, I don't know how SSH would affect the design.
Since you're basically just using the network to pass data between a hardware API and an application, you're on layer 7(application) of the OSI stack.