List the similarities and differences between the IoT and M2M systems.

Similarities:
• Both M2M and IoT refer to the networking of machines or devices for purposes such as remote monitoring,
control, and data exchange.
• Both systems aim to computerise and control surrounding objects and provide access to data in real-time.
• Both can utilise similar underlying communication protocols at lower layers, such as ZigBee, Bluetooth, and
IEEE 802.15.4 for local area networks.
• Both involve devices with embedded hardware modules for sensing, actuation, and communication.
• Both have diverse application domains including smart metering, home automation, industrial automation,
and smart grids.
Differences:
1. Communication Protocols:
M2M: Primarily uses proprietary or non-IP-based communication protocols for communication within M2M area
networks. Examples include ZigBee, Bluetooth, ModBus, M-Bus, Wireless M-Bus, Power Line Communication (PLC),
6LoWPAN, IEEE 802.15.4, and Z-Wave. The focus is usually on protocols below the network layer. M2M gateways
perform protocol translations to enable IP-connectivity to remote M2M area networks.
IoT: Primarily focuses on IP-based communication protocols, especially those above the network layer. Examples
include HTTP, CoAP, WebSockets, MQTT, XMPP, DDS, and AMQP.

2. "Machines" in M2M vs. "Things" in IoT:

M2M: Typically features homogeneous machine types within an M2M area network.
IoT: Refers to "Things" as physical objects that have unique identifiers (like IP or MAC addresses) and can sense
and communicate with their external environment, user applications, or their internal physical states. IoT systems can
have heterogeneous things, meaning various types of IoT devices (e.g., fire alarms, door alarms, lighting control
devices in a home automation system).
3. Hardware vs. Software Emphasis:
M2M: Places more emphasis on hardware with embedded modules.
IoT: Places more emphasis on software. IoT devices run specialised software for sensor data collection, data analysis,
and interfacing with the cloud through IP-based communication.
4. Data Collection & Analysis:
M2M: Data is collected in point solutions and often stored in on-premises storage infrastructure. It is accessed by
on-premises applications like diagnosis and service management.
IoT: Data is collected in the cloud (public, private, or hybrid cloud). Analytics components in the cloud analyse the
data, and results are stored in cloud databases and visualised with cloud-based applications. Due to the massive scale
of data, cloud-based real-time and batch data analysis frameworks are employed. IoT also includes observer nodes that
process information from the cloud but do not perform control functions.
 5. System Architecture:
M2M: End-to-end architecture typically comprises M2M area networks, a communication network, and an application
domain. M2M gateways are crucial for enabling communication between remote M2M area networks by performing
protocol translations.

IoT: Emphasises a dynamic global network infrastructure with self-configuring capabilities, where physical and virtual
"things" are seamlessly integrated into information networks. The architecture heavily leverages cloud components for
data processing, storage, and application hosting.

Explain M2M system architecture and M2M gateway with neat diagram.
M2M System Architecture
Machine-to-Machine (M2M) refers to the networking of machines or devices for the purpose of remote monitoring,
control, and data exchange. The end-to-end architecture for M2M systems typically comprises three main domains:
1. M2M Area Networks: These networks consist of machines (or M2M nodes) that have embedded hardware
modules for sensing, actuation, and communication.
Devices within an M2M area network are connected locally and can communicate with each other for coordination,
such as robots on a factory floor exchanging status data or smart meters in a neighbourhood.
Communication within these local networks primarily uses proprietary or non-IP-based communication protocols,
such as ZigBee, Bluetooth, ModBus, M-Bus, Wireless M-Bus, Power Line Communication (PLC), 6LoWPAN, IEEE
802.15.4, and Z-Wave. The focus is usually on protocols below the network layer.
2. Communication Network: This network provides connectivity to remote M2M area networks.
It can utilise either wired (e.g., Ethernet, fibre optics, industrial LAN) or wireless networks (e.g., cellular
technologies like 3G, 4G, 5G, NB-IoT, LoRaWAN, satellite).
Crucially, the communication network primarily uses IP-based networks. Its purpose is to carry data reliably and
securely to application servers.
Since M2M area networks often use non-IP based protocols, M2M nodes within one network cannot directly
communicate with nodes in an external IP-based network. This is where M2M gateways become essential.
3. Application Domain: This is the final stage where collected M2M data is processed, stored, and analysed.
Applications can be point solutions like enterprise applications, service management applications, or remote
monitoring applications.
Functions include data storage (databases, servers), analytics (AI/ML for predictions, dashboards), and end-user
services (mobile apps, web dashboards, automation triggers).
M2M has various application domains such as smart metering, home automation, industrial automation, and smart
grids.

