IOT SYSTEMS MANAGEMENT
WITH NETCONF-YANG
By
J.ANN ROSEELA
AP/ECE
Simple Network Management Protocol(SNMP)
Simple Network Management Protocol (SNMP)
is a set of protocols for network management
and monitoring.
These protocols are supported by many typical
network devices such as routers, hubs, bridges,
switches, servers, workstations, printers, modem
racks and other network components and
devices.
Supported devices are all network-attached
items that must be monitored to detect
conditions.
SNMP
These conditions must be addressed for proper,
appropriate and ongoing network
administration
SNMP standards include an application layer
protocol, a set of data objects and a
methodology for storing, manipulating and
using data objects in a database schema.
The SNMP protocol is included in the
application layer of TCP/IP as defined by the
Internet Engineering Task Force (IETF).
SNMP
Three key components of a network managed
by SNMP are the managed devices like
routers
servers
switches, etc.
software agents, and a network management
system.
There may be more than one NMS on a given
managed network.
SNMP versions
SNMP has evolved into three different versions:
SNMPv1: This was the first implementation,
operating within the structure management
information specification, and described in RFC 1157.
SNMPv2: This version has improved support for
efficiency and error handling and is described in RFC
1901. It was first introduced in RFC 1441 and is more
appropriately known as SNMP v2c.
SNMPv3: This version improves security and
privacy. It was introduced in RFC 3410.
Limitations of SNMP v1
SNMP may not be suitable for the
management of truly large networks because
of the performance limitations of polling.
SNMP is not well suited for retrieving large
volumes of data, such as an entire routing
table.
SNMP traps are unacknowledged & may not
be delivered.
Limitations of SNMP v1
SNMP provides only trivial authentication i.e.
it is suitable for monitoring rather than control.
SNMP does not support explicit actions i.e., an
action is taken by changing a parameter or
setting an object value (indirectly).
SNMP does not support manager-to-manager
communications
NETCONF protocol
The Network Configuration Protocol
(NETCONF) is a network management protocol
developed and standardized by the IETF.
It was developed in the NETCONF working
group and published in December 2006 as RFC
4741 and later revised in June 2011 and
published as RFC 6241.
The NETCONF protocol specification is an
Internet Standards Track document.
NETCONF protocol
NETCONF provides mechanisms to install,
manipulate, and delete the configuration of
network devices.
Its operations are realized on top of a simple
Remote Procedure Call (RPC) layer.
The NETCONF protocol uses an Extensible
Markup Language (XML) based data encoding
for the configuration data as well as the protocol
messages.
The protocol messages are exchanged on top of a
secure transport protocol.
NETCONF protocol partitioned into four layers:
The Content layer consists of configuration
data and notification data.
The Operations layer defines a set of base
protocol operations to retrieve and edit the
configuration data.
The Messages layer provides a mechanism for
encoding remote procedure calls (RPCs) and
notifications.
The Secure Transport layer provides a secure
and reliable transport of messages between a
client and a server.
NETCONF protocol
The NETCONF protocol has been implemented
in network devices such as
routers and
switches
by some major equipment vendors.
One particular strength of NETCONF is its
support for robust configuration change using
transactions involving a number of devices
IoT Systems Management with NETCONF-YANG
YANG is a data modeling language used to
model configuration and state data
manipulated by the NETCONF protocol.
The generic approach of IoT device
management with NETCONF-YANG. Roles
of various components are:
Management System
Management API
Transaction Manager
Roles of various components:
RollbackManager
Data ModelManager
ConfigurationValidator
ConfigurationDatabase
ConfigurationAPI
Data ProviderAPI
IoT Systems Management with
NETCONF-YANG
1) 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 NETCONFmessages.
2) Management API : allows management application to start
NETCONFsessions.
3) Transaction Manager: executes all the NETCONF
transactions and ensures that ACID properties hold true for
thetrasactions.
4) Rollback Manager : is responsible for generating all the
transactions necessary to rollback a current configuration to
its original state.
Data Model Manager : Keeps track of all the
YANG data models and the corresponding
managed objects. Also keeps track of the
applications which provide data for each part
of a datam,odel.
Configuration Validator : checks if the resulting
configuration after applying a transaction
would be a validconfiguration.
Configuration Database : contains both
configuration and operastionaldata.
CLOUD STORAGE API
A cloud storage API is an application program
interface that connects a locally-based
application to a cloud-based storage system,
so that a user can send data to it and access and
work with data stored in it.
To the application, the cloud storage system is
just another target device, like tape or disk-
based storage.
CLOUD STORAGE API
An application program interface (API) is code
that allows two software programs to
communicate with each other.
The API defines the correct way for a developer
to write a program that requests services from
an operating system (OS) or other application.
APIs are implemented by function calls
composed of verbs and nouns. The required
syntax is described in the documentation of the
application being called.
How APIs work
APIs are made up of two related elements.
The first is a specification that describes how
information is exchanged between programs,
done in the form of a request for processing
and a return of the necessary data.
The second is a software interface written to
that specification and published in some way
for use.
The software that wants to access the features
and capabilities of the API is said to call it, and
the software that creates the API is said to
publish it.
Three basic types of APIs
APIs take three basic forms:
local,
web-like and
program-like.
Local APIs are the original form, from which
the name came.
They offer OS or middleware services to
application programs.
Microsoft's .NET APIs, the TAPI (Telephony API)
for voice applications, and database access APIs
are examples of the local APIform.
APIs
Web APIs are designed to represent widely used
resources like HTML pages and are accessed
using a simple HTTP protocol.
Any web URL activates a web API.
Web APIs are often called REST
(representational state transfer) or REST ful
because the publisher of REST interfaces doesn't
save any data internally between requests.
As such, requests from many users can be
intermingled as they would be on the internet.
APIs
Program APIs are based on remote
procedure call (RPC) technology .
It makes a remote program component
appear to be local to the rest of the
software.
Service oriented architecture (SOA) APIs,
such as Microsoft's WS-series of APIs, are
program APIs
IoT/cloud infrastructures and related
services
IoT/cloud infrastructures and related services can be
classified to the following models:
Infrastructure-as-a-Service (IaaS) IoT/Clouds: These
services provide the means for accessing sensors and
actuator in the cloud. The associated business model
involves the IoT/Cloud provide to act either as data or
sensor provider.
IaaS services for IoT provide access control to resources as
a prerequisite for the offering of related pay-as-you-go
services.
Platform-as-a-Service
Platform-as-a-Service (PaaS) IoT/Clouds:
This is the most widespread model for IoT/cloud
services, given that it is the model provided by all
public IoT/cloud infrastructures.
Most public IoT clouds come with a range of tools and
related environments for applications development
and deployment in a cloud environment.
A main characteristic of PaaS IoT services is that they
provide access to data, not to hardware. This is a clear
differentiator comparing to IaaS.
Software-as-a-Service
Software-as-a-Service (SaaS) IoT/Clouds:
SaaS IoT services are the ones enabling their
uses to access complete IoT-based software
applications through the cloud, on-demand
and in a pay-as-you-go fashion.
As soon as sensors and IoT devices are not
visible, SaaS IoT applications resemble very
much conventional cloud-based SaaS
applications.
Software-as-a-Service
There are however cases where the IoT dimension is strong
and evident, such as applications involving selection of
sensors and combination of data from the selected sensors
in an integrated applications.
Several of these applications are commonly called Sensing-
as-a- Service, given that they provide on-demand access to
the services of multiple sensors.
SaaS IoT applications are typically built over a PaaS
infrastructure and enable utility based business models
involving IoT software and services.
WAMP
Transport: Transport is channel that connects two peers.
Session: Session is a conversation between two peers
that runs over a transport.
Client: Clients are peers that can have one or more roles.
In publish-subscribe model client can have following
roles:
a) Publisher: Publisher publishes events (including
payload) to the topic maintained by the broker.
b) Subscriber: Subscriber subscribes to the topics and
receives the events including the payload.
Application code runs on the Clients (Publisher,
Subscriber, Callee or Caller).
WAMP
In RPC model client can have following roles: –
Caller: Caller issues calls to the remote procedures
along with call arguments. –
Callee: Callee executes the procedures to which the
calls are issued by the caller and returns the results
back to the caller.
Router: Routers are peers that perform generic call
and event routing. In publish-subscribe model Router
has the role of a Broker: –
Broker: Broker acts as a router and routes messages
published to a topic to all subscribers subscribed to the
topic.
RPC model Router
In RPC model Router has the role of a Broker: –
1. Dealer: Dealer acts a router and routes
RPC calls from the Caller to the Callee and
routes results from Callee toCaller.
2. Application Code: Application code runs
on the Clients (Publisher, Subscriber, Callee or
Caller).
THANK YOU
HAPPY LEARNING
