Introduction to IoT Week-7: SUMMARY

As Week 7 of our 12-week NPTEL Introduction to IoT series comes to a close, we’re diving deeper into the world of IoT. Real-world applications, trends, and the importance of data analytics have been in focus. With each passing week, we’re gaining practical knowledge that will serve us well on this journey.

Network protocols allow us to establish connections between servers and clients, enabling data transmission from clients to servers. Socket programming, in particular, plays a crucial role in creating two-way communication between these network nodes.

Here’s how it works:

• We create both a server and a client.
• A connection is established between these two nodes.
• The client sends data to the server.

To kickstart this process, we initiate socket creation using the following syntax: s = socket.socket(SocketFamily, SocketType, Protocol=0)

• SocketFamily can be either AF_UNIX or AF_INET.
• SocketType can take on values SOCK_STREAM or SOCK_DGRAM.
• The Protocol parameter is set to 0 by default.

Data Processing: Data splitting/filtering
▪ Data from the client is saved in a text file
▪ The values are separated by a comma(‘ , ’)

message = str(h)+’,’+str(t)

▪ Split() function can be used to split a string into multiple strings depending on the type of separator/delimiter specified.

Plotting the data:
▪ MATPLOTLIB is a Python library used to plot in 2D
▪ Plot(x,y): plots the values x and y
▪ xlabel(‘X Axis’): Labels the x-axis
▪ ylabel(‘Y Axis’): Labels the y-axis
▪ title(“Simple Plot”): Adds title to the plot

import matplotlib.pyplot as myplot
myplot.plot([1,2,3,4])
myplot.ylabel(‘Y-Axis’)
myplot.show()

By default the values are taken for the y-axis, and values for the x-axis are
generated automatically starting from 0 to 9

Functions Used in Plotting Data:
Some other common functions used in plotting:
▪ figure(): Creates a new figure
▪ grid(): Enable or disable axis grids in the plot
▪ ion(): turns on the interactive mode
▪ subplot(): Adds subplot in a figure
▪ Close(): Close the current figure window
▪ Scatter(): make a scatter plot of the given points

Limitations of the current Network:
1. Vendor-specific architecture of switches limits dynamic configuration according to application-specific requirements.
2. Switches are required to be configured according to the installed operating system (OS).
3. Centralized control is not feasible in a traditional network.

Origin of Software Defined Networking: The origin of Software Defined Networking (SDN) can be traced back to several key milestones. In 2006, a team at Stanford University introduced the concept of a clean-slate security architecture called SANE, which proposed controlling security policies in a centralized manner instead of at the network edges. SDN’s inception was significantly influenced by the OpenFlow project, which emerged in 2008, and further developments took place.

In 2009, Stanford University published OpenFlow V1.0.0 specifications, and the foundation for SDN began to take shape. Nicira Networks was founded in June 2009, adding to the growing interest in SDN. In March 2011, the Open Networking Foundation was established to promote SDN. Later, in October 2011, the first Open Networking Summit attracted industries like Juniper and Cisco, who announced plans to incorporate SDN into their architectures.

Basic Concept of SDN: The fundamental concept of SDN involves separating control logic from hardware switches, centralizing the definition of control logic, enabling control over the entire network, and facilitating communication between applications, control, and data planes through APIs. Key components and attributes of SDN include hardware switches, controllers, applications, flow rules, and application programming interfaces (APIs).

Currently, companies such as Google have begun implementing SDN in their data center networks, often through phased transitions that promise reduced operational costs and minimized delays resulting from link failures. However, SDN also faces challenges, particularly in areas like rule placement and controller placement, as it continues to evolve and shape the future of networking.

Rule Placement: Rule placement is a critical aspect of Software Defined Networking (SDN) which switches forward network traffic based on predefined rules known as ‘Flow-Rules.’ Unlike traditional networks where routing tables are employed in each switch, SDN uses a Flow Table in every switch, with each entry in the Flow Table being referred to as a Flow-Rule. These rules follow specific formats, often dictated by protocols like OpenFlow.

Challenges of Rule Placement: The first challenge lies in the size limitation of ternary content-addressable memory (TCAM) at the switches, which restricts the number of rules that can be inserted. TCAM is essential for rapid processing but comes at a considerable cost. The second challenge emerges when a switch receives a request for which no matching flow rule is present. In this scenario, the switch sends a PACKET-IN message to the centralized controller, which then determines a suitable flow rule and inserts it into the switch. This process typically incurs a delay of 3–5 milliseconds for new rule placement.