M2M Gateway: acts as a bridge between the M2M area network and the IP-based communication network (core
network).
Its key functions are:
Protocol Translation: The communication between M2M nodes and the M2M gateway uses protocols native to the
M2M area network. The M2M gateway performs protocol translations to enable IP-connectivity for M2M area
networks. It acts as a proxy, translating from/to native protocols to/from Internet Protocol (IP).
Virtualised Node Representation: With an M2M gateway, each node in an M2M area network appears as a virtualised
node for external M2M area networks. This allows external networks (which are IP-based) to communicate with
individual M2M devices that originally use non-IP protocols.
Data Aggregation, Security, and Filtering: Beyond translation, M2M gateways can also perform other crucial
functions such as aggregating data from multiple devices, implementing security measures, and filtering data.

What is Software Defined Networking (SDN)? Explain the SDN architecture with its key elements.
Software-Defined Networking (SDN) is a networking architecture that separates the control plane from the data
plane and centralises the network controller.
In conventional network architectures, the control plane which handles signalling and routing messages and the data
plane which carries payload data traffic are coupled within complex network devices such as switches and routers.
These traditional devices are often built with proprietary hardware and interfaces, leading to several limitations:
Complex Network Devices: They become increasingly complex due to the growing number of distributed protocols
implemented and the use of proprietary hardware, limiting interoperability and innovation. This complexity makes it
difficult to adapt to dynamic traffic patterns, especially for IoT applications deployed in cloud computing environments.
Management Overhead: Managing multiple network devices and interfaces from various vendors requires significant
manual configuration changes for upgrades, leading to considerable management overhead.
Limited Scalability: The increasing number of virtual hosts and distributed algorithms in cloud environments,
particularly for IoT applications, demands highly scalable and easy-to-manage network architectures. Conventional
networks struggle to meet these requirements with minimal manual configurations.
SDN attempts to overcome these limitations by creating network architectures that are simpler, inexpensive,
scalable, agile, and easy to manage. It achieves this by decoupling the control and data planes and centralising
the network controller. Software-based SDN controllers maintain a unified view of the network, simplifying
configuration, management, and provisioning. The underlying infrastructure in SDN uses simple packet forwarding
hardware, abstracting it from the applications, which allows network devices to be simpler and more cost-effective
as they receive instructions on packet forwarding directly from the SDN controller.
SDN Architecture and Key Elements
1. Centralized Network Controller: By decoupling the control and data planes and centralising the network
controller, network administrators can rapidly configure the network. This centralised controller maintains a
unified view of the entire network, enabling quicker deployment of SDN applications through programmable open
APIs, which in turn speeds up innovation as administrators no longer depend on device vendors for new features.
2. Programmable Open APIs: The SDN architecture supports programmable open APIs for the interface between
the SDN application and control layers, often referred to as the Northbound interface. These open APIs allow the
implementation of various network services, such as routing, quality of service (QoS), and access control.
3. Standard Communication Interface (OpenFlow): SDN architecture uses a standard communication interface
between the control and infrastructure layers, known as the Southbound interface. OpenFlow, defined by the
Open Networking Foundation (ONF), is the broadly accepted SDN protocol for this interface. OpenFlow allows
direct access and manipulation of the forwarding plane of network devices. It uses the concept of "flows" to identify
network traffic based on predefined match rules, which can be programmed statically or dynamically by the SDN
control software. An OpenFlow switch typically comprises one or more flow tables, a group table for packet
lookups and forwarding, and an OpenFlow channel to an external controller. The controller manages the switch by
adding, updating, and deleting flow entries in these tables. Each flow entry includes match fields, counters, and
instructions for processing matching packets.

