Machine-to-Machine (M2M)

• Machine-to-Machine (M2M) refers to networking of machines (or

devices) for the purpose of remote monitoring , control and data exchange.
• An M2M area network comprises of machines (or M2M nodes) which have
embedded hardware modules for sensing, actuation and communication.
• Various communication protocols can be used for M2M local area
networks such as ZigBee, Bluetooh, ModBus, M-Bus, Wirless M-Bus,
Power Line Communication (PLC), 6LoWPAN, IEEE 802.15.4, etc.
• The communication network provides connectivity to remote M2M
area networks.
• 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
uses IP-based networks.
• The communication between the M2M nodes and the M2M
gateway is based on communication protocols which are
native to the M2M area networks.
 M2M gateway
• M2M gateway performs protocol translation to enable IP-connectivity for M2M area
networks.
• M2M gateway acts as a proxy performing translations from/to native protocols
to/from IP.
• 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.
Communication in IoT vs M2M
 Difference between IoT and M2M
• Communication Protocols
• M2M and IoT can differ in how the communication between
the machines or devices happens.
• M2M uses either proprietary or non-IP based
communication protocols for communication within the
M2M area networks.
• Machines in M2M vs Things in IoT
• The "Things" in IoT refers to physical objects that have
unique identifiers and can sense and communicate with their
external environment (and user applications) or their internal
physical states.
• M2M systems, in contrast to IoT, typically have homogeneous
machine types within an M2M area network.
• Hardware vs Software Emphasis
• While the emphasis of M2M is more on hardware with
embedded modules, the emphasis of IoT is more on
software.
• Data Collection & Analysis
• M2M data is collected in point solutions and often
in on-premises storage infrastructure.
• In contrast to M2M, the data in IoT is collected in the cloud
(can be public, private or hybrid cloud).
• 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- premisis enterprise
applications.
• IoT data is collected in the cloud and can be accessed by
cloud applications such as analytics applications, enterprise
applications, remote diagnosis and management
applications, etc.
 Software Defined Networking
• Software-Defined Networking (SDN) is a networking architecture that
separates the control plane from the data plane and centralizes the
network controller.
• Networking devices in conventional network architectures are complex
with number of distributed protocols.
• In the conventional network architecture the control plane and data plane
are coupled.
• Control plane is the part of the network that carries the signaling and
routing traffic while the data plan is the part of the network that carries
the payload data traffic.
• The limitations of the conventional network architectures are as
follows:
Complex Network Devices:
• Conventional networks are getting increasingly complex with more
protocols.
• Interoperability is limited due to the lack of standard and open
interfaces.
• The conventional networks are well suited for static traffic patterns,
and it is not suitable for dynamic traffic patterns.
Management Overhead:
• Conventional networks involve significant management overhead.
• Network managers find it difficult to manage multiple network
devices and interfaces from multiple vendors.
• Upgradation of network requires configuration changes in multiple
devices.
Limited Scalability:
• The virtualization technologies used in cloud computing
environment has increased the number of virtual hosts requiring
network access.
• IoT applications hosted in the cloud are distributed across multiple
virtual machines that require exchange of traffic.
• In IoT, huge amounts of data are exchanged between virtual
machines.
• Software-Defined
Networking (SDN) is a
networking architecture
that separates the control
plane from the data plane
and centralizes the
network controller.
• Software-based SDN
controllers maintain a
unified view of the
network and make confi
guration, management and
provisioning simpler.
• The underlying
infrastructure in SDN
uses simple packet
forwarding hardware as
opposed to specialized
hardware in conventional
networks.
• The underlying network infrastructure is abstracted from the
applications.
• Network devices become simple with SDN as they do not require
implementations of a large number of protocols.
• Network devices receives instructions from the SDN controller on
how to forward the packets.
Key elements of SDN:

1) Centralized Network Controller

• With decoupled control and data planes and centralized network

controller, the network administrators can rapidly configure the
network.
• SDN applications can be deployed through programmable open
APIS.
2) Programmable Open APIs
• SDN architecture supports programmable open APIs for interface
between the SDN application and control layers (Northbound
interface).
• With these open APIs various network services can be implemented
such as routing, QoS, access control etc.
3) 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.
• With OpenFlow, the forwarding plane of the network devices can be
directly accessed and manipulated.
• OpenFlow uses the concept of flows to identify network traffic
based on pre-defined match rules.
• OpenFlow consists of one or more flow tables and a group table
which performs packet lookup and forwarding.
 NFV
• Network Function Virtualization (NFV) is a 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 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.
• The Key elements of NFV architecture are as follows:
i) Virtualized Network Function(VNF)
ii) NFV Infrastructure(NFVI)
iii) NFV Management and Orchestration
NFV Architecture
 Key elements of NFV
