Chapter 4

Book website: http://www.internet-of-things- Bahga & Madisetti, ©

 Outline

•Need for IoT Systems Management

•SNMP
•Network Operator Requirements
•NETCONF
•YANG
•IoT Systems Management with NETCONF-YANG

Book website: http://www.internet-of-things- Bahga & Madisetti, ©

 Need for IoT Systems Management

•Automating Configuration
• Monitoring Operational & Statistical Data
• Improved Reliability
• System Wide Configurations
• Multiple System Configurations
• Retrieving & Reusing Configurations

Book website: http://www.internet-of-things- Bahga & Madisetti, ©

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 operates within the application layer of the Internet protocol
suite and allows network administrators to manage network
performance, find and solve network problems, and plan for
network growth.

Book website: http://www.internet-of-things- Bahga & Madisetti, ©

 •SNMP components include

 Network Management Station (NMS):

 It is a centralized system used to monitor the network.
 A router that runs the SNMP server program is called an agent,
while a host that runs the SNMP client program is called
a manager.
• Managed Device:
 Management Information Base (MIB):

 consists of information on resources that are to be managed.

Book website: http://www.internet-of-things- Bahga & Madisetti, ©

  This information is organized hierarchically.
 It consists of objects instances which are essentially variables.
 A MIB, or collection of all the objects under management by the manager, is
unique to each agent. System, interface, address translation, IP, UDP,
EGP(Exterior Gateway Protocol),ICMP(Internet Control Message
Protocol), TCP( Transmission Control Protocol) are the eight categories that
make up MIB. The MIB object is home to these groups.

 SNMP Agent that runs on the device:

 It is a software management software module installed on a managed
device.

Book website: http://www.internet-of-things- Bahga & Madisetti, ©

  The manager accesses the values stored in the database, whereas the
agent maintains the information in the database.
 To ascertain if the router is congested or not, for instance, a manager
can examine the relevant variables that a router stores, such as the
quantity of packets received and transmitted.

Book website: http://www.internet-of-things- Bahga & Madisetti, ©

Book website: http://www.internet-of-things- Bahga & Madisetti, ©
SNMP Messages
 GetRequest : It is simply used to retrieve data from SNMP agents. In response to this, the
SNMP agent responds with the requested value through a response message.
 GetNextRequest : To get the value of a variable, the manager sends the agent the
GetNextRequest message. The values of the entries in a table are retrieved using this kind
of communication. The manager won’t be able to access the values if it doesn’t know the
entries’ indices. The GetNextRequest message is used to define an object in certain
circumstances.
 Set Request : It is used by the SNMP manager to set the value of an object instance on the
SNMP agent.
 Response : When sent in response to the Set message, it will contain the newly set value
as confirmation that the value has been set.

Book website: http://www.internet-of-things- Bahga & Madisetti, ©

  Trap : These are the message sent by the agent without being requested by the manager.
It is sent when a fault has occurred.
 Inform Request : It was added to SNMPv2c and is used to determine if the manager has
received the trap message or not. It is the same as a trap but adds an acknowledgement
that the trap doesn’t provide.
Advantages of SNMP
 It is easy to implement.
 Agents are widely implemented.
 Agent level overhead is minimal.
 It is robust and extensible.
 Polling approach is good for LAN based managed object.
 It offers the best direct manager agent interface.

Book website: http://www.internet-of-things- Bahga & Madisetti, ©

 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.

Book website: http://www.internet-of-things- Bahga & Madisetti, ©

 Network Operator Requirements

• Ease of use • Configuration validation

• Distinction between configuration and state data • Configuration database schemas
• Fetch configuration and state data separately • Comparing configurations
• Configuration of the network as a whole • Role-based access control
• Configuration transactions across devices • Consistency of access control lists:
• Configuration deltas • Multiple configuration sets
• Dump and restore configurations • Support for both data-oriented and
task- oriented access control

Book website: http://www.internet-of-things- Bahga & Madisetti, ©

 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 is a protocol that that can manage, configure and install new configuration of network
device. Its operations are realized on top of an easy Remote Procedure Call (RPC) layer. NETCONF
uses Extensible Markup Language (XML) based on data encoding for protocol messages. The
protocol messages are exchanged on the top of a secure transport protocol.

Book website: http://www.internet-of-things- Bahga & Madisetti, ©

 NETCONF

• 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 NETCONF protocol are often conceptually partitioned into four layers:
• The Content layer has a configuration data and notification data.
• The Operations layer defines a set of base protocol operations to retrieve and to edit the
configuration data.
• The Messages layer is responsible for encoding remote procedure calls (RPCs) and
notifications.

Book website: http://www.internet-of-things- Bahga & Madisetti, ©

 • The Secure Transport layer features a secure and reliable transport of messages between a
client and a server.
• 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.
How Does NETCONF Work?

Book website: http://www.internet-of-things- Bahga & Madisetti, ©

 Network Configuration Protocol is a session-based protocol. For operation, firstly, a session must be
established between the client and the server.
NETCONF Server waits for NETCONF Client to initiate the session. Here, the process steps are like
below:

 Firstly, the client starts SSH connection to the server. Here, the client can be a software on a PC
and the server is the managed device.

 If the connection is established successfully, then client and the server start to exchange NETCONF
Hello massages. In this step, the client and the server negotiate about the capabilities, supported
models, versions etc.

 After that, the client uses RPC calls for any actions on the device like device configuration.
NETCONF Server replies with OK message if it is successful or it gives information or error.

 To terminate the session, the client uses RPC calls

Book website: http://www.internet-of-things- Bahga & Madisetti, ©

 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.

Book website: http://www.internet-of-things- Bahga & Madisetti, ©

 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’).

Book website: http://www.internet-of-things- Bahga & Madisetti, ©

IoT Systems Management with NETCONF-YANG

•Management System
• Management API
• Transaction Manager
• Rollback Manager
• Data Model Manager
•Configuration Validator
•Configuration Database
•Configuration API
•Data Provider API

Book website: http://www.internet-of-things- Bahga & Madisetti, ©