Describe how Network Function Virtualization (NFV) can be used for virtualizing IoT device with neat diagram.
Network Function Virtualization (NFV) is a technology that leverages virtualisation to consolidate heterogeneous
network devices onto industry-standard high-volume servers, switches, and storage. While NFV is
complementary to SDN, providing the infrastructure on which SDN can run, they are mutually beneficial but not
dependent. NFV allows network functions, typically implemented in dedicated hardware, to be run as software on
virtualised resources in the cloud. This separation of network functions from the underlying hardware enables easier
testing and upgrading by simply installing new software, while the hardware remains the same. It also reduces
equipment costs and power consumption, and its multi-tenanted nature allows virtualised network functions to be
shared across multiple network services.
NFV Architecture and Key Elements
1. Virtualized Network Function (VNF): A VNF is a software implementation of a network function that is
capable of running over the NFV Infrastructure (NFVI). These are the actual network functions, such as routing,
DHCP server, Network Address Translation (NAT), or firewall functions, that are now implemented in software.
2. NFV Infrastructure (NFVI): The NFVI includes compute, network, and storage resources that are
virtualised. This is the hardware and virtualisation layer that provides the environment for VNFs to operate.
3. NFV Management and Orchestration: This component focuses on all virtualisation-specific management
tasks. It covers the orchestration and life-cycle management of physical and/or software resources supporting
the infrastructure virtualisation, as well as the life-cycle management of the VNFs themselves.
Virtualising IoT Devices with NFV (Example: Home Gateway)
NFV is applicable to both data plane and control plane functions in various networks, including home networks,
which are crucial for many IoT deployments.
In a conventional home network, a Home Gateway (a physical device) provides WAN connectivity to enable
services like Internet, IPTV, and VoIP. This physical gateway performs several network functions:
• Dynamic Host Configuration Protocol (DHCP) server: Assigns private IP addresses to connected devices in
the home.
• Network Address Translation (NAT): Translates private IP addresses of home devices to a single public IP
address for internet communication.
• Application-specific gateway: Provides specific routing for applications like VoIP and IPTV.
• Firewall: Protects the home network.
When NFV is applied to virtualise this Home Gateway, the physical device's functions are moved to a virtualised
environment in the cloud. The conventional physical Home Gateway is replaced by a virtualised version running
as a VNF on the NFVI.
Here's how this virtualisation works:
1. NFVI in the Cloud: Compute, network, and storage resources in the cloud form the NFVI.
2. Virtualized Home Gateway: The network functions previously performed by the physical Home Gateway
(DHCP, NAT, firewall, application-specific routing) are implemented in software as a Virtualized Network
Function (VNF). This VNF is then hosted and run on the NFVI in the cloud.
3. Connectivity for IoT Devices: Devices within the home (which could include various IoT devices) connect to
this virtualised gateway. The virtualised gateway provides private IP addresses to these home devices, just as a
physical gateway would. It also connects these devices to external network services like VoIP and IPTV.
This setup allows the core network functions for IoT devices within the home to be managed, scaled, and updated with
greater flexibility and efficiency from the cloud, rather than relying on a fixed, proprietary hardware box in the home.
Interaction Flow: Arrows would indicate the IoT devices in the home sending traffic to the simple network interface,
which then forwards it over the internet to the "Virtualized Home Gateway (VNF)" in the cloud. The VNF processes
this traffic and routes it to/from the appropriate external services, providing the necessary network functions for the
IoT devices. This effectively shows how the network functions for the IoT devices are no longer locally managed by a
physical gateway but are offloaded to a virtualised entity in the cloud.
Feature Software-Defined Networking (SDN) Network Function Virtualization (NFV)
Core Separates the control plane from the data plane Leverages virtualisation to consolidate
Concept/Focus and centralises the network controller. Aims to heterogeneous network devices onto
make networks simpler, inexpensive, scalable, industry-standard high-volume servers,
agile, and easy to manage by abstracting the switches, and storage. Its aim is to run network
underlying infrastructure from applications. functions (e.g., routing, firewall) as software on
virtualised resources in the cloud, replacing
dedicated hardware.
Architectural Has a three-layered architecture: Application Standardised by ETSI, it comprises Virtualized
Approach Layer, Control Layer (with a centralised SDN Network Functions (VNFs), NFV
controller), and Infrastructure Layer (simple Infrastructure (NFVI) (virtualised compute,
packet forwarding hardware). It uses network, and storage resources), and NFV
programmable Northbound APIs (between Management and Orchestration.
Application and Control Layers) and a standard
Southbound interface like OpenFlow (between
Control and Infrastructure Layers).
Problem Aims to solve the complexity of conventional Aims to reduce equipment costs, power
Addressed network devices, high management overhead due consumption, and increase flexibility by
to manual configurations, and limited scalability, allowing easier testing and upgrading of
especially for dynamic traffic patterns in cloud and network functions through software updates
IoT environments. It simplifies how the network is rather than hardware replacements. It simplifies
controlled and managed. how network functions are deployed.
Transformation Transforms network control by abstracting it into Transforms network functions by taking them
Emphasis software, making network devices simpler and out of proprietary hardware appliances and
more cost-effective as they primarily perform implementing them as software, allowing them
packet forwarding based on instructions from the to run on generic, off-the-shelf servers.
SDN controller.
Hardware vs. Emphasises software-based control and simpler, Focuses on virtualising network functions
Software Focus potentially generic, packet forwarding hardware. (traditionally hardware-based) into software that
runs on standard, high-volume hardware.
Relationship Complementary to NFV as it can provide the Complementary to SDN as it can provide the
programmable control over the virtualised infrastructure on which SDN can run. They are
infrastructure that NFV creates. They are mutually mutually beneficial but not dependent. Network
beneficial but not dependent. SDN can run without functions can be virtualised without SDN.
NFV.
Key Centralised Network Controller, Programmable Virtualized Network Function (VNF), NFV
Components Open APIs (Northbound), Standard Infrastructure (NFVI), NFV Management and
Communication Interface (Southbound, e.g., Orchestration.
OpenFlow).
Explain the need for IoT system management.
IoT systems can have complex software, hardware, and deployment designs, incorporating sensors, actuators, software,
and network resources, along with data collection and analysis services and user interfaces. Managing multiple
distributed IoT devices within a single system necessitates advanced management capabilities.
The need for managing IoT systems arises from several critical requirements: (6)
1. Automating Configuration: IoT system management capabilities are essential for automating system
configurations. This automation is particularly important in systems with multiple devices or nodes, as it ensures that
all devices have consistent configurations and helps avoid errors or variations that can arise from manual configuration.
2. Monitoring Operational & Statistical Data: Management systems play a vital role in monitoring operational
data (data related to the system's operating parameters collected at runtime) and statistical data (data describing system
performance, such as CPU and memory usage). This collected data is crucial for fault diagnosis or prognosis.
3. Improved Reliability: A robust management system enhances system reliability by allowing the validation of
system configurations before they are actively implemented.
4. System-Wide Configuration: For IoT systems composed of multiple devices or nodes, ensuring a system-wide
configuration is critical for correct functioning. Management approaches that configure each device separately can
lead to faults if devices run on inconsistent configurations (e.g., some on old, some on new). To prevent this, system-
wide configuration ensures that changes are applied to all devices in a single, atomic transaction ("all or nothing"
approach), with changes rolled back if any failure occurs.
5. Multiple System Configurations: Some IoT systems may require the ability to support multiple valid
configurations that can be applied at different times or under specific conditions.
6. Retrieving & Reusing Configurations: Management systems that can retrieve configurations from devices
facilitate the reuse of these configurations for other devices of the same type. This is particularly useful for ensuring
consistency when adding new devices that require the same configuration.
What is Simple Network Management Protocol? Explain managing a device with SNMP along with limitations
of SNMP.
The Simple Network Management Protocol (SNMP) is a widely used application-layer protocol designed for
monitoring, managing, and controlling devices on an IP network. These devices can include routers, switches,
servers, printers, and even IoT devices. SNMP enables a Network Management System (NMS) to communicate with
SNMP Agents that run on these managed devices, utilising a standard database known as the Management
Information Base (MIB). SNMP uses User Datagram Protocol (UDP) as its transport protocol.

