Module - 3

Dr. Bivas Ranjan Parida

Silicon University
 M2M
• Called as Machine-to-Machine applications (or aptly
known as Mobile-to-Machine or Machine-to-Mobile)
• Emerging area in the field of telecom technologies.
• M2M allows a wide variety of machines to become
nodes of personal wireless networks, and provides to
develop monitoring and remote control applications.
• Decrease costs for involved human resources
• Makes machines more intelligent and autonomous.
M2M
M2M
M2M
M2M
 M2M
• Machine-to-Machine (M2M) refers to networking of
machines(or devices) for the purpose of remote
monitoring, control and data exchange.
 M2M Architecture
• An M2M area network comprises of machines(or M2M
nodes) that have embedded hardware modules for
sensing, actuation and communication.
• Various communication protocols can be used for M2M
local area networks such as ZigBee, Bluetooth, ModBus,
M-Bus, Wireless M-Bus, Power Line
Communication(PLC), 6LoWPAN, IEEE 802.15.4, etc.
• These communication protocols provide connectivity
between M2M nodes within an M2M area network.
• The communication network provides connectivity to
remote M2M area networks.
 M2M Architecture
• The communication network can use either wired or
wireless networks(IP-based).
• While the M2M area networks use either proprietary
or non-IP based communication protocols, the
communication network use IP-based networks.
 M2M Gateway
• Since non-IP based protocols are used within M2M
area networks, the M2M nodes within one network
cannot communicate with nodes in an external
network.
• To enable the communication between remote M2M
area networks, M2M gateways are used.
M2M Gateway
 M2M Gateway
• The communication between the M2M nodes and the
M2M gateway is based on the communication
protocols which are native to the M2M area network.
• M2M gateway performs protocol translations to
enable IP-connectivity for M2M area networks.
• M2M gateway acts as a proxy performing translations
from/to native protocols to/from Internet
Protocol(IP).
• With an M2M gateway, each node in an M2M area
network appears as a virtualized node for external
M2M area network.
 M2M Wireless Architecture
• M2M wireless architecture consists of : Applications,
Communication Network, M2M Area Network
 Capillary Network
• The sensors, communication and processing units act
as endpoints of M2M applications and together
constitute the capillary network.
• The devices shall interconnect amongst themselves
over various PAN and LAN technologies in both
Wireless and Wired domain.
• Their primary components are sensors, processors,
and radio transceivers.
• The primary WPAN technology enablers in this space
are ZigBee and Bluetooth.
 Capillary Network
• The sensors also known as smart nodes form
Bluetooth piconets or ZigBee networks used for
coordination and transmission of the collected data to
the Gateway
 M2M Gateways
• The Gateway module provides control and
localization services for data collection.
• It supports Bluetooth, Zig Bee, GPRS capabilities.
• It supports wireless communication standards like
GSM/GPRS, IEEE 802.11, Bluetooth/IEEE 802.15.1,
ZigBee/IEEE 802.15.4
 Applications
• M2M applications may either target at end users, such
as user of a specific M2M solution, or at other
application providers.
• These application offers more refined building blocks
by which they can build more sophisticated M2M
solutions and services.
 Applications of M2M
• The M2M data is gathered into point solutions such
as enterprise applications, service management
applications or remote monitoring applications.
• M2M has various applications domains such as smart
metering, home automation, industrial automation,
fleet tracking, security and surveillance , etc.
 Difference between M2M and IoT
• Communication Protocols:
M2M uses either proprietary or non-IP based
communication protocols for communication
within the M2M area networks.
M2M protocols include ZigBee, Bluetooth,
ModBus, M-Bus, 6LoWPAN, IEEE 802.15.4 etc.,
whereas IoT protocols include HTTP, CoAP,
WebSockets, MQTT, XMPP, AMQP, DDS, etc.
The focus of communication in M2M is usually on
the protocols below the network layer, whereas
IoT focuses usually on the protocols above the
network layer.
Communication in IoT vs M2M
 M2M vs IoT
• Machines in M2M vs Things in IoT:
 The “Things” in IoT refers to physical objects that
