Sdn architecture
SDN Architecture
SDN mainly consist of three components, that is the application layer, the data plane
also known as infrastructure layer, and the control plane. The application is mainly located
within the upper side, and contains several application logic and Northbound interfaces,
NBIs. The control plane exists within the middle, and contains NBIs, control-Data-planeinterfaces, CDPIs, and the control logic. On the other hand, the data plane is located in the
bottom of the design and contains several CDPIs and the forwarding engines. The NBIs aids
the application plane to communicate with the control plane, and sends down their network
needs to the controller whereas the control plane sends up the desired network behavior,
events, and statistics to offer application with abstract view of the entire networks.
Nevertheless, the CDPIs or southbound interface aid the network components that exists
within the infrastructure plane to communicate with the control plane. Also, the data layer
transfers its statistics, events, notifications, and reports up to the control layer, while, in turn,
the control layer sends down its network needs to the network components that exists within
the data layer, and the data plane obeys the stipulated rules of the control plane (). On the
other hand, the management and admin element are accountable for offering static tasks to all
the planes, which encompasses of the data plane, control plane, and application. Further, the
service agreement and contracts, SLAs, would be configured within the last element, that is,
the application plane. Lastly, the design has multiple coordinators, which are spread in the
control and data plane, which are responsible to set up the isolation and share configuration
between the control and data plane.
OpenFlow Switch
The OpenFlow switch is an example of data plane and provides an open protocol that
is the OpenFlow protocol, which aids the researchers in programming the flow table that exist
in the networking devices. The administrators can inserts their novel protocols and security
paradigm, also, they can add their addressing strategy rather than the present IP protocol
model. However, they could merely separate their research flows from the production flows,
to ensure they adopt and test their new concepts without interfering with others. The switch
entails three main segments, which are the flow table, OpenFlow protocol, and secure
channel. The switch contains several flow tables, and every flow table contains several flow
entries. Every entry within the table contains three fields, and the packet header is the initial
field, which identifies every flow. The header contains certain information like the ethernet
sources address, type of ethernet, ethernet destination address, TCP port number, IP source
address, TCP port number, and IP destination address. The action within the second field aids
the switch in addressing the received flow’s packets. Statistics in the third field, which keeps
information concerning the packets like number of packets, time since the last packet match
flow, and the number of bytes. Additionally, the secure channel is another section of the
switch, which assists instructions and packets to be send back and forth between the switch
and controller in a secure environment. the final segment is the OpenFlow, which provides an
open and standard path for controller to communicate with the switch.
There are primarily three forms of actions that can be executed by the switch, where
the fist action forwards a flow to a particular port to allow the packets reach their destination.
This situation is applicable when there are rules in the flow table regarding how to address
the received flow. The second action encapsulates and forwards merely the first package of
every flow to the controller via secure channel. This can only occur if there is no saved action
within the flow table concerning how to process that flow. The key reason for the
encapsulation and forwarding the initial packet for every flow towards the controller is to
essentially reduce the controller bottleneck of the overhead. In other case, all the packets in
every flow send to the controller for processing. After processing the flow within the
controller, response is sent and saved within the corresponding flow entry. The third action
essentially drops the flow, which is executed to significantly prevent attacks like the DDoS
attacks, or even to reduce the fake broadcast traffic from the end users. Lastly, these rules and
actions are installed by the controller within the data layer. Further, these actions can be
installed proactively by the controller that means on its accord. However, the controller can
select to install such actions reactively in line with the reports or notifications from switches
if there are no matches amid the incoming packets and existing rules.
Overview of DDoS Attack
…