Managing a Device with SNMP

Network Management Station (NMS): This is the central system, typically software or a tool used by a network
administrator. The NMS executes SNMP commands to monitor and configure the Managed Device. It sends requests
(such as GET or SET commands) and receives responses or unsolicited alerts called "Traps".
Managed Device: This refers to the network device (e.g., router, switch, printer, IoT device) that needs to be monitored
or controlled.
SNMP Agent: A software module that runs within the Managed Device. Its role is to collect information (like CPU
usage, interface status, or errors) from the device and communicate with the NMS using the SNMP protocol. It acts as
a bridge between the Management Information Base (MIB) and the NMS.
Management Information Base (MIB): This is a virtual database stored on the Managed Device. The MIB contains
structured information about the device's attributes that can be managed, defining what parameters can be monitored
or controlled (e.g., device uptime, number of packets transmitted). MIBs use the Structure of Management Information
(SMI) notation to define the structure of this management data. The data is organised in the form of variables, each
identified by a hierarchical Object Identifier (OID). Management applications can either get (read) or set (write) the
values of these variables.
How it Works:
1. The NMS sends a request (e.g., "Give me the system uptime") to the SNMP Agent on the Managed Device.
2. The SNMP Agent retrieves the requested data from the MIB.
3. The agent sends the response back to the NMS.
4. If a significant event occurs (e.g., an interface failure), the SNMP Agent can proactively send an unsolicited
Trap message to the NMS.
Limitations of SNMP
1. Stateless Nature: SNMP was designed as a simple management interface where each request is independent and
contains all necessary information to process it. The application (NMS) needs to be intelligent enough to maintain state
across a sequence of interactions and to handle rollbacks to a consistent state if errors occur during configuration.
2. Unreliability: SNMP is a connectionless protocol that uses UDP as its transport protocol. This makes it unreliable
because it does not inherently support acknowledgements for requests, meaning there's no guarantee that messages
reach their destination.
3. Lack of Writable Objects: MIBs often lack writable objects, which are necessary for configuring a device. Without
these, SNMP's utility is limited to device monitoring and status polling rather than active configuration.
4. Difficulty Differentiating Data: It is difficult to differentiate between configuration data and state data within
MIBs. This lack of clear separation hinders effective management.
5. Configuration Retrieval Issues: Retrieving the current configuration from a device can be difficult with SNMP,
as it does not easily support the retrieval and subsequent "playback" of configurations.
6. Security Concerns: Earlier versions of SNMP lacked strong security features, making management information
vulnerable to network intruders. While later versions added security, this significantly increased their complexity.
Discuss the following: i) NETCONF ii) YANG