have unique identifiers which can sense and
communicate with their external environment or their
internal physical states.
The unique identifiers for the things in IoT are IP
addresses or MAC addresses.
IoT Systems have heterogeneous things.
Things have software components for accessing,
processing and storing sensor information or
controlling actuators.
 M2M systems typically have homogeneous machine
types within an M2M area network.
 M2M vs IoT
• Hardware vs Software Emphasis:
 The emphasis of M2M is more on hardware with
embedded modules.
 The emphasis of IoT is more on software.
 IoT devices run specialized software for sensor
data collection, data analysis and interfacing with
the cloud through IP based communication.
Contd..
 M2M vs IoT
• Data Collection & Analysis:
 M2M data is collected in point solutions and often on-
premises storage infrastructure.
 IoT data is collected in the cloud(public, private, or
hybrid cloud). The analytics component analyzes the
data and stores the results in the cloud database.
The IoT data and analysis results are visualized
with the cloud based applications.
The centralized controller is aware of the status of
all the end nodes and sends control commands to
the nodes.
Contd..
 M2M vs IoT
• Applications:
 M2M data is collected in point solutions and can be
accessed by on-premises applications such as
diagnosis applications, service management
applications and on-premises enterprise applications.
 IoT data is collected in the cloud and can be accessed
by cloud applications such as analytic applications,
enterprise applications etc.
As there is massive scale of data collected in IoT
systems, cloud-based real-time and batch data
analysis frameworks are used for data analysis.
 SDN & NFV
Dr. Bivas Ranjan Parida

27
 Software Defined Networking (SDN)
Definition:
A Software-Defined Network (SDN) is a network
architecture approach that separates the control plane
from the data plane, allowing for more flexible and
programmable network management. In traditional
networks, both the control plane (which decides how
data should flow) and the data plane (which forwards
the data packets) are tightly coupled in network devices
(such as routers and switches). SDN decouples these
functions, enabling centralized control and more
efficient network management.
28
 Network Architecture
• The control plane, the data plane and the management
plane are the three basic components of a network or
telecommunications architecture.
Control Plane:
In network routing, the control plane is
concerned with drawing the network topology, or
the information in a routing table that defines what
to do with incoming packets.
The control plane participates in routing protocols.

29
 Network Architecture
The routing table contains a list of destination
addresses and the outgoing interface associated
with them.
Control plane logic also can define certain packets
to be discarded.
Control packets originate from or are destined for a
router.
Management Plane:
 The management plane carries administrative
traffic, is considered a subset of the control plane.

30
 Network Architecture
Data Plane:
 The control plane and management plane serve the data
plane, which bears the traffic that the network exists to
carry.
 The data plane sometimes known as the user plane,
forwarding plane, carrier plane or bearer plane.
 It defines the part of the router architecture that decides
what to do with packets arriving on an inbound interface.
 Mostly, it refers to a table in which the router looks up the
destination address of the incoming packet and retrieves
the information necessary to determine the path from the
receiving element.

31
 Conventional Network Architecture
• Conventional network architectures built with specialized
hardware (switches, routers etc).
• Network device in conventional network architectures are
getting exceedingly complex
• with the increasing number of distributed protocols
being implemented
• use of proprietary hardware and interfaces.
• The control plane and data plane are coupled.
• Control plane is the part of the network that carries the
signaling and routing message traffic while the data
plane is the part of the network that carries the
payload data traffic.

32
Conventional Network Architecture

33
OSPF (Open Shortest Path First) is a router protocol used to find the best
path for packets as they pass through a set of connected networks.
34
35
 Limitations of Conventional Architectures

• Complex Network Devices:

 Conventional networks are getting increasingly
complex.
 Interoperability is limited due to the lack of
standard and open interfaces.
 Well suited for static traffic patterns and had large
number of protocols designed for specific
applications.
 Difficulty in managing the complex traffic.

36
Limitations of Conventional Architectures

• Management overhead:
 Conventional networks involves significant
overhead.
 Upgradation of network requires configuration
