UNIT II
Internet of Things:
IOT is known as the Internet of Things where things are said to be the
communicating devices that can interact with each other using a communication media.
Usually every day some new devices are being integrated which uses IoT devices for its
function. These devices use various sensors and actuators for sending and receiving
data over the internet. It is an ecosystem where the devices share data through a
communication media known as the internet or Iot is an ecosystem of connected
physical object that are accessible through internet. Iot means anything which can be
connected to internet and can be controlled or monitored using internet from smart
devices or PC.
2. Machine to Machine:
This is commonly known as Machine to machine communication. It is a concept
where two or more than two machines communicate with each other without human
interaction using a wired or wireless mechanism. M2M is an technology that helps the
devices to connect between devices without using internet. M2M communications offer
several applications such as security, tracking and tracing, manufacturing and facility
management.
M2M is also named as Machine Type Communication (MTC) in 3GPP ( 3rd
Generation Partnership Project).
M2M is communication could carried over mobile networks, for ex- GSM-GPRS,
CDMA EVDO Networks.
In M2M communication, the role of mobile networks is largely confined to server as a
transport networks.
M2M is only subset of IoT.
Difference between IoT and M2M :
Basis of IoT M2M
Abbreviation Internet of Things Machine to Machine
Devices have objects that are Some degree of intelligence
Intelligence
responsible for decision making is observed in this.
The connection is via Network
Connection type The connection is a point to
and using various communication
used point
types.
Basis of IoT M2M
Traditional protocols and
Communication Internet protocols are used such
communication technology
protocol used as HTTP, FTP, and Telnet.
techniques are used
Data is shared between other
Data is shared with only the
Data Sharing applications that are used to
communicating parties.
improve the end-user experience.
Internet connection is required Devices are not dependent
Internet
for communication on the Internet.
Type of It supports point-to-point
It supports cloud communication
Communication communication.
Involves the usage of both Mostly hardware-based
Computer System
Hardware and Software. technology
A large number of devices yet
Scope Limited Scope for devices.
scope is large.
Business Type Business 2 Business(B2B) and
Business 2 Business (B2B)
used Business 2 Consumer(B2C)
There is no support for Open
Open API support Supports Open API integrations.
APIs
It requires Generic commodity devices. Specialized device solutions.
Communication and device
Centric Information and service centric
centric.
Vertical system solution
Approach used Horizontal enabler approach
approach .
Devices/sensors, connectivity, Device, area networks,
Components
data processing, user interface gateway, Application server.
Smart wearables, Big Data and Sensors, Data and
Examples
Cloud, etc. Information, etc.
SDN and NFV for IOT:
What is SDN?
SDN, or Software-Defined Networking, is a networking technology that
separates the control plane from the data plane. In traditional networks, each network
device (such as a switch or router) has its own control plane, which controls the
routing of traffic. This can lead to a lack of coordination and inefficiencies in the
network.
However, in an SDN architecture, the control plane is centralized in a
software-based controller. This controller can communicate with all the network
devices in the network, allowing the entire network to be managed as a single entity.
This centralized control allows for more efficient routing of traffic, as well as easier
management and troubleshooting of the network.
SDN is being adopted by many organizations, including cloud providers,
telecom companies, and enterprises. Its benefits include increased agility, improved
network performance, and reduced costs.
What is NFV?
NFV, or Network Functions Virtualization, is a virtualization technology that
allows network functions (such as firewalls, load balancers, and intrusion detection
systems) to be run on standard servers, rather than on specialized hardware.
Like virtual servers in a data center, virtual network functions (VNFs) can be
deployed, moved, and scaled dynamically, allowing for more agile and flexible
networks. This can lead to cost savings, as well as increased efficiency and scalability.
NFV is being adopted by many organizations, including telecom companies,
cloud providers, and enterprises. Its benefits include increased agility, improved
network performance, and reduced costs.
While SDN and NFV are different technologies, they are often used together to
create even more flexible and efficient networks. By separating the control plane from
the data plane and virtualizing network functions, organizations can create networks
that are easier to manage, more agile, and more cost-effective.
Key Differences Between SDN and NFV
Software-defined networking (SDN) and network functions virtualization
(NFV) are two technologies that are transforming the networking industry. While both
SDN and NFV aim to make networks more flexible and efficient, they differ in their
approach and implementation. In this article, we will explore the key differences
between SDN and NFV.
Architectural Differences
One of the primary differences between SDN and NFV is their architecture.
SDN separates the control plane from the data plane, allowing for centralized
management of the network. This means that the network can be managed and
configured from a central location, rather than having to configure each individual
network device separately. In contrast, NFV virtualizes network functions, allowing
them to be run on standard servers. This means that network functions, such as
firewalls and load balancers, can be deployed and scaled more easily.
SDN's architecture is well-suited for data center or campus networks, where
centralized control is important. By separating the control plane from the data plane,
SDN can provide greater flexibility and agility in network management. NFV, on the
other hand, is most often used in wide-area networks (WANs), where virtualization
can help reduce the number of physical devices required. By virtualizing network
functions, NFV can help reduce the cost and complexity of WAN deployments.
Deployment Scenarios
Another difference between SDN and NFV is their deployment scenarios. SDN
is typically used in data center or campus networks, where centralized control is
important. SDN can provide greater flexibility and agility in network management,
making it well-suited for these types of environments. NFV, on the other hand, is
most often used in wide-area networks (WANs), where virtualization can help reduce
the number of physical devices required. By virtualizing network functions, NFV can
help reduce the cost and complexity of WAN deployments.
SDN and NFV can also be used together in hybrid deployments. For example,
SDN can be used to manage the network infrastructure, while NFV can be used to
virtualize network functions, such as firewalls and load balancers.
Management and Orchestration
Finally, SDN and NFV differ in terms of management and orchestration.
SDN's centralized architecture makes it easier to manage and orchestrate the network
as a whole.
By separating the control plane from the data plane, SDN can provide a single
point of control for the network. This makes it easier to configure and manage the
network, as well as to troubleshoot issues.
NFV's virtualization, on the other hand, requires more sophisticated
management and orchestration tools to ensure that virtual network functions are
deployed and managed properly. NFV management and orchestration tools must be
able to deploy and manage virtual network functions, as well as to ensure that these
functions are properly integrated into the network. This can be more complex than
managing a traditional network, but it can also provide greater flexibility and agility
in network management.
Advantages and Disadvantages of SDN and NFV
Benefits of SDN
Software-Defined Networking (SDN) has revolutionized the way networks are
managed and controlled. Its advantages include:
Centralized Management: With SDN, the network can be managed centrally,
making it easier to configure and control the network as a whole. This is
particularly useful in large networks where managing each device separately
can be a daunting task.
Improved Network Performance: SDN allows for more efficient routing and
traffic management, which can lead to improved network performance and
reliability. This is because SDN separates the control plane from the data
plane, allowing for more intelligent routing decisions.
Reduced Network Costs: SDN enables the use of lower-cost commodity
switches, which can help reduce network costs. Additionally, SDN can help
reduce operational costs by automating network management tasks.
Benefits of NFV
Network Functions Virtualization (NFV) is another technology that is changing the
way networks are designed and deployed. Its benefits include:
Agile and Flexible Networks: NFV allows for more agile and flexible
networks, which can be deployed and scaled more easily than traditional
networks. This is because NFV virtualizes network functions, making it easier
to deploy new services and applications.
Reduced Network Costs: NFV reduces the need for specialized hardware
devices, which can help reduce network costs. Additionally, NFV can help
reduce operational costs by automating network management tasks.
Challenges and Limitations of SDN
While SDN has many advantages, it also has its challenges and limitations. These
include:
Security Risks: The centralized architecture of SDN makes it vulnerable to
attacks on the controller itself. This can lead to serious security risks if not
properly addressed.
High Deployment Costs: The initial deployment costs of SDN can be high, as
specialized switches and controllers are required. This can make it difficult for
smaller organizations to adopt SDN.
Complex Management: SDN requires more sophisticated management and
orchestration tools than traditional networking. This can make it difficult for
organizations to manage their networks effectively.
Challenges and Limitations of NFV
Like SDN, NFV also has its challenges and limitations. These include:
Management and Orchestration: Ensuring that virtual network functions are
deployed and managed properly can be a challenge. This requires more
sophisticated management and orchestration tools than traditional networking.
Deployment in Certain Environments: NFV can be difficult to deploy in
certain environments, such as those with strict regulatory requirements. This
can limit its adoption in some industries.
Conclusion
SDN and NFV are related but distinct technologies that are transforming the way
networks are designed, deployed, and managed. SDN's centralized architecture allows
for more efficient network management, while NFV's virtualization allows for more
agile and flexible networks. Understanding the similarities and differences between
these two technologies is key to effectively leveraging them in real-world scenarios.
Difference between SDN and NFV :
SDN NFV
SDN architecture NFV is targeted at
mainly focuses on service providers or
data centers. operators.
NFV helps service
providers or operators
SDN separates
to virtualize functions
control plane and
like load balancing,
data forwarding plane
routing, and policy
by centralizing
management by
control and
transferring network
programmability of
functions from
network.
dedicated appliances
to virtual servers.
SDN uses OpenFlow There is no protocol
as a communication determined yet for
protocol. NFV.
SDN supports Open NFV is driven by
Networking ETSI NFV Working
Foundation. group.
Various enterprise
Telecom service
networking software
providers or operators
and hardware
are prime initiative
vendors are initiative
supporters of NFV.
supporters of SDN.
Service providers or
Corporate IT act as a
operators act as a
Business initiator for
Business initiator for
SDN.
NFV.
SDN applications run NFV applications run
on industry-standard on industry-standard
servers or switches. servers.
SDN reduces cost of NFV increases
network because now scalability and agility
SDN NFV
there is no need of as well as speed up
expensive switches & time-to-market as it
routers. dynamically allot
hardware a level of
capacity to network
functions needed at a
particular time.
Application of NFV:
Routers, firewalls,
Application of SDN: gateways
Networking WAN accelerators
Cloud SLA assurance
orchestration Video Servers
Content Delivery
Networks (CDN)
IOT system Management:
IoT device management refers to processes managing the entire lifecycle of Internet
of Things (IoT) devices and sensors, from planning and onboarding, to monitoring and
maintenance, through to retirement.
IoT device management is defined as the collection of processes, tools, and
technologies that help you provision, monitor, and maintain the growing sprawl of connected
objects (also called the Internet of Things endpoints or edge devices) in your home or
enterprise network. This article discusses IoT device management in more detail, the features
you need, and the top software solutions in this segment.
Two factors make IoT device management so important: pull and push.
o There is a clear pull factor, as intelligent IoT device management paves the
way for smarter analytics, more seamless automation, internal efficiencies,
and innovative business models. Business models like servitization (where
equipment is leased out and services are rendered based on IoT data instead
of outright equipment sales) hinge on IoT device management.
o Further, there is a push factor, as consumer adoption of connected devices is
constantly growing. Without IoT device management, employees are likely
to keep adding new endpoints to the organizational network, creating a
massive shadow IT burden.
Key Components of IoT Device Management
o Device onboarding: When an IoT device is switched on for the very
first time, it needs to be onboarded into the network. But unlike
traditional devices, they do not come with a full-fledged,
independent interface to navigate the onboarding process. Checking
credentials, defining authentication protocols, assigning a device
identity, etc., are some of the steps you could expect in device
onboarding.
o Device configuration: Every IoT device on your network must be
configured as per your business needs. For example, in the case of a
fleet of connected trucks, you might want to group specific devices
together as per their usual destination or area of operation.
o Operational diagnostics: Diagnostics can reveal a host of useful
insights into your IoT operations. Most IoT devices would not have
sufficient memory or computing resources to analyze diagnostics on
the device itself, which is why you need a centralized IoT device
management capability.
o Device security: This will become an increasingly important part of
IoT device management. In 2020, as much as 98% of IoT device
traffic in the U.S. was allowed to pass through unencrypted
channels, despite comprising 30% of all endpoints. IoT device
management brings unmapped endpoints into the organizational
oversight and applies necessary security protocols.
o Device maintenance: Apart from updating device firmware to the
latest version, you should also watch out for any security
vulnerabilities that might creep in unnoticed via fresh releases. IoT
device management uses over the air (OTA) updates for device
maintenance, and like onboarding or configuration, this is also
performed in bulk.
o End of life: IoT devices that aren’t in use but continue to be part of
the enterprise network pose a massive security risk – an external
entity could capture data via the device without anyone noticing.
Further, an outdated or non-functional device could cause severe
operational damage. End-of-life policies and processes specify
exactly how an IoT device is to be retired, what are the
decommissioning steps needed, and how to recycle the materials for
a minimal carbon footprint.
Key Must-Have Features of an IoT Device Management Software
o Bulk device onboarding: The software must enable onboarding
using a network key and identification credentials. Device
onboarding must be performed remotely to establish a secure
connection between the endpoint device and the IoT service.
o Remote troubleshooting: There should be support for remote
troubleshooting to quickly resolve user issues and reduce manual
efforts. An integrated governance portal can help resolve issues
across multiple endpoints in a consolidated manner.
o Reports and analytics: IoT devices typically ship with some edge
analytics capabilities. The IoT device management software will be
able to display detailed analytics insights in real-time via GUI
dashboards. This data can also be converted into reports for business
user understanding.
o Robust integrations: Compatibility with your hardware ecosystem
and application codebase (i.e., the language in which they are
written) is an essential feature for this software. It must connect with
downstream data servers and enterprise apps for integrated
workflows.
o Stringent security: The software should equip you with detailed
device logs to detect instances of anomalous use and unauthorized
access. Real-time notifications sent via the software’s dashboard can
help diagnose issues and conduct root-cause analysis quickly.
Simple Network Management Protocol (SNMP):\
Simple Network Management Protocol (SNMP) is a widely used protocol for
network management that provides a standardized framework for monitoring and
managing network devices such as routers, switches, servers, printers,firewalls, and
load balancer. It 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.
Architecture of SNMP
There are mainly three main components in SNMP architecture:
SNMP Manager: It is a centralized system used to monitor the network. It is also
known as a Network Management Station (NMS). 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.
SNMP agent: It is a software management software module installed on a managed
device. 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.
Management Information Base:MIB consists of information on resources that are
to be managed. 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 , and EGP , ICMP , TCP are the eight categories that
make up MIB. The MIB object is home to these groups.
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.
SetRequest : 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.
Trap : These are the message sent by the agent without being requested by the
manager. It is sent when a fault has occurred.
InformRequest : 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.
SNMP Security Levels
noAuthNoPriv: This (no authentication, no privacy) security level uses a
community string for authentication and no encryption for privacy.
authNopriv: This security level ( authentication , no privacy) uses HMAC with
Md5 for authentication and no encryption is used for privacy.
authPriv: This security level (authentication, privacy) uses HMAC with MD5 or
SHA for authentication and encryption uses the DES-56 algorithm.
Versions of SNMP
SNMPv1: It uses community strings for authentication and uses UDP
only. SNMPv1 is the first version of the protocol. It is described in RFCs 1155 and
1157 and is simple to set up.
SNMPv2c: It uses community strings for authentication. It uses UDP but can be
configured to use TCP. Improved MIB structure elements, transport mappings, and
protocol packet types are all included in this updated version. However, it also
makes use of the current “community-based” SNMPv1 administrative structure,
which is why the version is called SNMPv2c. RFC 1901, RFC 1905, and RFC 1906
all describe it.
SNMPv3: It uses Hash-based MAC with MD5 or SHA for authentication and DES-
56 for privacy. This version uses TCP. Therefore, the conclusion is the higher the
version of SNMP, the more secure it will be. NMPv3 provides the remote
configuration of SNMP entities. This is the most secure version to date because it
also includes authentication and encryption, which may be used alone or in
combination. RFC 1905, RFC 1906, RFC 2571, RFC 2572, RFC 2574, and RFC
2575.6 are the RFCs for SNMPv3.
Characteristics of SNMP
SNMP is used to monitor network.
It detects any network faults.
It can also be used to configure remote devices.
It allows a standardized way of collecting information about all kinds of devices
from various manufacturers among the networking industry.
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 forLAN based managed object.
It offers the best direct manager agent interface.
Limitation of SNMP
It does not scale well.
There is no object orietned data view.
It has no standard control definition.
It has many implementation specific (private MIB) extensions.
It has high communication overhead due to polling
Conclusion
The Simple Network Management Protocol (SNMP) is an important protocol for
managing and monitoring network-connected devices in IP networks. It enables
administrators to effectively monitor network performance, discover and address errors,
and configure remote devices. While SNMP’s simplicity and popularity provide
significant advantages, it also has drawbacks, such as scalability concerns and high
communication costs. Despite its drawbacks, SNMP remains an important in network
management.
YANG
YANG is a data modeling language. The YANG model defines a hierarchical
data structure, which can be used for operations based on network configuration
management protocols (such as NETCONF/RESTCONF). The operations
include configuration, status data, remote procedure calls (RPCs), and
notifications. Compared with the SNMP model MIB, YANG is more
hierarchical, can distinguish between configurations and status, and provides
high extensibility.
Overview of the YANG Model
Positioned as a next-generation modeling language, YANG is used to build data models.
It is used to model the configuration data, status data, RPCs, and notifications used by
network configuration management protocols (such as NETCONF and RESTCONF). YANG
generates YANG models (also called YANG files) by describing data structures, data
integrity constraints, and data operations.
YANG is defined in the following RFC standards:
RFC 6020: In 2010, the Internet Engineering Task Force (IETF) defined YANG for the
first time. YANG is a data modeling language for NETCONF.
RFC 6021: In 2010, the IETF defined various data types commonly used in network
communication technologies. This allows us to import and use predefined network data
types without redefining them when building YANG models.
RFC 6991: In 2013, the IETF added data types to the YANG model on the basis of RFC
6021.
RFC 7950: In 2016, the IETF released YANG1.1 to correct ambiguity and defects in the
initial version (RFC 6020).
Through ongoing standardization, YANG is gradually becoming a mainstream data
description specification in the industry. Standards organizations, vendors, carriers, and
OTTs all define their own YANG models. As shown in the following figure, the YANG
model is integrated on the devices, which function as the servers. Network
administrators can use NETCONF or RESTCONF to centrally manage, configure, and
monitor various YANG-capable network devices, simplifying network O&M and reducing
O&M costs.
NETOPEER:
Netopeer is a set of NETCONF tools built on the libnetconf library. It allows operators to
connect to their NETCONF-enabled devices as well as developers to allow control their
devices via NETCONF. More information about NETCONF protocol can be found at
NETCONF WG.
IoTSystemsManagementwith NETCONF-YANG
YANGisadatamodelinglanguageusedtomodelconfigurationandstatedata manupulated
by the NETCONF protocol.
ThegenericapproachofIoTdevicemanagementweithNETCONF-YANG. Roles of
various components are:
1) ManagementSystem
2) ManagementAPI
3) TransactionManager
4) RollbackManager
5) DataModelManager
6) ConfigurationValidator
7) ConfigurationDatabase
8) ConfigurationAPI
9) DataProviderAPI
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) ManagementAPI:allowsmanagementapplicationtostart NETCONFsessions.
3) Transaction Manager: executes all the NETCONF transactions and ensures
that ACID properties hold true for thetrasactions.
4) RollbackManager:isresponsibleforgeneratingallthetransaction
necessarytorollbackacurrentconfigurationtoitsoriginalstate.
5) 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 data model.
6) Configuration Validator: checks iftheresulting configurationafter applying a
transaction would be a valid configuration.
7) ConfigurationDatabase:containsbothconfigurationandoperationaldata.
8) Configuration API : Using the configuration API the application on the IoT
device can be read configuration data from the configuration datastore and write
opeartional data to the opearationaldatastore.
9) Data Provider API: Applications onthe 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 opeartionaldata.
StepsforIoTdeviceManagementwithNETCONF-YANG
1) CreateaYANGmodelofthesystemthat definestheconfigurationandstate data of
the system.
2) CompletetheYANGmodelwiththe‗Inctool‘whichcomes withLibnetconf.
3) FillintheIoTdevicemangementcodeintheTransAPImodule.
4) BuildthecallbacksCfiletogeneratethe libraryfile.
5) Load the YANG module and the TransAPImodule into the Netopeer server using
Netopeer managertool.
6) The operator can now connect from the management system to the Netopeer
server using the NetopeerCLI.
Operator can issue NETCONF commands from the Netopeer CLI. Command can be issued to
changew the configurationdsta, getoperationaldat orexecute an RPC on the IoTdevice