i) Network Configuration Protocol (NETCONF)

NETCONF is a session-based network management protocol that serves to retrieve state or configuration data and
to manipulate configuration data on network devices.

Key Characteristics and Components:

Layered Architecture: NETCONF uses a layered architecture.
Transport Layer: NETCONF typically operates on the SSH transport protocol (Secure Shell Transport Layer
Protocol). This transport layer ensures end-to-end connectivity and reliable delivery of messages. Other transport
mappings, such as Blocks Extensible Exchange Protocol (BEEP), can also be supported.
Messaging: NETCONF uses XML-encoded Remote Procedure Calls (RPCs) for framing request and response
messages. The RPC layer provides the mechanism for encoding RPC calls and notifications.
Content Layer: This layer contains configuration and state data, which is XML-encoded. The schema for this data is
defined using the YANG modelling language.
Data Separation: NETCONF offers a clear separation between configuration and state data. For example, the <get-
config> operation retrieves configuration data only, while the <get> operation retrieves both configuration and state
data.
Configuration Datastores: A NETCONF server defines one or more configuration datastores. By default, a running
configuration store is present. Additional datastores, such as <startup> and <candidate>, can also be defined in the
capabilities.
Protocol Nature: NETCONF is a connection-oriented protocol, meaning the connection persists between protocol
operations. It relies on the transport protocol (like SSH or TLS) for authentication, data integrity, and confidentiality.
NETCONF overcomes limitations found in protocols like SNMP and is suitable for configuration management in
addition to monitoring state information.
ii) YANG
YANG (Yet Another Next Generation) is a data modelling language designed to model configuration and state data
manipulated specifically by the NETCONF protocol.
Key Aspects of YANG:
Module Content: YANG modules define the data exchanged between the NETCONF client and server. They contain
definitions for: Configuration data., State data., RPC calls that can be issued. & The format of notifications.
Data Structure: A YANG module is organized into a hierarchical tree structure. The data components are referred to
as 'leaf' nodes, which are specified using the 'leaf' or 'leaf-list' constructs. Leaf nodes can be organized using 'container'
or 'list' constructs.
Modelling Capabilities: YANG can model both configuration data and state data through the use of the 'config'
statement.
Modularity and Constraints: YANG modules can import definitions from other modules. Constraints, such as allowed
values, can be defined on the data nodes.
Operation Description
connect Connect to a NETCONF server
get Retrieve the running configuration and state information
get-config Retrieve all or a portion of a configuration datastore
edit-config Loads all or part of a specified configuration to the specified target configuration
copy-config Create or replace an entire target configuration datastore with a complete source configuration
delete-config Delete the contents of a configuration datastore
lock Lock a configuration datastore for exclusive edits by a client
unlock Release the lock on a configuration datastore
get-schema This operation is used to retrieve a schema from the NETCONF server
commit Commit the candidate configuration as the device’s new current configuration
close-session Gracefully terminate a NETCONF session
kill-session Forcefully terminate a NETCONF session
 Node Type Description