changes in multiple devices

37
 Limitations of Conventional Architectures
• Limited Scalability:
 Increase number of virtual hosts requiring network
access. IoT applications hosted in the cloud are
distributed across multiple virtual machines that
requires exchange of traffic.
 The analytic components of IoT applications run
distributed algorithms.
 Computing environments require highly scalable
and easy to manage network architectures with
minimal manual configurations

38
39
40
41
42
 SDN Architectures
• SDN attempts to create network architectures that are
simpler, inexpensive, scalable, agile and easy to
manage.
• SDN architectures and layers in which the control and
data plane are decoupled and network controller is
centralized.
• Software SDN controllers maintain unified view of
the network and make configuration, management
and provisioning simpler.
• The underlying infrastructure in SDN uses simple
packet forwarding hardware as opposed to
specialized hardware in conventional networks.
43
SDN Architectures

44
 SDN Architectures
• The underlying infrastructure is abstracted from the
applications.
• Network devices becomes simple with SDN as they
do not require implementation of a large number of
protocols.
• Network devices receive instructions from the SDN
controllers on how to forward the packets. These
packets can be simpler and cost-less as they can be
built from standard hardware and software
components.

45
SDN

46
 SDN Northbound API
 Software-defined northbound application program
interfaces are usually SDN RESTful APIs used to
communicate between the SDN Controller and the
services and applications running over the
network.
 These APIs can be used to facilitate efficient
orchestration and automation of the network to align
with the needs of different applications via SDN
network programmability.

47
 Working of Northbound API
• Northbound APIs are the link between the applications
and the SDN controller.
• The applications can tell the network what they need
(data, storage, bandwidth, and so on)
• The network can deliver those resources, or communicate
what it has to the specific destination.
• Examples of the types of network applications that can be
optimized via the northbound interface include load
balancers, firewalls, or other software-defined
security services, or orchestration applications
across cloud resources.

48
 SDN SouthBound API
• Software-defined southbound application program
interfaces are used to communicate between the SDN
Controller and the switches and routers of the
network.
• They can be open-source or proprietary.

49
 Working of SouthBound API
• Southbound APIs facilitate control over the network
and enable the SDN Controller to dynamically make
changes according to real-time demands and needs.
• OpenFlow, which was developed by the Open
Networking Foundation (ONF), is the first and
probably most well-known southbound interface.
• Example: The Network Configuration Protocol
(NetConf) uses an Extensible Markup Language
(XML) to communicate with the switches and routers
to install and make configuration changes

50
SDN Layers

51
 Key elements/ benefits of SDN
• Centralized Network Controller
– With decoupled control and data planes and
centralized network controller, the network
administrators can rapidly configure the network,
providing a global view of the network.
– SDN applications can be deployed through
programmable open APIs.

52
 Key elements/ benefits of SDN
• Programmable Open APIs
– SDN architecture supports programmable open
APIs for interface between the SDN application
and control layers (Northbound interface).
– With these OpenAPIs various network services can
be implemented such as routing, Quality of
Service(QoS), access control etc.
– Network behavior can be programmed and
dynamically adjusted in real-time based on
changing conditions, business needs, or traffic
patterns.
53
 Key elements/ benefits of SDN
• Standard Communication Interface (OpenFlow)
• SDN architecture uses a standard communication
interface between the control and infrastructure layers
(Southbound interface).
• OpenFlow, which is defined by the Open Networking
Foundation (ONF) is the broadly accepted SDN
protocol for the Southbound interface.

54
 Key elements/ benefits of SDN
• Agility and Flexibility: The network can be easily
reconfigured without needing to physically modify
hardware, making it highly adaptable to changing
requirements.
• Improved Automation: SDN allows for more automated
provisioning and management, reducing the need for
manual intervention and minimizing human error.
• Cost Efficiency: By decoupling the control and data
planes, SDN enables the use of commodity hardware,
reducing hardware costs and simplifying network
management.

55
 OpenFlow
