You are on page 1of 47

Nature of IoT

• IoT is a complex system

• Complex software, hardware and deployment
• Includes sensors, actuators, network, data
collection, analysis and UIs
• Deployed distributed
• Needs formal management techniques
Need for IoT Systems management
• Automating configuration
– Required when number of devices is more
– Ensures that all devices have the same configuration
– Variations or errors are avoided
• Monitoring operational data and statistical data
– Operational data – generated during run time
– Statistical data – related to performance
– Required for fault diagnosis or prognosis
Need for IoT Systems management
• Improved reliability
– Validating the system configuration before they are
put into effect
• System wide configuration
– Configuring devices separately results in faults or
undesirable outcomes
– Some run on old and some run on new
– Holistic approach is required to avoid inconsistency
– All devices are configured in a single atomic
Need for IoT Systems management
• Multiple system configuration
• Retrieving and resulting configurations
• Network Management Station (NMS),
managed device, Management Information
Base and SNMP agent that runs on the device
• NMS executes SNMP commands to monitor
and configure the managed devices
• Managed devices contain the MIBs
• MIBs are based on Structure of Management
Information (SMI) standard or notation
• Runs above UDP
• Stateless in nature
• Connectionless protocol
• No reliability
• MIBs lack writable objects which is required
for device configuration
• Difficult to differentiate between
configuration data and state data in MIBs
• Retrieving current configuration is difficult
• Lacks security features
Network Operator Requirements
• Workshop on network management in 2002
by IAB and IETF
• Ease of use
• Distinction between configuration and state
• Configuration data – set of writable data that is
required to transform the system from its initial state to
its current state
• State data – operational data + statistical data
Network Operator Requirements
• Fetch configuration and state data separately
• Configuration of the network as a whole
• Configuration transactions across devices
• Configuration deltas
• Dump and restore configurations
• Configuration validation
• Configuration database schema
• Role based access control
• Consistency of access control lists
• Multiple configuration sets
• Support for both data oriented and task oriented access
Types of Data
• Operational data – generated during run time
• Statistical data – related to performance
• Required for fault diagnosis or prognosis
• Configuration data – set of writable data that
is required to transform the system from its
initial state to its current state
• State data – operational data + statistical data
Limitations of SNMP
• MIBs lack writable objects which is required
for device configuration
• Difficult to differentiate between
configuration data and state data in MIBs
• Retrieving current configuration is difficult
• Lacks security features
• NETwork CONFiguration Protocol
• Session based network management protocol
• Allows retrieving state or configuration data
• Allows to manipulate configuration data on
network devices
• Works on SSH transport protocol
• SSH – Secure Shell
– Provides a secure channel over an unsecured
network in a client-server architecture
– Common applications include remote command-
line login and remote command execution
– Any network service can be secured with SSH
• NETCONF can work over BEEP also
• BEEP – Blocks Extensible Exchange Protocol
– Not a transport layer protocol, but supports transport
– A framework for creating network application
– Includes building blocks like framing, pipelining,
multiplexing, reporting and authentication
– Connection and message-oriented P2P protocols with
support of asynchronous full-duplex communication
are the application protocols
– Message syntax and semantics is defined with
BEEP profiles
– BEEP profiles are associated to one or more BEEP
– Each channel is a full-duplex pipe
– Framing-mechanism enables simultaneous and
independent communication between peers
• NETCONF protocol has a higher bandwidth
requirement utilization for ‘k’ number of Ethernet
frames (i.e., packets) due to the overhead
required for
– Security
– Connection-oriented (session-based) and
– Capability exchange features that are lacking in the
SNMP protocol
• However, these are necessary features for
managing complex networks
• At a lower number of managed objects, SNMP has a
faster operation time
• But as the managed objects exceeds ~500, NETCONF’s
operation time efficiency surpasses SNMP
• NETCONF is most powerful when it stacks up against
SNMP for number of transactions
• NETCONF is able to configure 100,000 managed objects
in a single transaction, using XML configuration data as
its payload
• SNMP’s best case scenario is 2779 transactions for the
same number of managed objects
• NETCONF is a viable alternative solution to SNMP
for Configuration Management functions for
today’s complex networks
• Also suitable for emerging new generation back
office systems
• NETCONF protocol clearly has the ability to
displace SNMP as the incumbent Configuration
Management protocol
• Also provides the Communication Service
Provider’s with a more powerful back office tool
to meet their higher network operation demands
NETCONF Protocol Layers
YANG Defined