Addressing these challenges requires a focus on defining and placing rules at switches while considering available TCAM and designing rules to minimize the number of PACKET-IN messages sent to the controller. Balancing these aspects is crucial for optimizing rule placement in SDN and ensuring efficient network operation.

Open Flow Control: The OpenFlow Protocol is the primary protocol employed for rule placement in Software Defined Networking (SDN). It offers various versions, such as 1.0, 1.1, 1.2, 1.3, and more, each supporting a different number of match fields, including Source IP, Destination IP, Source Port, Priority, and others.

OpenFlow also allows for specifying the duration for which a flow rule should be kept at a switch, known as timeouts. The two types of timeouts include hard timeouts, which involve deleting all rules from the switch when the timer expires, and soft timeouts, which delete a rule when no flow is associated with it for a certain period, essentially clearing unused rules.

It’s essential to clarify that SDN, or Software Defined Networking, is a broader technology and concept, while OpenFlow is the specific protocol used for communication between the data plane and the control plane. While other protocols for this purpose may exist, OpenFlow is the primary protocol currently in use.

OpenFlow Switch Software: OpenFlow is supported by various OpenFlow Switch Software, including Indigo, LINC, Pantou, Of13softswitch, and the highly popular Open vSwitch.

APIs In SDN: SDN utilizes different types of APIs, including the Southbound API used for communication between the control layer and infrastructure layer, typically through the OpenFlow protocol. The Northbound API facilitates communication between the control layer and application layer, using standard APIs, while East-Westbound APIs support communication among multiple controllers within the control layer.

Controller Placement: When it comes to controller placement in SDN, it is crucial to ensure that controllers can efficiently define flow rules according to application-specific requirements, handle incoming requests from switches without significant delays, and maintain the network’s responsiveness. Controllers should be logically connected to switches within one-hop distance, even though they may be physically located at a multi-hop distance. The number and distribution of controllers are essential considerations to prevent network congestion with control packets like PACKET-IN messages.

Control Mechanism: Control mechanisms in Software Defined Networking (SDN) are categorized into two approaches: Distributed and Centralized. Distributed control involves decentralized decision-making, with each subnetwork managed by a different controller. In contrast, Centralized control makes decisions in a centralized manner, with a single controller managing the entire network. The choice depends on network requirements and design.

Backup Controller: To ensure reliability, a Backup Controller acts as a replica of the main controller. In case of failure, the backup controller takes over for uninterrupted network management.

Security using SDN: SDN enhances security with features like firewalls, proxies, HTTP, and intrusion detection systems (IDS).

Experimentation with SDN is done through simulators and emulators, enabling SDN configuration testing. Infrastructure must support OpenFlow, and controllers can be placed remotely or locally based on needs.

Switch Deployment utilizes tools like Mininet, creating a virtual network with OpenFlow-enabled switches, supported in Python. Controllers can be configured using software tools like Pox, Nox, FloodLight, OpenDayLight, or ONOS for effective SDN network management.

Benefits of Integrating SDN in IoT: Integrating SDN into IoT brings notable benefits, including intelligent routing, streamlined operations for information processing, enhanced visibility of network resources tailored to user, device, and application needs, and the capability for intelligent traffic analysis and coordinated decision-making within IoT networks.

Challenges of Integrating SDN in IoT: Integrating SDN into IoT presents several challenges, including the need for real-time programming of sensor nodes, compatibility issues with vendor-specific architectures, resource constraints that limit heavy computation, and restricted memory capacities that limit the insertion of control programs. These challenges must be addressed to realize the full potential of SDN in IoT applications.

Software Defined Wireless Sensor Networks (WSN): It offers innovative capabilities such as value-centric and ID-centric data forwarding, enabling data transmission based on specific criteria like data value or source node ID. Soft-WSN, a notable system in this context, provides comprehensive sensor device management, allowing multiple sensors on a single board and dynamic adjustments for sensing delay and active sleep modes. Furthermore, Soft-WSN empowers topology management, enabling node-specific and network-specific control over data forwarding, enhancing the adaptability and efficiency of WSNs.

That’s all for Week 7. Week 8 promises even more intriguing insights as our adventure continues. Your engagement is highly valued, so please share your thoughts and be part of our growing community. Thank you for joining us on this learning journey. Stay tuned for what lies ahead in Week 8!