• With OpenFlow, the forwarding plane of network devices
can be directly accessed and manipulated.
• OpenFlow uses the concept of flows to identify network
traffic based on predefined match rules.
• Flows can be programmed statically or dynamically by
SDN controllers software.
• The components of an OpenFlow switch comprising of
one or more flow tables and a group table, that perform
packet lookup and forwarding, and OpenFlow channel to
an external flow controller.
• OpenFlow protocol is implemented on both sides of the
interface between the controller and network devices.

56
OpenFlow Switch

57
 OpenFlow
• The controller manages the switch via the OpenFlow
switch protocols.
• The controller can add, update, delete flow entries
and flow tables.
• OpenFlow Flow Table
• Each flow table contains a set of flow entries.
• Each flow entries consists of match fields, counters,
and a set of instructions to apply to matching packet.
• Matching starts at the first flow table and may
continue to additional flow tables of the pipeline.

58
OpenFlow flow table

59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
Network Function Virtualization(NFV)
• NFV is the technology that leverages virtualization to
consolidate the heterogeneous network devices onto
industry, standard high volume servers, switches and
storage.
• NFV is complementary to SDN as a NFV can provide
the infrastructure on which SDN can run.
• NFV and SDN are mutually beneficial to each other
but not dependent.
• Network functions can be virtualized without SDN.
• Similarly SDN can run without NFV.

75
NFV Architecture

76
 Key elements of NFV architecture
• Virtualized Network Function: VNF is software
implementation of a network function which is
capable of running over NFV infrastructure(NFVI).
• NFV Infrastructure: NFVI includes compute,
network and storage resources that are virtualized.
• Virtualization Layer: Virtualization uses software to
create an abstraction layer over computer hardware
that allows the hardware elements of a single
computer such as processors, memory, storage and so
on to be divided into multiple virtual computers,
commonly called virtual machines (VMs).
77
 Key elements of NFV architecture
• Each VM runs its own operating system (OS) and
behaves like an independent computer, even though it
is running on just a portion of the actual underlying
computer hardware.
• It follows that virtualization enables more efficient
utilization of physical computer hardware and allows
a greater return on an organization’s hardware
investment.

78
 Key elements of NFV architecture
• NFV Management and Orchestration: NFV
management and orchestration focuses on:
• All virtualization-specific management tasks
• Covers the orchestration and lifecycle management
of physical and /or software resource that supports
infrastructure virtualization and the lifecycle
management of VNFs.

79
 Home network with Virtualized Home
Gateway
• NFV can be used for virtualization of the Home networks.
• Using NFV, a home gateway provides Wide Area
Network(WAN) connectivity to enable services such as
internet IPTV, VoIP etc.
• The NFV infrastructure in the cloud hosts a virtualized
Home Gateway.
• The Home Gateway performs various functions including
Dynamic Host Configuration Protocol (DHCP) server,
Network Address Translation(NAT), application specific
gateway and firewall.

80
 Home network with Virtualized Home
Gateway
• The virtualized gateway provides private IP addresses
to each connected device in the home.
• The Home Gateway provides routing capabilities and
translates the private IP addresses to one public
address(NAT function).
• The virtualized gateway also connects to network
services such as VoIP and IPTV.

81
Home network with Virtualized Home
Gateway

82
IoT System Management

Dr. Bivas Ranjan Parida

 IoT System Management
• IoT System or Device Management refers to
processes that involve registration, configuration and
provisioning, maintenance and monitoring of
connected devices.
• For example, all the significant cloud providers,
Azure IoT Hub, AWS IoT or Google Cloud IoT,
include services of IoT device management in their
offerings.
 IoT System Management
• IoT system can have
• complex software, hardware
• deployment designs including sensors, actuators,
software
• network resources
• data collection
• analysis services
• user interfaces
 Need for IoT System Management
1. Automating configuration:
 It refers to the spectrum of changes that a system makes to
itself in response to occurrences in its environment.
 IoT System management capabilities can help in
automating the system configurations.
 Provide predictable and easy to use management
capability and the ability to automate system
configurations.
 Automation becomes even more important when system