Client Server
Operations (<get-
config>, <edit-

RPC or Notification
(SSH, TLS, Console)

YANG defined
• Transport layer
– Provides end to end connectivity and ensure
reliable transfer of messages
• RPC layer
– Provides mechanism for encoding of RPC calls and
– Uses XML encoded RPCs for framing request and
response messages
– Works by sending a HTTP request to a server
implementing the protocol
– The client is typically a software wanting to call a
single method of a remote system
– Multiple input parameters can be passed to the
remote method, one return value is returned
– The parameter types allow nesting of parameters into
maps and lists, thus larger structures can be
– Therefore, XML-RPC can be used to transport objects
or structures both as input and as output parameters
Operations Layer - retrieve and edit configuration data from
network devices
Commonly used NETCONF RPC methods
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 data store
edit-config Loads all or part of a specified configuration data-store with a complete
source configuration
copy-config Create or replace an entire target configuration data store with a
complete source configuration
delete-config Delete the contents of a configuration database
lock Lock a configuration data-store for exclusive edits by a client
unlock Release the lock on a configuration data-store
get-scheme This operation is used to retrieve a schema from the NETCONF server
commit Commit the candidate configuration as the device’s new current
close-session Gracefully terminate a NETCONF session
kill-session Forcefully terminate a NETCONF session
• 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
• Provides a clear separation of configuration
data and state data
– E.g., Get-config retreives the configuration data
only whereas the get operation retrieves the
configuration data and static data
• Configuration data resides within a NETCONF
configuration data store on the server
• NETCONF server resides on the network
• Management application plays the role of a NETCONF client
• Hence the terms management system and the client are
used interchangeably
• The client establishes a NETCONF session with the server to
manage a network device
• Hence the terms server and device are used
• i.e, the entity that manages is the client and the entity that
is managed is the server
• In SNMP also, network manager plays the role of client and
the management agent running in the devices to be
managed plays the role of server
• Once a session is established the client and
server exchange hello messages which contain
information on their capabilities
• Client then sends multiple requests to the
server for retrieving or editing the
configuration data
• Allows the management client to discover the
capabilities of the server (on the device)
• Defines one or more configuration data stores
• A configuration store contains all the
configuration information to bring the device
from its initial state to the operational state
• By default a <running> configuration store is
• Additional configuration data stores such as
<startup> and <candidate> can be defined in
the network capabilities
• A connection oriented protocol
• NETCONF connection persists between
protocol operations
• For authentication, data integrity and
confidentiality NETCONF depends on the
transport protocol e.g., SSH, BEEP etc
• Yet Another Next Generation
• Data modeling language for NETCONF
• Developed by NETMOD working group of IETF
• Can be used to model both configuration data
as well as state data manipulated by NETCONF
• Used to define the format of event
notifications emitted by network elements
• Abstract Syntax Notation
– Describes rules and structures for representing, encoding,
and decoding data intelecommunications and computer
– A set of rules for encoding documents in a format which is
both human-readable and machine-readable
– A special-purpose programming language designed for
managing data held in a relational database management
system (RDBMS), or for stream processing in a relational
data stream management system (RDSMS)
• Used to model configuration and state data
manipulated by NETCONF protocol
• A YANG module defines a hierarchy of data that can be
used for NETCONF based operations
• Data includes configuration, state data, Remote
Procedure Calls (RPCs), and notifications
• This allows a complete description of all data sent
between a NETCONF client and server
• YANG models the hierarchical organization of data as a
tree in which each node has a name, and either a value
or a set of child nodes
• YANG structures data models into modules
and sub modules
• YANG modules define the data exchanged
between the NETCONF client and server
• A module can import data from other external
modules, and include data from sub modules
• A module contains a number of leaf nodes
which are organized into a hierarchical tree
• The leaf nodes are specified using the leaf or
leaf-list constructs
• Leaf nodes are organized using ‘container’ or
‘list’ constructs
• Constraints can be defined on the data nodes
– Allowed values
• Can model both configuration data and state
data using the ‘config’ statement
YANG Node Types

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 leafs and
may contain any number of child nodes of
any type
IoT Systems Management with NETCONF-YANG

Management System


Management Transaction Rollback

API Manager Manager

Authentication Server
Data Model Configuration
, Authorization
Manager Validator
and Auditing

Yang Configuration Configuration Data provider

Modules Database API API

Managed Applications (Status, Statistics, IoT

Objects Performance, alarms, Counters) Device
IoT Systems Management with
• Management System
– Operator uses a Management System to send
NETCONF messages to configure the IoT device
– Operator 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
• Invoke RPCs
IoT Systems Management with
• Transaction Manager
– Executes all the NETCONF transactions
– Ensures the ACID properties of the transactions
– Atomicity – a transaction is executed either
completely or not at all
– Consistency – a transaction brings the device
configuration from one valid state to another
– Isolation – concurrent execution of transactions
results in the same device configuration as if
transactions were executed serially in order
– Durability – a transaction once committed will persist
IoT Systems Management with
• Rollback manager
– Responsible for generating all the transactions
necessary to rollback a current configuration to its
original state
• Data model manager
– Keeps track of al the YANG data models and the
corresponding managed objects
– Keeps track of applications which provide data for
each part of a model
IoT Systems Management with
• Configuration validator
– Checks if the resulting configuration after applying a
transaction would be a valid configuration
• Configuration database
– Contains both configuration and operational data
• Configuration API
– Enables the applications on the IoT device to
• Read configuration data from the configuration data store
• Write operational data to the operational data store
• Data provider API
– Helps the applications to report statistics and operational
• Set of open source NETCONF tools built on the
LIBnetconf library
IoT Device management with NETCONF – a specific approach based on Netopper tools

SSH Client

Netopeer YANG Modules

SSH Server
netopeer-agent DBus netopeer-
server TransAPI
Datastore Server

IoT Device
• Netopeer-server
– A NETCONF protocol server that runs on the
managed device
– Provides an environment for configuring the
device using NETCONF RPC operations
– Also provides an environment for retrieving the
state data from the device
• Netopeer-agent
– The NETCONF protocol agent running as a SSH/TLS
– Accepts incoming NETCONF connection and
passes the NETCONF RPC operation received from
the NETCONF client to the Netopeer-server
• Netopeer-cli
– A NETCONF client that provides a command line
interface for interfacing with the Netopeer-server
– Used by the operator from the management
station to send NETCONF RPC operations for
configuring the device and retrieving the state
• Netopeer-manager
– Allows managing the YANG and Libnetconf
Transaction API modules on the Netopeer-server
– Used to load or remove modules from the server
• Netopeer-configurator
– Used to configure the Netopeer-server
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 mechanism of reflecting the changes in the configuration
file in the actual device. The Inctool generates a TransAPI module (callbacks C
file). Whenever a change is made in the configuration file using the NETCONF
operations, the corresponding callback function is called. The callback functions
contain the code for making the changes on the device)
3. Fill in 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 (.so)
5. Load the YANG module (containing the data definitions) and the TransAPI module
(.so binary) into the Netopeer server using the Netopeer manager tool
6. The operator can now connect from the management system to the Netopeer
server using the Netopeer CLI
7. Operator can issue NETCONF commands from the Netopeer CLI. Commands can
be used to change the configuration data, get operational data or execute an RPC
on the IoT device