Leaf Nodes Contains simple data structures such as an integer or a string. Leaf has exactly one value of a
particular type and no child nodes.
Leaf-List Nodes Is a sequence of leaf nodes with exactly one value of a particular type per leaf.
Container Nodes Used to group related nodes in a subtree. A container has only child nodes and no value. A
container may contain any number of child nodes of any type (including leafs, lists, containers,
and leaf-lists).
List Nodes Defines a sequence of list entries. Each entry is like a structure or a record instance and is
uniquely identified by the values of its key leafs. A list can define multiple key leafs and may
contain any number of child nodes of any type.
Table 2: YANG Node Types

Describe the generic approach for IoT device management using NETCONF-YANG with a block diagram.

Management System: The operator uses this system to send NETCONF messages to configure the IoT device and
receives notifications and state information back via NETCONF messages.
Management API: This API allows management applications to perform functions programmatically, such as initiating
NETCONF sessions, reading and writing configuration data, reading state data, retrieving configurations, and invoking
RPCs.
Transaction Manager: Responsible for executing all NETCONF transactions. It ensures the ACID properties
(Atomicity, Consistency, Isolation, and Durability) hold true for these transactions.
Atomicity ensures a transaction is executed entirely or not at all.
Consistency ensures the transaction moves the device configuration from one valid state to another.
Isolation ensures concurrent transactions yield the same result as if executed serially.
Durability guarantees that a committed transaction persists.
Rollback Manager: This component is responsible for generating the necessary transactions to roll back a current
configuration to its original state.
Data Model Manager: Keeps track of all YANG data models and their corresponding managed objects. It also tracks
which applications provide data for each part of a data model.
Configuration Validator: Checks if the resulting configuration, after a transaction has been applied, would be valid.
Configuration Database: Stores both the configuration data and the operational data.
Configuration API: This API allows applications running on the IoT device to read configuration data from the
configuration datastore and write operational data to the operational datastore.
Data Provider API: Enables applications on the IoT device to register for callbacks related to various events and to
report operational data and statistics.
What is the difference between configuration and state data?