consists of multiple devices.
 System configuration ensures that all devices have the
same configuration and errors or variations due to manual
configurations avoided.
 Need for IoT System Management
2. Monitoring operational and statistical data:
 Operational data is the data which is related to
system’s operating parameters and is collected by
the system at runtime.
 Statistical data is the data that describes the
system performance.
 Management system can help in monitoring
operational and statistical data of a system. This
data can be used for fault diagnosis and prognosis.
 Need for IoT System Management
3. Improved Reliability:
– Validating the system configurations before they
are put into effect can help in improving system
reliability.
4. Multiple System Configurations:
– It is desirable to have multiple valid
configurations that are applied at different times
or in certain conditions.
 Need for IoT System Management
5. System wide configurations:
 Ensuring system wide configurations can be
critical for the correct functioning of the system.
 Using manual configuration chances of getting
fault is more. This happens when devices are
running on an old configuration while others start
running on new configurations.
 Ensures that the configuration changes are applied
either to all the devices or to none.
 All-or-nothing approach ensures that system
works as expected.
 Need for IoT System Management
6. Retrieving & Reusing configurations
– Management systems have the capability of
retrieving configurations from device can help in
reusing the configurations for other devices of the
same type.
 Simple Network Management
Protocol(SNMP)
• SNMP is a well-known and widely used network
management protocol.
• SNMP allows monitoring and configuring network
devices such as routers, switches, server, printers etc.
• SNMP is an application layer protocol that uses User
Datagram Protocol(UDP) as the transport protocol.
• Components of SNMP:
1. Network Management Station(NMS)
2. Managed Device
3. Management Information Base(MIB)
4. SNMP Agent (runs on the device)
 Contd..
• NMS : NMS executes SNMP commands to monitor
and configure the Managed Device.

• The Managed Device contains the MIB which has

all the information of the device attributes to be
managed.

• MIBs use the Structure of Management

Information(SMI) notation for defining the structure
of the management data.
 Contd..
• The structure of management data is defined in the
form of variables that are identified by object
identifiers(OIDs),
– These have a hierarchical structure.

• Management application can either get or set the

values of these variables.
 SNMP Commands
Retrieve data from a network
GET
node
Retrieve the next element from a
GETNEXT
network node
Send configuration or control
SET
commands to a network node
A network node can send a
TRAP notification to the management
station
An acknowledged trap (network
INFORM nodes can try and send it again if
no acknowledgement is received)
Managing a device with SNMP
Communication of a device with SNMP
Agent
 Limitations of SNMP
1. SNMP is stateless in nature and each SNMP request
contains all the information to process the request.
• If there is sequence of SNMP interactions, the
applications need to maintain state and to roll
back the device to attain consistency in case of
failures.
2. SNMP is a connectionless protocol that uses UDP as
the transport protocol making it unreliable.
3. MIBs lack writable objects without which device
configuration is not possible using SNMP.
• SNMP can be used only for device monitoring
and status polling
 Contd..
4. It is difficult to differentiate between configurations
and state data in MIBs.
5. Retrieving the current configurations from a device
can be difficult with SNMP.
– SNMP does not support easy retrieval and
playback of configurations
6. Earlier versions of SNMP does not have strong
security features making the management information
vulnerable to network intruders.
• Although security features added in later versions
of SNMPs but the complexity increased a lot.
IoT System Management
with
netconf & YANG

Dr. Bivas Ranjan Parida

 Network Operator Requirements
• To address the limitations of the existing network
management protocols
• Internet Architecture Board (IAB) oversees the
Internet Engineering Task Force (IETF)
• IAB held workshop on network management in 2002
• Based on the inputs from the network operators, a list
of operator requirements was prepared
 Introduction
• Netconf is a device configuration and management
protocol and Yang is a modeling language that’s used
by Netconf.
• Shortcomings of SNMP
– SNMP was designed as a management protocol, its
cumbersome for configuration.
– Not transaction based, adds lot of overhead on
upper level management layers to maintain state.
– Not suitable for Developers – makes it difficult to
manage configs, do rollbacks, compare configs etc.
 NETCONF