Virtualized Network Function (VNF):
• VNF is a software implementation of a network function which is capable
of running over the NFV Infrastructure (NFVI).
NFV Infrastructure (NFVI):
• NFVI includes compute, network and storage resources that are
virtualized.
NFV Management and Orchestration:
• NFV Management and Orchestration focuses on all virtualization-specific
management tasks and covers the orchestration and life-cycle management
of physical and/or software resources that support the infrastructure
virtualization, and the life-cycle management of VNFs.
• NFV comprises of network functions implemented in software that
run on virtualized resources in the cloud.
• NFV enables separation of network functions which are
implemented in software from the underlying hardware.
• Thus network functions can be easily tested and upgraded by
installing the new software while the hardware remains the
same(Example: DTH).
• Virtualizing network functions reduces the equipment costs and also
reduces power consumptions.
• The Multi-tenanted nature of the cloud allows virtualized network
functions to be shared for multiple network services.
• NFV is applicable only to data plane and control plane functions in
fixed and mobile networks.
 NFV Use Case
• NFV can be used to virtualize the Home Gateway. The NFV
infrastructure in the cloud hosts a virtualized Home Gateway. The
virtualized gateway provides private IP addresses to the devices in
the home. The virtualized gateway also connects to network services
such as VoIP and IPTV.
 Chapter-2
• Need for IoT Systems Management
• SNMP
• Network Operator Requirements
• NETCONF
• YANG
• IoT Systems Management with NETCONF-YANG
 Need for IoT Systems Management
• IoT systems can have complex software, hardware and deployment designs
including sensors, actuators, software and network resources, data collection and
analysis services and user interfaces.
• IoT systems can have distributed deployments comprising of a number of IoT
devices which collect data from sensors or performs actuation.
• Managing multiple devices within a single system requires advanced management
capabilities.
The need for Managing IoT Systems is described as follows:
 Automating Configuration
 Monitoring Operational & Statistical Data
 Improved Reliability
 System Wide Configuration
 Multiple System Configurations
 Retrieving & Reusing Configurations
Automating Configuration:
• IoT system management capabilities can help in automating the system
configurations.
• System management interfaces provide predictable and easy to use
management capability and the ability to automate system configuration.
• Automation becomes even more important when a system consists of multiple
devices or nodes.
• In such cases automating the system configuration ensures that all devices
have the same configuration and variations or errors due to manual
configurations are avoided.
Monitoring Operational & Statistical Data:
• Operational data is the data which is related to the systems operating
parameters and is collected by the system at runtime.
• Statistical data is the data which describes the system performance( Ex: CPU
and Memory Usage)
• Management systems can help in monitoring operational and statistical data of
a system.
• This data can be used for fault diagnosis or prognosis.
System Wide Configuration:
• IoT systems that consists of multiple devices or nodes, ensuring system-wide configuration
can be critical for the critical functioning of the system.
• Management approaches in which each device is configured separately can result in system
faults.
• This happens when some devices are running on old configuration while others start running
on new configuration.
• To avoid this, system wide configuration is required where all devices are configured in a
single atomic transaction.
• In the event of a failure in applying the configuration to one or more devices, the
configuration changes are rolled back.(Ex: ATMs).

Multiple System Configurations:

• For some systems it may be desirable to have multiple valid configurations which are applied
at different times or in certain conditions.

Retrieving & Reusing Configurations:

• Management systems which have the capability of retrieving configurations from devices can
help in reusing the configurations for other devices of the same type.
• Ex: Management System retrieve the current configuration from a device and apply the same
to the new devices.
Simple Network Management
Protocol (SNMP)
• SNMP is a well-known and widely used
network management protocol that allows
monitoring and configuring network devices
such as routers, switches, servers, printers,
etc.
• SNMP component include
• Network Management Station (NMS)
• Managed Device
• Management Information Base (MIB)
• SNMP Agent that runs on the device
• 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.
• MIB use the structure of Management Information(SMI) notation for defining
the structure of the management data.
• The structure of management data is defined in the form of variables which
are identified by Object Identifiers(OIDs), which have a hierarchical structure.
• Management applications can either get or set the values of these variables.

• SNMP is an application layer protocol that uses UDP as the transport protocol.
 Limitations of SNMP
• SNMP is stateless in nature and each SNMP request contains all
the information to process the request. The application needs to
be intelligent to manage the device.
• SNMP is a connectionless protocol which uses UDP as the transport
protocol, making it unreliable as there was no support for
acknowledgement of requests.
• MIBs often lack writable objects without which device
configuration is not possible using SNMP.
• It is difficult to differentiate between configuration and state data
in MIBs.
• Retrieving the current configuration from a device can be
difficult with SNMP.
• Earlier versions of SNMP did not have strong security
features.
 Network Operator Requirements

• Ease of use • Configuration validation

• Distinction between • Configuration database
configuration and state data schemas
• Fetch configuration and state • Comparing configurations
data separately • Role-based access control
• Configuration of the network as • Consistency of access
a whole control lists
• Configuration transactions across • Multiple configuration sets
devices
• Support for both data-
• Configuration deltas oriented and task- oriented
• Dump and restore configurations access control
 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(Contd..)

• NETCONF works on SSH transport protocol.

