Nature of IoT

• IoT is a complex system

• Complex software, hardware and deployment
designs
• 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
transaction
Need for IoT Systems management
• Multiple system configuration
• Retrieving and resulting configurations
 SNMP
• 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
 SNMP
• 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
 SNMP
• 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
data
• 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
control
 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
 NETCONF
• NETwork CONFiguration Protocol
• Session based network management protocol
• Allows retrieving state or configuration data
• Allows to manipulate configuration data on
network devices
 NETCONF
• 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
 NETCONF
• BEEP – Blocks Extensible Exchange Protocol
(BEEP)
– Not a transport layer protocol, but supports transport
mappings
– A framework for creating network application
protocols
– 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
 NETCONF
• BEEP
– Message syntax and semantics is defined with
BEEP profiles
– BEEP profiles are associated to one or more BEEP
channels
– Each channel is a full-duplex pipe
– Framing-mechanism enables simultaneous and
independent communication between peers
 NETCONF Vs SNMP
• 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
 NETCONF Vs SNMP
• 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 Vs SNMP
• 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
Content
(Configuration
Data)

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

RPC or Notification
(<rpc>,<rpc-reply>)
NETCONF
Configuration
Datastore
Transport
(SSH, TLS, Console)

YANG defined
 NETCONF
• Transport layer
– Provides end to end connectivity and ensure
reliable transfer of messages
• RPC layer
– Provides mechanism for encoding of RPC calls and
notifications
– Uses XML encoded RPCs for framing request and
response messages
 NETCONF
• XML-RPC
– 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
transported
– 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
configuration
close-session Gracefully terminate a NETCONF session
kill-session Forcefully terminate a NETCONF session
 NETCONF
• 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 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
device
 NETCONF
• 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
interchangeably
• 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
 NETCONF
• 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)
 NETCONF
• 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
present
• Additional configuration data stores such as
<startup> and <candidate> can be defined in
the network capabilities
 NETCONF
• 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
 YANG
• Yet Another Next Generation
• Data modeling language for NETCONF
protocol
• 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
 YANG
• Abstract Syntax Notation
– Describes rules and structures for representing, encoding,
transmitting,
and decoding data intelecommunications and computer
networking
• XML
– A set of rules for encoding documents in a format which is
both human-readable and machine-readable
• SQL
– 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)
 YANG
• 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
• 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
structure
 YANG
• 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

NETCONF

Management Transaction Rollback

API Manager Manager

NETCONF
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
NETCONF-YANG
• 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
NETCONF-YANG
• 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
NETCONF-YANG
• 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
NETCONF-YANG
• 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
data
 NETOPEER
• Set of open source NETCONF tools built on the
LIBnetconf library
IoT Device management with NETCONF – a specific approach based on Netopper tools

Management
System
SSH Client
netopper-cli

Netopeer YANG Modules

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

IoT Device
 NETOPEER
• 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
• Netopeer-agent
– The NETCONF protocol agent running as a SSH/TLS
subsystem
– Accepts incoming NETCONF connection and
passes the NETCONF RPC operation received from
the NETCONF client to the Netopeer-server
 NETOPEER
• 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
information
 NETOPEER
• 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