• Network Configuration Protocol (NETCONF) is a
session-based network management protocol.
• NETCONF allows retrieving state or configuration
data and manipulating configuration data on network
devices. NETCONF provides a clear separation of
the configuration and state data.
• For network management architecture based on
NETCONF, the terms client and management
system, and the terms server and device are often
used interchangeably.
 Characteristics of NETCONF
Following are some key characteristics of Netconf.
• Transaction based – can allow network wide
transactions
• Supports rollback
• Supports any data model
• Clearly separates config from operational state
• Friendlier for Developers – can do save and restore,
compare configs, etc
NETCONF Protocol Stack
 NETCONF Protocol Stack
• Netconf -Network Configuration Protocol defined by
the IETF to “install, manipulate, and delete the
configuration of network devices”.
• NETCONF operations are realized on top of a
Remote Procedure Call (RPC) layer using an XML
encoding.
• NETCONF operations provide a basic set of
operations to edit and query configuration on a
network device.
 NETCONF
• Transport layer provides end-to-end connectivity and
ensure reliable delivery of messages.
• NETCONF works on SSH transport protocol.
• In addition to Secure Shell Transport Layer
Protocol(SSH), NETCONF implementations can
support other transport mappings such as Blocks
Extensible Exchange Protocol(BEEP).
• Transport Layer Security (TLS) is a cryptographic
protocol that protects Internet
communications. TLS replaced SSL in 1999.
 NETCONF
• NETCONF uses XML-encoded Remote Procedure
Calls (RPCs) for framing request and response
messages.
• The RPC layer provides mechanism for encoding of
RPC calls and notifications.
• NETCONF provides various operations to retrieve
and edit configuration data from network devices.
• The Content Layer consists of configuration and state
data which is XML-encoded.
• The schema of the configuration and state data is
defined in a data modeling language called YANG.
 NETCONF
• The configuration data resides within a NETCONF
configuration datastore on the server.
• The NETCONF server resides on the network device.
• The NETCONF operation <getconfig> retrieves the
configuration data only, while the operation <get>
retrieves the configuration and state data.
• The management application plays the role of a
NETCONF device.
 NETCONF
• For managing a network device, the client establishes
a NETCONF session with the server.
• When a session is established, the client and server
exchange “Hello” messages that contain information
on their capabilities.
• Clients can then send multiple requests to the server
for retrieving or editing the configuration data.
• NETCONF allows the management client to discover
the capabilities of the server.
• NETCONF give access to the native capabilities of
the device.
 NETCONF
• A configuration store contains all the configuration
information to bring the device from its initial state to
the operational state.
• By default <running> configuration store is present.
• Additional configuration datastores such as <startup>
and <candidate> can be defined in the capabilities.
NETCONF Datastore
 YANG
• Yang is a data modeling language. Other data modeling
languages like XSD was considered before Yang. But the other
models were not networking friendly. Following are some key
characteristics of Yang.
– Hierarchical data node representation
– Extensible
– Constraints can be placed on the data
– Human readable
• If 2 network vendors implement their device configuration for
a particular feature using a common Yang model, a common
client can be developed and that would be inter-operable. This
would allow a simpler management layer across Network
devices.
• YANG (Yet Another Next Generation)
 YANG
• YANG is a data modeling language used to model
configuration, state data, and administrative actions
manipulated by the NETCONF protocol.
• YANG was originally published as RFC 6020 in
September 2010. Based on real-world user
experience, the original RFC was updated to YANG
1.1 in RFC 7950 in August 2016.
 NETCONF vs RESTCONF
• RESTCONF is quite similar to NETCONF. It also uses
YANG models, and it also stores information and
configuration in logical datastores.
• The difference between NETCONF and RESTCONF is
how we interact with them. RESTCONF provides a
RESTful experience.
• The NETCONF protocol is the oldest and the most
mature protocol used to automate the network. The
RESTCONF is used to programmatically read or update
the configuration of a network device and network
softwares, but is still not suitable for bulk network
automation.