• Transport layer provides end-to-end connectivity and ensure reliable
delivery of messages.
• 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 provides a clear separation of the configuration and state
data.
• The configuration data resides within a NETCONF configuration
datastore on the server.
• The NETCONF server resides on the network device.
• The management application plays the role of a NETCONF client.
• 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.
• Client can send multiple requests to the server for retrieving or editing
configuration data.
• NETCONF allows the management client to discover the capabilities of
the server.
• NETCONF defines one or more configuration datastores.
• A configuration store contains all the configuration information to bring
the device from its initial state to operational state.
• NETCONF is a connection oriented protocol, it also overcomes the
limitations of SNMP.
• It is suitable not only for monitoring state information, but also for
configuration management.
 YANG
• YANG is a data modeling language used to model
configuration and state data manipulated by the
NETCONF protocol
• YANG modules contain the definitions of the configuration data, state
data, RPC calls that can be issued and the format of the notifications.
• YANG modules defines the data exchanged between the NETCONF
client and server.
• A module comprises of a number of 'leaf' nodes which are organized
into a hierarchical tree structure.
• The 'leaf' nodes are specified using the 'leaf' or 'leaf-list' constructs.
• Leaf nodes are organized using 'container' or 'list' constructs.
• A YANG module can import definitions from other modules.
• Constraints can be defined on the data nodes, e.g. allowed values.
• YANG can model both configuration data and state data using the
'config' statement.
 YANG Module Example
• This YANG module is a YANG version
of the toaster MIB
• The toaster YANG module begins with
the header information followed by
identity declarations which define
various bread types.
• The leaf nodes
(‘toasterManufacturer’,
‘toasterModelNumber’ and
oasterStatus’) are defined in the
‘toaster’ container.
• Each leaf node definition has a type and
optionally a description and default
value.
• The module has two RPC definitions
(‘make-toast’ and ‘cancel-toast’).
IoT Systems Management with
NETCONF-YANG
Management system: The operator uses a management system to send
NETCONF messages to configure the IoT device and receives state
information and notifications from the device as NETCONF messages.
Management API: Management API allows management applications to start
NETCONF sessions, read and write configuration data, read state data,
retrieve configurations and invoke RPCs.
Transaction Manager: Transaction Manager executes all the NETCONF
transactions and ensures that the ACID(Atomicity, Consistency, Isolation,
Durability)properties.
• Atomicity properties ensures that transaction is executed completely or not.
• Consistency property ensures that a transaction brings the device
configuration from one valid state to another.
• Isolation property ensures that concurrent execution of transactions results
in the same device configuration as if transactions were executed serially
in order.
• Durability property ensures that a transaction once committed will persist.
• Rollback Manager: Rollback manager is responsible for generating all the
transactions necessary to rollback a current configuration to its original
state.
• Data Model Manager: The Data Model Manager keeps track of all the
YANG data models and the corresponding managed objects. The Data
Model Manager also keeps track of the applications which provide data for
each part of a data model.
• Configuration Validator: Configuration validator checks if the resulting
configuration after applying a transaction would be a valid configuration.
• Configuration Database: This database contains both the configuration
and operational data.
• Configuration API: Using the configuration API the applications on the
IoT device can read configuration data from the configuration datastore and
write operational data to the operational datastore.
• Data Provider API: Applications on the IoT device can register for
callbacks for various events using the Data Provider API. Through the Data
Provider API, the applications can report statistics and operational data.
 NETOPEER
• Netopeer is set of open source NETCONF tools built on the Libnetconf
library.
• The Netopeer tools include:
• Netopeer-server: Netopeer-server is a NETCONF protocol server that
runs on the managed device. Netopeer-server provides an environment for
configuring the device using NETCONF RPC operations and also
retrieving the state data from the device.
• Netopeer-agent: Netopeer-agent is the NETCONF protocol agent running
as a SSH/TLS subsystem. Netopeer-agent accepts incoming NETCONF
connection and passes the NETCONF RPC operations received from the
NETCONF client to the Netopeer-server.
• Netopeer-cli: Netopeer-cli is a NETCONF client that provides a command
line interface for interacting with the Netopeer-server. The operator can use
the Netopeer-cli from the management system to find the NETCONF RPC
operations for configuring the device and retrieving the state information.
• Netopeer-manager: Netopeer-manager allows managing the YANG
and Libnetconf Transaction API modules on the Netopeer-server.
With Netopeer-manager modules can be loaded or removed from the
server.
• Netopeer-configurator: Netopeer-configurator is a tool that can be
used to configure the Netopeer-server.
Steps for IoT device Management with NETCONF-YANG:
1. Create a YANG model of the system that defines the configuration
and state data of the system.
2. Compile the YANG model with the Inctool which comes with
Libnetconf.
Libnetconf provides a framework called Transaction API that
provides a mechanism of reflecting the changes in the
configuration file in the actual device.
3.Fill the IoT device management code in the TransAPI
module(callbacks C file). This file includes configuration callbacks,
RPC callbacks and state data callbacks.
4.Build the callbacks C file to generate the library file.
5.Load the YANG module and the TransAPI module into the Netopeer
server using the Netopeer manger tool.
6.The operator can now connect from the management system to the
Netopeer server using the Netopeer CLI.
7. Operator can issue the NETCONF commands from the Netopeer
CLI. Commands can be issued to change the configuration data, get
operational data or execute an RPC on the IoT device.