Feature Configuration Data State Data

Definition The set of writable data required to Data that is not configurable.
transform the system from its initial
state to its current state.
Contents Settings and parameters used to define Includes operational data collected by the system at
how the device should operate. runtime, and statistical data describing system
performance (e.g., CPU and memory usage).
Mutability Writable/Configurable. Read-only/Not configurable.
Management Goal Used to set and maintain the desired Used for fault diagnosis, prognosis, and monitoring
operational parameters. system performance.
It is a requirement for modern management solutions that it should be possible to fetch configuration and state data
separately from the managed device. In SNMP's MIBs, it is often difficult to differentiate between configuration and
state data, which is a limitation of SNMP. NETCONF, conversely, provides a clear separation of this data.
Explain the role of the OpenFlow protocol and flow tables in SDN.
OpenFlow serves as a standard communication interface between the control layer (the "brain" of the network) and the
infrastructure layer (the physical switches and routers). It is specifically categorised as a Southbound interface.
The primary roles of OpenFlow include:
• Direct Manipulation: It allows the centralised SDN controller to directly access and manipulate the forwarding plane
of network devices.
• Centralised Management: The controller uses the protocol to add, update, and delete flow entries within the switches,
allowing administrators to rapidly configure the network without waiting for proprietary vendor firmware updates.
• Traffic Identification: OpenFlow uses the concept of "flows" to identify network traffic based on pre-defined match
rules, which can be programmed either statically or dynamically by the SDN control software.

The Role of Flow Tables

A physical or virtual OpenFlow switch contains one or more flow tables, which act as the internal instruction manuals for handling
incoming packets. These tables are arranged in a pipeline, and matching typically starts at the first table.
Each flow entry within a table consists of three key components:
1. Match Fields: These are the criteria used to identify the packet, such as the ingress port, MAC addresses, IP addresses,
VLAN IDs, and TCP/UDP ports.
2. Actions: These define what the switch should do with a matching packet. Common actions include forwarding the
packet to a specific port, dropping the packet, or encapsulating and forwarding it to the controller for further instructions.
3. Stats: These are packet and byte counters that track the amount of traffic matching each rule, which is vital for
monitoring and analytics.
When a packet arrives at an OpenFlow switch, the switch looks up the packet's headers in its flow tables. If a match is found, the
switch executes the associated action and updates its counters. If no match is found, the switch may send the packet to the controller
over the OpenFlow channel to ask for new instructions on how to handle that specific flow.
How do SDN and NFV work together to benefit IoT systems?.
Infrastructure Synergy: NFV provides the virtualised infrastructure upon which SDN controllers and applications can run.
Centralised Management: While NFV replaces heterogeneous hardware devices with software running on standard high-volume
servers, SDN provides the centralised programmatic control needed to manage the traffic flowing through these virtualised
functions.
Dynamic Adaptation: Together, they allow network administrators to rapidly configure and scale the network to meet the
dynamic traffic patterns common in IoT applications, such as large-scale data exchanges between virtual machines for analytics.
Benefits for IoT Systems
1. Reduced Complexity and Costs: By moving network functions like firewalls and gateways into software (VNFs), NFV
reduces equipment costs and power consumption. SDN further reduces management overhead by abstracting the underlying
network infrastructure.
2. Scalability for Big Data: IoT systems involve massive scale data collection and analysis; the combined approach provides the
highly scalable architectures required to handle these volumes without the manual configuration limitations of conventional
networks.
3. Virtualised Home Gateways: NFV can be used to virtualise the Home Gateway in a smart home system. In this scenario, the
NFV infrastructure in the cloud hosts a virtual gateway that provides private IP addresses, security (firewalls), and specific routing
for home devices, which can then be managed programmatically.
4. Interoperability and Innovation: The use of programmable open APIs (Northbound interfaces) in SDN architecture allows
for the rapid deployment of new IoT services and features without waiting for proprietary hardware updates from vendors.
Why do network operators prefer NETCONF over SNMP for IoT management?.
Distinction Between Configuration and State Data: In SNMP, it is difficult to differentiate between configuration data (the
settings required to transform a system) and state data (the runtime status) within the Management Information Base. NETCONF
and YANG provide a clear separation between these two types of data, allowing operators to manage them independently.
Connection Reliability and Security: SNMP is a connectionless protocol that typically uses UDP, making it unreliable for
complex tasks as there is no built-in acknowledgement for requests. In contrast, NETCONF is a session-based protocol that
operates over connection-oriented transports like SSH, providing guaranteed delivery, data integrity, and confidentiality.
Transaction and Rollback Capabilities: SNMP is stateless; it requires the management application to be "intelligent" enough to
manually roll back a device to a consistent state if an error occurs during configuration. NETCONF supports atomic transactions,
meaning configuration changes are applied in an "all or nothing" fashion, and it includes a Rollback Manager to automatically
return a device to its original state if a transaction fails.
Multiple Configuration Sets: NETCONF allows for various configuration datastores, such as "running," "startup," and
"candidate". This allows operators to validate a candidate configuration before committing it to the active "running" state, a feature
SNMP does not support.
Network-Wide Management: While SNMP is often restricted to device-by-device status polling, NETCONF enables operators
to configure the network as a whole. It supports configuration transactions across multiple devices, which is critical for
maintaining consistency in large-scale IoT deployments.
Configuration Deltas and Validation: NETCONF allows for configuration deltas, which generate only the necessary operations
to move from one configuration state to another with minimal changes. It also provides a Configuration Validator to ensure that
any resulting configuration after a transaction remains valid.
Explain how NETCONF and YANG are used together for IoT system management.
NETCONF and YANG are used together as a robust framework for the management of IoT systems, addressing the limitations
of older protocols like SNMP by providing a more reliable and programmable approach to configuration.
The Role of YANG (The Data Model)
YANG is a data modelling language used to define the data structure that is manipulated by the NETCONF protocol.
• Structure: YANG modules provide a hierarchical tree-like definition of the configuration data, state data, and Remote
Procedure Calls (RPCs) that the system can execute.
• Node Types: It uses specific node types like leaf nodes (simple data items), container nodes (groups of related nodes),
and list nodes (sequences of entries) to organize information.
• Separation of Data: A key feature of YANG is its ability to separate configuration data (settings required to transform
the system) from state data (runtime statistics and status), allowing operators to manage them independently.
The Role of NETCONF (The Protocol)
NETCONF is a session-based network management protocol that provides the communication link between a management
system (the client) and the IoT device (the server).
• Secure Transport: It operates over secure connection-oriented protocols such as SSH or TLS, ensuring data integrity
and confidentiality.
• Configuration Datastores: NETCONF defines datastores like running, startup, and candidate, which allow operators to
validate and stage configurations before they are committed to the active system.
• Operations: It supports standard RPC methods, such as get-config to retrieve settings, edit-config to modify them, and
commit to apply a candidate configuration as the new active state.
How they work together in IoT Management
In a generic IoT management approach, these two technologies function as a single system to automate and secure the network.
1. Modelling: System designers first create a YANG model that defines exactly how the device can be configured and what
state data it should report.
2. Transaction Management: When an operator sends a configuration change via NETCONF, a Transaction Manager
ensures the operation follows ACID properties (Atomicity, Consistency, Isolation, and Durability).
3. Validation and Consistency: A Configuration Validator checks if the proposed changes are valid according to the
YANG model, and the Data Model Manager ensures the managed objects are updated correctly.
4. Rollback: If a configuration transaction fails across any part of the IoT network, a Rollback Manager automatically
returns all affected devices to their original consistent state, preventing partial or "broken" configurations.
5. Network-Wide Control: Unlike device-by-device polling, NETCONF allows for network-wide management, enabling
an operator to configure the entire IoT system as a single transaction.