The document provides an overview of Software Defined Networking (SDN) and Network Function Virtualization (NFV), highlighting their fundamental characteristics, operational components, and benefits. It explains the separation of control and data planes in SDNs, centralized management of network operations, and the virtualization of network functions in NFV, which allows for better resource utilization and operational efficiency. Additionally, it discusses tools like OpenDaylight and various use cases for both SDN and NFV technologies in modern networking environments.

1. Internet of Things
(20CS002)
Department of Computer Science and Engineering
Vignan's Foundation for Science, Technology & Research

2. The Internet: Remarkable story

3. The Internet Landscape

4. Why can't we innovate?

5. Networks are hard to manage

6. Traditional Computer networks

7. Traditional Computer networks

8. Traditional Computer networks

9. Traditional Network Router
• Router can be partitioned into control and data plane
• Management plane/ configuration
• Control plane / Decision: OSPF (Open Shortest Path First)
• Data plane / Forwarding
Router
Management/Policy plane
Configuration / CLI / GUI
Static routes
Control plane
Neighbor
table
OSPF
Link state
database
IP routing
table
Forwarding table
Data plane
Adjacent Router Adjacent Router
Data plane
Control plane
OSPF
Routin
g
Routing
Control plane
OSP
F
Switchin
g
Switching
Data plane

10. Two possible views on SDN

11. SDN Layers
Different layers in OpenFlow
SDN Concept
Firmware handling instructions from control
plane (e.g Open Vswitch) via flow tables.
Hardware (switches)
Make decisions and instructions
Routing, load balancers, security, etc.
(Application Plane)

12. Software-Defined Network with key Abstractions
Network Operating System
Routing Traffic
Engineering
Other
Applications
Well-defined
API
Network Map
Abstraction
Forwarding
Forwarding
Forwarding
Forwarding
Separation of Data
and Control
Plane
Network
Virtualizatio
n
Security
Data Palne
Control Plane
Application
Plane
Instructions Instructions
Instructions
Instructions

13. Directly programmable: Network control is directly programmable because it is
decoupled from forwarding functions.
Agile: Abstracting control from forwarding lets administrators dynamically adjust
network-wide traffic flow to meet changing needs.
Centrally managed: Network intelligence is (logically) centralized in software-based
SDN controllers that maintain a global view of the network, which appears to
applications and policy engines as a single, logical switch.
Programmatically configured: SDN lets network managers configure, manage,
secure, and optimize network resources very quickly via dynamic, automated SDN
programs, which they can write themselves because the programs do not depend on
proprietary software.
Open standards-based and vendor-neutral: When implemented through open
standards, SDN simplifies network design and operation because instructions are
provided by SDN controllers instead of multiple, vendor-specific devices and protocols.
SDN Characteristics

14. Software Defined Networking (SDN)

15. Plane Separation
• The first fundamental characteristic of SDN is the separation of planes
• Data plane, implemented in the device
• Control plane, implemented by a centralized controller
Traditional networks SDN networks
W. Stallings, “Foundations of Modern Networking: SDN, NFV, QoE, IoT, and Cloud” Addison Wesley, 2017.

16. Plane Separation – Data Plane
• The data plane implements forwarding functionality (logic and tables for
choosing how to deal with incoming packets)
• Forwarding based on MAC address, IP address, VLAN ID, etc.
• The data plane may forward, drop, consume, transform, replicate an incoming
packet
Traditional networks SDN networks
W. Stallings, “Foundations of Modern Networking: SDN, NFV, QoE, IoT, and Cloud” Addison Wesley, 2017.

17. Plane Separation – Control Plane
• The algorithms used to program the data plane reside in the control plane
• Many protocols / algorithms require global knowledge (for example, OSPF,
BGP)
• The control plane is moved off of the switching device, onto a centralized
controller
Traditional networks SDN networks
W. Stallings, “Foundations of Modern Networking: SDN, NFV, QoE, IoT, and Cloud” Addison Wesley, 2017.

18. SDN Operation
• Basic components (bottom-up)
• SDN switches (e.g., Open vSwitch)
• Controller (e.g., ONOS controller)
• Applications (e.g., OpenFlow, forwarding)
Global view
app
BGP app
IDS app Business app
SDN Controller
Northbound (REST, JSON)
Southbound (OpenFlow)
Control plane
Data plane
Flow table

19. SDN Operation – Switches
• Forwarding information is stored in flow
tables
• The flow tables reside on the network
device and consist of a series of flow
entries and actions to perform when a
packet matches an entry
• If the SDN device finds a match, it takes
the appropriate action (e.g. forward the
packet)
• If it does not find a match, it can either
drop the packet or pass it to the controller
Global view
app
BGP app
IDS app Business app
SDN Controller
Northbound (REST, JSON)
Southbound (OpenFlow)
Control plane
Data plane
Flow table

20. SDN Operation – Controller
• SDN controller implements control plane
functionality
• It allows the SDN application to define flows
on devices and to help the application to
respond to packets forwarded to the
controller by devices
• It maintains a global view of the network
Global view
app
BGP app
IDS app Business app
SDN Controller
Northbound (REST, JSON)
Southbound (OpenFlow)
Control plane
Data plane
Flow table

21. SDN Operation – Applications
• SDN applications are built on top of the
controller
• Software applications can implement
forwarding, routing, overlay, multipath,
access control, etc.
• The application is driven by events
coming from the controller and from
external inputs
Global view
app
BGP app
IDS app Business app
SDN Controller
Northbound (REST, JSON)
Southbound (OpenFlow)
Control plane
Data plane
Flow table

22. Example: Campus/WAN (Traditional)

23. Example: Campus/WAN (SDN)

24. Example: Data Centre (Traditional)

25. Example: Data Centre (SDN)

26. Tool: OpenDaylight (Control
Plane)
•OpenDaylight (ODL) is a modular open platform for customizing and
automating networks of any size and scale.
•The OpenDaylight Project arose out of the SDN movement, with a clear
focus on network programmability.
•It was designed from the outset as a foundation for commercial solutions
that address a variety of use cases in existing network environments.

27. Tool: OpenDaylight (Control Plane)

28. OpenDaylight Controller : Installation
OpenDaylight Controller runs in a JVM. Being a Java application, it
can potentially run on any operating system that supports Java.
A recent Linux distribution
• Java Virtual Machine 1.7
Note: The following instructions assumes:
• Install OpenDaylight Controller on local Linux machine
•Use the Mininet VM to create a virtual network OpenDaylight
Controller has not been tested in other environments.

29. Download and Run the controller
• The source code of the OpenDaylight Controller is in a directory called
opendaylight. In this directory (the coresponding directory in the git
repository is usually the
distribution/opendaylight/target/distribution.opendaylight-0.1.6-
SNAPSHOT-osgipackage/opendaylight), you will see the following files:
• run.sh — launches the OpenDaylight Controller on Linux/Unix systems
• run.bat — launches OpenDaylight Controller on Windows systems
• version.properties — indicates the build version
• configuration — basic initialization files (internal to OpenDaylight
Controller)
• lib — Java libraries
• plugins — OpenDaylight Controller's OSGi plugins

30. Download and Run the controller
• Enter ./run.sh or ./run.bat with administrator privileges to launch the
OpenDaylight Controller application.
• Navigate to http://controller-ip:8080 to open the web interface, then
use the following credentials to log in:
• User: admin
• Password: admin
• Once logged in, please ensure to change the default admin password.
To do so, navigate to the admin menu in the top right corner of the web
interface. Select Users and then select the admin user. A pop-up will
then present the option to Change Password.

31. OpenDaylight (Control Plane)

32. Network Virtual Function

33. | Have fast standard hardware
- White box implementation
| Decouple network functions from proprietary
hardware appliances
- Software implementation of network
| Standard API’s between Modules
Network Virtual Function (NFV)
“Leverage standard IT virtualization
technology to consolidate many
network equipment types onto
industry standard high-volume
servers, switches, and storage.”
Traditional Network Model
DPI
Firewall
Load
Balancer
NAT
CDN
Session Border
Controller
PE Router
IDS
Traditional Network Model
ORCHESTRATED, AUTOMATIC
& REMOTE INSTALL
Standard High
Volume Servers/
Storages/Switches
NFV Model
CDN
DPILoad Balancer NAT VIRTUAL
APPLIANCES
Firewall PE Router

34. NFV :: Network Functions Virtualization
• Network Functions Virtualization is about implementing network functions in
software - that today run on proprietary hardware - leveraging (high volume)
standard servers and IT virtualization
• Supports multi-versioning and multi-tenancy of network functions, which allows use of
a single physical platform for different applications, users and tenants
• Enables new ways to implement resilience, service assurance, test and diagnostics and
security surveillance
• Provides opportunities for pure software players
• Facilitates innovation towards new network functions and services that are only
practical in a pure software network environment
• Applicable to any data plane packet processing and control plane functions, in
fixed or mobile networks
• NFV will only scale if management and configuration of functions can be automated
• NFV aims to ultimately transform the way network operators architect and operate their
networks, but change can be incremental
Source: Adapted from D. Lopez Telefonica I+D, NFV

35. Benefits & Promises of NFV
• Reduced equipment costs (CAPEX)
– through consolidating equipment and economies of scale of IT industry.
• Increased speed of time to market
– by minimising the typical network operator cycle of innovation.
• Availability of network appliance multi-version and multi-tenancy,
– allows a single platform for different applications, users and tenants.
• Enables a variety of eco-systems and encourages openness.
• Encouraging innovation to bring new services and generate new revenue
streams.

36. Benefits & Promises of NFV
• Flexibility to easily, rapidly, dynamically provision and
instantiate new services in various locations
• Improved operational efficiency
• by taking advantage of the higher uniformity of the physical
network platform and its homogeneity to other support platforms.
• Software-oriented innovation to rapidly prototype and test new
services and generate new revenue streams
• More service differentiation & customization
• Reduced (OPEX) operational costs: reduced power, reduced space,
improved network monitoring
• IT-oriented skillset and talent
Source: Adapted from D. Lopez Telefonica I+D,

37. Some Use Case Examples Driving NFV
• Switching elements: BNG, CG-NAT, routers.
• Mobile network nodes: HLR/HSS, MME, SGSN, GGSN/PDN-GW.
• Home networks: Functions contained in home routers and set top boxes to create
virtualised home environments.
• Tunnelling gateway elements: IPSec/SSL VPN gateways.
• Traffic analysis: DPI, QoE measurement.
• Service Assurance: SLA monitoring, Test and Diagnostics.
• NGN signalling: SBCs, IMS.
• Converged and network-wide functions: AAA servers, policy control and charging
platforms.
• Application-level optimisation: CDNs, Cache Servers, Load Balancers, Application
Accelerators.
• Security functions: Firewalls, virus scanners, intrusion detection systems, spam
protection.

38. Need of NFV?
1.Virtualization: Use network resource without worrying about where it is physically
located, how much it is, how it is organized, etc.
2.Orchestration: Manage thousands of devices
3.Programmable: Should be able to change behavior on the fly.
4.Dynamic Scaling: Should be able to change size, quantity, as a F(load)
5.Automation: Let machines / software do humans’ work
6.Visibility: Monitor resources, connectivity
7.Performance: Optimize network device utilization
8.Multi-tenancy: Slice the network for different customers (as-a-Service)
9.Service Integration: Let network management play nice with OSS/BSS
10.Openness: Full choice of modular plug-ins
Note: These are exactly the same reasons why we need/want SDN.
Source: Adapted from Raj

39. Revisiting Layers
Rack, cable, power, cooling
Switching infrastructure
Network Infrastructure
Hypervisors
Operating Systems
Applications
Rack, cable, power, cooling
Switching infrastructure
Computer infrastructure
Operating systems
Network functions
Applications
Hypervisors

40. NFV Layers
Virtual
Compute
Virtual Storage
Virtual
Network
Virtualization Layer
Compute Storage Network
VNF VNF VNF VNF
VNF Instances
VNF VNF VNF
VNF VNF
End
Point
End
Point
Logical Abstractions
Software Instances
Virtual Resources
Virtualization SW
HW Resources
Logical Links
VNF: Virtualized Network Function

41. NFV Layers
• Network Function (NF): Functional building block with a well defined interfaces
and well defined functional behavior
• Virtualized Network Function (VNF): Software implementation of NF that can be
deployed in a virtualized infrastructure
• VNF Set: Connectivity between VNFs is not specified, e.g.,
residential gateways
• VNF Forwarding Graph: Service chain when network connectivity order is important,
e.g., firewall, NAT, load balancer
• NFV Infrastructure (NFVI): Hardware and software required to deploy, mange and
execute VNFs including computation, networking, and storage.
• NFV Orchestrator: Automates the deployment, operation, management, coordination
of VNFs and NFVI.
Source: Adapted from Raj

42. NFV Use Cases
ETSI Formalized NFV Use Cases Potentially Virtualized Functions
Network Functions Virtualization Infrastructure as a Service vNAT, vFW, vLB, vRR, vVPN, vRouter
Virtual Network Function as a Service (VNFaaS) vCPE, vPE
Virtual Network Platform as a Service (VNPaaS) vPrivateCloud
VNF Forwarding Graphs vPE-F
Virtualization of Mobile Core Networks and IMS vEPC (vS/P-GW, vMME, vPCRF, vSGSN, vGGSN, vGiLan)
vIMS (vP/S/I-CSCF, vMGCF, vAS)
Virtualization of Mobile Base Station vMAC, vRLC, vPDCP, vRRC, vCOMP, vBBU
Virtualization of the Home Environment vBNG, vRGW, vSTB
Virtualization of CDNs vCDN
Fixed Access Network Functions Virtualizations vOLT, vDSLAM, vONU, vONT, vMDU, vDPU
ETSI: The European Telecommunications Standards Institute

43. SDN, NFV Growing Together
Source: NEC

44. Cloud vs. NFV

45. Cloud vs. NFV
Source: Adapted from D. Lopez Telefonica I+D,

46. SDN poses to NFV
• SDN poses to NFV:
– Central point of contact / Orchestrate VNFs (NSC)
Source:
Uwe Michel
T-Systems

47. Networking with SDN & NFV

48. Balance Between SDN and NFV
Source: Adapted from D. Lopez Telefonica I+D,

49. Scope of NFV and OpenFlow/SDN

50. Differences Between NFV and SDN
• NFV: re-definition of network equipment architecture
• NFV was born to meet Service Provider (SP) needs:
– Lower CAPEX by reducing/eliminating proprietary hardware
– Consolidate multiple network functions onto industry standard
platforms
• SDN: re-definition of network architecture
• SDN comes from the IT world:
– Separate the data and control layers, while
centralizing the control
– Deliver the ability to program network behavior using well-
defined interfaces

51. Differences Between NFV and SDN
Software Defined Networking (SDN) Comparison
Features
Network Function Virtualization (NFV)
Separate control and data, centralize control
and programmability of network
Basic Concept Relocate network functions from dedicated
appliances to generic servers
Campus, data center/cloud Target Location Service provider network
Commodity servers and switches Target Devices Commodity servers and switches
Cloud Orchestration and networking Initial Application Routers, Firewalls, gateways, CDN, WAN
accelerators, SLS assurance
OpenFlow New Protocols None
Open Networking Foundation (ONF) Formalization European Telecommunications Standards
Institute (ETSI) NFV Working Group

52. NFV : Network function Virtualization
enB SGw GGSN DPI PGw
MME
HSS OCS PCRF
Internet
Traditional LTE Network
C G N AT
DNS

53. NFV : Network function Virtualization
Internet
Traditional LTE Network
CGNAT
PGw HLR/HSS MME OCS PCRF DNS
Specialized Appliances / Purpose Build
Combination of Capacity & Functionality
Router
Switch

54. NFV
- Softwarization
- Virtualization
- Orchestration
Purpose Build hardware
to Generic Hardware
App running on
Software
Separation of
Network
Function & Capacity
Easy Capacity Scale
Up /
Down
VM are Building
Blocks
Internet
Virtual Network
Generic Hardware
Features of NFV
V V V
M M M
V V V
M M M
V V V
M M M
V V V
M M M
NFV : Network function Virtualization

55. NFV Layers
Governing Specs
October 2012
White Paper
• AT&T USA
• BT
• CenturyLink
• China Mobile
• Colt
• Deutsche Telekom
• KDDI
• Orange
• Telecom Italia
• Telefonica
• Telstra
• Verizon
VM VM VM VM VM
VM
VM
NFV Architecture

56. Internet
Cloud LTE
Network
Components of NFV
MME
MSC CRAN
PCRF
SMSC
Switch
Router
Virtual Machines Virtual Machines
HLR PGw
Each Application running on
One or Multiple VMs
Generic Hardware
Virtual Machines
vSMSC vMSC vHLR vSGSN vGGSN
NFV LTE network

57. NFV Architecture
NFV Layers
OSS /
BSS
Orchestration
Service , VNF &
Infra description
EM1
VNF1
vSMSC
EM2
VNF2
vMSC
EM3
VNF3
vHLR
Virtual
Compute
Virtual
Memory
Virtual
Network
Virtualization Layer
Compute Memory Network
VNF Manager
VIM Virtualized
Infrastructure
Manager
NF-Vi
NFVI
Ve-Vnfm
Se-Ma
Os-Ma
Or-Vnfm
Vi-Vnfm
Or-Vi
NFV Management
& Orchestration
VNF ( Virtual
Network Function)
NFVI
(Network Function Virtualization Infrastructure)
• Manage Physical part in NFVI
• Hypervisor : Responsible for abstracting
physical resources into virtual resources
VIM
(Virtualized Infrastructure Manager)
• Management / Control for NFVI
• Also manages Reports & events
Blades of HP / DELL
Hardware

58. NFV Layers
OSS /
BSS
Orchestration
Service , VNF &
Infra description
EM1 EM2 EM3
Virtual
Compute
Virtual
Memory
Virtual
Network
Virtualization Layer
Compute Memory Network
VNF Manager
VIM Virtualized
Infrastructure
Manager
NF-Vi
NFVI
Ve-Vnfm
Se-Ma
Os-Ma
Or-Vnfm
Vi-Vnfm
Or-Vi
NFV Management
& Orchestration
VNF
• A VNF is the basic block in NFV
Architecture , Example :-
• vIMS
• vMME
• vMSC
• vSwitch
• vRouter
• EM (Element Management) FCAPS of
Application such as Link down , KPI
Degradation etc.
VNF ( Virtual
Network Function)
VNF Manager
• Life cycle VNFs :
• setting up/
• Maintaining
• Tearing down
• FCAPS of Virtualization and VNF
NFV Architecture
VNF1
vSMSC
VNF2
vMSC
VNF3
vHLR
VM VM VM VM VM VM

59. NFV Architecture
FCAPS Layers
OSS /
BSS
Orchestration
Service , VNF &
Infra description
EM1 EM2 EM3
Virtual
Compute
Virtual
Memory
Virtual
Network
Virtualization Layer
Compute Memory Network
VNF Manager
VIM Virtualized
Infrastructure
Manager
NF-Vi
NFVI
Ve-Vnfm
Se-Ma
Os-Ma
Or-Vnfm
Vi-Vnfm
Or-Vi
NFV Management
& Orchestration
VNF ( Virtual
Network Function)
VNF1
vSMSC
VNF2
vMSC
VNF3
vHLR
VM VM VM VM VM VM
EM
• Telecom
Virtualized
Nodes , Ex :
vMSCs
VNF Manager
• VNFs
VIM
• NFVI ,VMs
• Hardware

60. NFV Architecture
NFV Layers
NFV Orchestrator (NFVO)
• Key to Automation of SDN &
NFV
• Performs :-
• Resource orchestration
• Network service
orchestration
• Global resource management of
NFVI resources via VNFM & VIM
• Allocating and scaling resources
• Single Orchestrator for NFV
service
OSS /
BSS
Orchestration
Service , VNF &
Infra description
EM1
VNF1
EM2
VNF2
EM3
VNF3
Virtual
Compute
Virtual
Memory
Virtual
Network
Virtualization Layer
Compute Memory Network
VNF Manager
VIM Virtualized
Infrastructure
Manager
NF-Vi
NFVI
Ve-Vnfm
Se-Ma
Os-Ma
Or-Vnfm
Vi-Vnfm
Or-Vi
NFV Management
& Orchestration
VNF ( Virtual
Network Function)

61. IoT system and network management

62. Need for IoT Systems Management
IoT devices once installed may need software updates or bug fixes.
Sometimes it has to be replaced or repaired. This may result in
downtime. In order to solve, the following things are required.
• Automating configuration
• Monitoring operational and statistical data
• Improved reliability
• System-wide configuration
• Multiple system configuration
• Retrieving and reusing configurations
Ref: Internet of Things: A Hands-on Approach by Arshdeep Bahga and Vijay K. Madisetti

63. Network Management
• Network management includes deployment, integration, and coordination of the
hardware, software. To monitor, test, poll, configure, analyze, and control
the network and element resources to meet the real-time, operational performance,
and quality of service requirements at a reasonable cost.
• Performance management : to quantify, measure, report, analyze and control the
performance of network components.
• Fault management : to log, detect, and respond to fault conditions in the network.
• Configuration management : allows a network manager to track which devices are
on the managed network and the hardware and software configurations of these
devices.
• Accounting management : allows the network manager to specify, log, and control
user and devices access to network resources.
• Security management : to control access to network resources according to
some well defined policy.

64. Protocols for Network management
• CMISE/CMIP (the Common Management Information Services
Element/Common Management Information Protocol )
• SNMP (Simple Network Management Protocol)
Disadvantages of CMIP over SNMP
1.CMIP protocol takes more system resources than SNMP by a factor of
ten
2.CMIP is large and complete management system that only the best
equipped networks can afford to run it.

65. Evolution of SNMP
• In early days of the ARPANET, they used ping to detect the problem.
• When ARPANET turned into WWW, better tools to network management
are needed.
• SNMP provided a systematic way of monitoring and managing a computer
network.
• Three versions in SNMP
SNMPv1 : The initial implementation of the SNMP protocol, which is
described in RFC 1098 and RFC 1157
SNMPv2 : An improved version of SNMPv1 that includes additional
protocol operations for the SNMPv2 Structure of Management Information
(SMI) (RFC 1441-1452)
SNMPv3

66. What is it?
A Protocol that Facilitates the exchange of management information between
network devices. The preferred transport protocol for carrying SNMP messages
is UDP and the preferred port number for the SNMP is port 161. Port 162 is used for
trap messages.
Why was it developed?
To control and monitor status of network devices
How is it beneficial?
Enables network administrators to:
Manage network performance
Find and solve network problems
Plan for network growth
Simple Network Management Protocol (SNMP)

67. Management Station
NMS
User Interface
Network
Management
Application
MIB MIB
MIB
AGENT AGENT AGENT
S
N
M
P
SNMP
S
N
M
P
Managed
Devices
Network
Management
Architecture
Router

68. • Network Management station
• Collects and stores management information, and makes this information
available to NMS using SNMP
• Could be a work station or PC
• Network Management System (NMS)
• Executes applications that monitor and control managed devices
• Agent: A network-management software module that resides in a managed
device
• Management Information Base (MIB): Used by both the manager and the
agent to store and exchange management information
SNMP Basic Components

69. Management stations
• General-purpose computers running special software
• The management station contain one or more processes that communicate with
agents over the network, issuing commands and getting responses
• An NMS (network management station) executes applications that monitor and
control managed devices.
• It controls the collection, processing, analysis, and display of network
management information
• NMSs provide the bulk of the processing and memory resources required for
network management.

70. Managed device and Agent
• A managed device is a network node that contains an SNMP agent and that resides
on a managed network
• Managed devices collect and store management information and make this
information available to NMSs using SNMP
• A managed device might be a host, router, bridge, hub, printer, or modem.
• A network-management software module that resides in a managed device that
communicates with management stations.
• An agent has local knowledge of management information and translates that
information into a form compatible with SNMP.

71. SNMP Management information base
• Each device maintains one or more variables that describes its state. These
variables are called objects.
• The collection of all objects in a network is given in a datastructure called
MIB (management information base)
• MIBs are accessed using a network-management protocol such as SNMP
and identified by object identifiers.
• The MIB hierarchy can be depicted as a tree with a nameless root, the levels
of which are assigned by different organizations.
• When an SNMP manger requests information from an SNMP agent, the
SNMP agent retrieves the current value of the requested information from
the Management Information Base (MIB).

72. Network management protocol
• The protocol runs between the managing entity and managed device.
• Allows managing entity to query the status of managed device
• Agents use it to inform the managing entity of exceptional events.
• Data are sent using the ASN.1(abstract syntax notation one) transfer
syntax.
• The structure of management information, SMI, is the language used
to define the management information residing in a managed-network
entity. SMI is used to ensure that the syntax and semantics of the
network management data are well defined.

73. Information Types
An SNMP manager can request the following types of information
from the SNMP agents that it monitors:
• Network protocol identification and statistics.
• Dynamic identification of devices attached to the network.
• Hardware and software configuration data.
• Device error and event messages.
• Program and application usage statistics.

74. SNMP Messages
• SNMP sends operation requests and responses as SNMP messages. An
SNMP message consists of an SNMP protocol data unit (PDU) plus
additional message header elements defined by the relevant RFC.
• An SNMP agent sends information in two situations:
1. When it responds to a request from an SNMP manager and
2. When a trap event occurs.

75. SNMP Message Types
• Get: Accesses and retrieves the current value of one or more MIB objects on an
SNMP agent.
• GetResponse: Replies to a Get, GetNext, or Set operation.
• GetNext: Obtains the information from selected columns from one or more rows of a
table.
• GetBulk: Accesses multiple values at one time without using GetNext message.
• Set: Changes the current value of an MIB object.
• Trap: Notifies the SNMP manager when an unexpected event occurs locally on the
managed host.
• All the above messages except Trap and GetResponse are from Manager to Host.

83. Windows Server 2003 SNMP Components at Each TCP/IP
Layer

84. Windows Server 2003 SNMP Components
Component
Name
Associated Programs Component Type Description
Microsoft SNMP
Service
Snmp.exe Agent Receives SNMP requests and delivers them to the appropriate
SNMP subagent DLL for processing. The service is also responsible
for intercepting events (traps) from the SNMP subagents and
forwarding trap messages to the appropriate management systems.
SNMP Subagents Inetmib1.dll,
Hostmib.dll,
Lmmib2.dll, and
others
Agent Provides a set of entry points. When an SNMP request is received,
the SNMP service delivers it to the appropriate subagent by calling
one of these entry points. After the subagent processes the
message, it passes the information back to the SNMP service, which
then forwards the message to the SNMP manager.
SNMP Utility API Snmpapi.dll Both Agent and
Manager
Provides utilities that the SNMP service uses for memory
management operations, address-decoding routines, object identifier
handling routines, and so forth.
Provides a set of routines that SNMP subagents use to handle and
order SNMP objects.
Although use of the Snmpapi.dll is not required, the framework
defined by this tool greatly facilitates the development of new
SNMP subagents.
SNMP Trap
Service
Snmptrap.exe Manager Uses the WinSNMP API to forward a trap message sent by an
SNMP agent to the appropriate SNMP manager application

85. Windows Server 2003 SNMP Components
Component
Name
Associated
Programs
Component Type Description
WinSNMP API
-and-
Management API
Wsnmp32.dll
-and-
Mgmtapi.dll
Manager Helps develop SNMP management software applications:
•The WinSNMP API provides a set of functions for encoding,
decoding, sending, and receiving SNMP messages
.•The Management API is a simple API that resides on top of the
WinSNMP and SNMP Utility APIs. It provides a limited set of
functions that you can use to develop basic SNMP management
applications quickly.
SNMP Manager
Application
Snmputil.exe Manager Provides a basic command-line utility with which to retrieve
information from any SNMP agent in your network. This example
of a management application was developed using the
Management API.

86. Limitations of SNMP
• SNMP is stateless in nature and each SNMP request contains all the
information required 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 is no support for acknowledgement of requests.
• It is difficult to differentiate between configuration and state data in MIBs.
• Earlier versions of SNMP did not have strong security features.

87. Network Configuration Protocol
• Network Configuration Protocol (NETCONF) is a network management protocol allowing a
network management system (NMS) to deliver, modify, and delete configurations of network
devices.
• Standard application programming interfaces (APIs) are available on network devices for the
NMS to manage the devices using NETCONF.
• NETCONF uses Extensible Markup Language (XML)-based data encoding for the
configuration data and protocol messages, and uses a simple remote procedure call (RPC)
mechanism to implement communication between a client and a server.
• A client can be a script or an application running on an NMS. A server is typically a network
device.

88. Need of NETCONF
• Network automation is one of the key requirements for networks in the cloud
era, including fast and on-demand service provisioning and
automatic operations and maintenance (O&M).
• The above mentioned requirement cannot be met by the conventional network
management methods: command-line interface (CLI) and SNMP.
• NETCONF comes in, which is gaining momentum in network automation.

89. Disadvantages of CLI and SNMP
• CLI-based configuration is complex and differs greatly according to vendors.
- CLIs vary significantly by vendor, so users have to learn and develop adaptation scripts for
each vendor's CLI. Additionally, frequent changes to the CLI structure and syntax make it
difficult to maintain CLI scripts.
• SNMP does not support the transaction mechanism, resulting in a low configuration
efficiency. Therefore, it is typically used for monitoring purposes.
- SNMP uses the User Datagram Protocol (UDP), which cannot provide reliable and
ordered data transmission and lacks an effective security mechanism.
• SNMP does not have a mechanism for submitting configuration transactions. Therefore,
configuration is performed separately for each object, not for each service. When multiple
objects need to be configured, unknown impacts may be caused on the network if some objects
are successfully configured and some fail to be configured.
• SNMP manages device configuration on a per-device basis and does not support network-level
configuration or multi-device configuration collaboration.

90. Advantages of NETCONF
• NETCONF uses a hierarchical protocol framework, making it more suitable for on-demand,
automated, and big data requirements of cloud-based networks.
• NETCONF uses XML encoding to define messages and uses the RPC mechanism to modify
configuration data. This facilitates configuration data management and interoperability
between devices from different vendors.
• NETCONF performs operations on devices based on the YANG model, reducing network
faults caused by manual configuration errors.
• NETCONF provides security mechanisms such as authentication and authorization to ensure
message transmission security.
• NETCONF provides a transaction mechanism to support data classification, storage, and
migration, phase-based submission, configuration isolation, as well as overall configuration
delivery, verification, and rollback, minimizing the impact on network services.
• NETCONF defines a variety of operation interfaces and supports extension on basis of
capabilities. This allows vendors to define their own protocol operations, so as to implement
unique management functions.

91. How Does NETCONF Work?

92. How Does NETCONF Work?
The NETCONF architecture consists of two roles: client and server.
• A client provides the following functions:
• Manages network devices using NETCONF.
• Sends RPC requests to a NETCONF server to query or modify one or more parameter values.
• Learns the status of a managed device based on the alarms and events sent by the NETCONF
server of the managed device.
• A server maintains information about managed devices and responds to the client-initiated requests.
• When receiving a request from a NETCONF client, the NETCONF server parses the request and
sends a reply to the client.
• If a fault or another type of event occurs on a managed device, the NETCONF server reports an
alarm or event to the client through the notification mechanism. This allows the client to learn the
status of the managed device.

93. Establishing a NETCONF Session

94. NETCONF Protocol Framework

95. NETCONF Message Format

96. NETCONF Communication Mode
• The request-reply framework is independent of transport layer protocols. The following
lists some basic RPC elements:
• <rpc>: An <rpc> element is used to enclose a request sent from a NETCONF client to a
NETCONF server.
• <rpc-reply>: An <rpc-reply> element is sent by a NETCONF server in response to each
<rpc> request.
• <rpc-error>: If any error or alarm occurs during the processing of an <rpc> request, the
NETCONF server returns an <rpc-reply> message containing only the <rpc-error>
element to the NETCONF client.
• <ok>: If no error or alarm occurs during the processing of an <rpc> request, the
NETCONF server returns an <rpc-reply> message containing only the <ok> element to
the NETCONF client

97. Configuration Datastores
A configuration datastore is a complete set of configuration parameters for a device.
• Only the <running/> configuration datastore is available in the base model of
NETCONF.
Additional configuration datastores can be defined by capabilities, and are available
only on devices that support the capabilities.
• <running/>: It stores all configurations that are currently active on a network
device.
• <candidate/>: It stores configuration data that is about to be committed to
<running/> on a device. <candidate/> configuration datastore can be manipulated
without impacting the device's current configuration.
• <startup/>: It stores the configuration data to be loaded during device startup.

98. What Are NETCONF Capabilities?
• <get-config>: queries all or specified configuration data.
• <edit-config>: The device performs authorization for the operation in <edit-config>, and
performs the requested modifications if authorization is successful.
• <copy-config>: copies data from one configuration datastore to another.
• <delete-config>: deletes a configuration datastore.
• <lock>:Locks allow a client to exclusively have the permission to make modifications and
thereby prevent conflicts.
• <unlock>: releases a configuration lock, which is previously obtained with the <lock>
operation.
• <close-session>: requests graceful termination of a NETCONF session.
• <kill-session>: forces the termination of a NETCONF session. Only an administrator can
perform this operation.

99. Yet Another Next Generation
• 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.

100. YANG 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).

101. Network management architecture based on NETCONF and YANG

102. NETCONF and YANG in
Context
NETCONF
YANG Modules
YANG Modules
YANG Modules
YANG Modules
Management
Applications

103. What is a Data-Model? What is a Network Management
Protocol?
• Data-Model
• A data-model explicitly and precisely
determines the structure, syntax and
semantics of the data…
• …that is externally visible
• Consistent and complete
• Protocol
• Remote primitives to view and manipulate the
data
• Encoding of the data as defined by the data-
model
Data-Model
Protocol

104. Confusion and
Comparison
• Data-Models and information Models
• Information models are for humans
• Not everything
• Not always detailed and precise
• Starting-­point
‐ for data-­model
‐
• Protocol
• Confusion between domain-specific network
management protocols and general RPC
mechanisms
• NETCONF vs. SOAP, REST, …
Data-Model
MIB Modules
YANG Modules
Protocol
The SNMP Protocol
NETCONF

105. YANG – A Data Modeling Language for
Networking
• Human readable, and easy to learn
representation
• Hierarchical configuration data
models
• Reusable types and groupings
(structured types)
• Extensibility through augmentation
mechanisms
• Supports definition of operations
(RPCs)
• Formal constraints for configuration
validation
• Data modularity through modules and
sub-modules
• Well defined versioning rules
Why you should care:
YANG is a full, formal contract language with
rich syntax and semantics to build
applications on

106. Who
?
YANG
• Phil Shafer
• Juniper, XML
• Jürgen Schönwälder
• Jacobs University, SNMP SMIng
• Martin Björklund
• Tail-f
• David Partain
• Ericsson, made it happen
NETCONF
• Phil Shafer, Rob Enns
• Juniper
• Jürgen Schönwälder
• Jacobs University
• Martin Björklund
• Tail-f
• Andy Bierman
• Yumaworks
• Ken Crozier Eliot Lear
• Cisco Systems
• Ted Goddard
• IceSoft
• Steve Waldbusser
• Margaret Wasserman
• Painless Security, LLC

107. Language
Bindings

108. Momentum

109. What makes NETCONF/YANG
different? SNMP NETCONF SOAP REST
Standard IETF IETF W3C -
Resources OIDs Paths URLs
Data models Defined in MIBs YANG
Core
Models
Data Modeling
Language
SMI YANG (WSDL, not data) Undefined, (WSDL),
WADL, text…
Management
Operations
SNMP NETCONF In the XML
Schema, not
standardized
HTTP operations
Encoding BER XML XML XML, JSON,…
Transport Stack UDP SSH
TCP
SSL
HTTP
TCP
SSL
HTTP
TCP
“RESTConf”

110. Common
Operations
Data Manipulation
• <get>
• <get-config>
• <edit-config>
• <copy-config>
• <delete-config>
• <discard-changes> (:candidate)
Session Management
• <close-session>
• <kill-session>
Locking
• <lock>
• <unlock>
Transaction Management
• <commit> (:candidate, :confirmed)
• <cancel-commit> (:confirmed)
Schema Management
• <get-schema> (:monitoring)
RPC Extensions
• <rpc>

111. NETCONF <hello>
Operation
• Capabilities exchange
• Data model ID exchange
• Encoding
• Framing
• NETCONF 1.0 EOM, ]]>]]>
• NETCONF 1.1 Chunk Framing
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.1</capability>
</capabilities>
</hello>

112. NETCONF <get-config>
Operation message-
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1”
id="1">
<data>
<aaa xmlns="http://tail-f.com/ns/aaa/1.1">
<authentication>
<users>
<user>
<name>admin</name>
<uid>9000</uid>
<gid>0</gid>
<password>$1$3ZHhR6Ow$acznsyClFc0keo3B3BVjx/</password>
<ssh_keydir>/var/confd/homes/admin/.ssh</ssh_keydir>
<homedir>/var/confd/homes/admin</homedir>
</user>
<user>
<name>oper</name>
…
</users>
</authentication>
</aaa>
</data>
</rpc-reply>

113. NETCONF <edit-config>
Operation
message-id="1">
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.1”
<edit-config>
<target><running/></target>
<config>
<dhcp xmlns="http://tail-f.com/ns/example/dhcpd"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1">
<defaultLeaseTime nc:operation="merge”>PT1H
</defaultLeaseTime>
</dhcp>
</config>
</edit-
config>
</rpc>
message-
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1"
id="1">
<ok/>
</rpc-reply>

114. NETCONF <copy-config>
Operation
• Copy and replace configuration data between stores or URLs
<rpc message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:
1.1">
<copy-config>
<target><running/></target>
<source>
<url>https://user@example.com:passphrase/cfg/new.txt
</url>
</source>
</copy-config>
</rpc>
<rpc-reply message-id="101”
xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">
<ok/>
</rpc-reply>

115. NETCONF <delete-config>
Operation
• Delete a complete data store (not running)
xmlns="urn:ietf:params:xml:ns:netconf:base:
<rpc message-id="101”
1.1">
<delete-config>
<target>
<startup/>
</target>
</delete-config>
</rpc>
xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">
<rpc-reply message-id="101”
<ok/>
</rpc-reply>

116. NETCONF <lock>, <unlock>
Operation
• Lock/unlock a complete data store
xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">
<rpc message-id="101”
<lock>
<target>
<candidate/>
</target>
</lock>
</rpc>
xmlns="urn:ietf:params:xml:ns:netconf:base:
<rpc-reply message-id="101”
1.1">
<ok/>
</rpc-reply>

117. NETCONF <get>
Operation
• Read configuration and status
<rpc message-id="101” xmlns=”urn:ietf:param
<get>
<filter type="subtree">
<top xmlns="http://example.com/ns/dhc
<interfaces>
<interface>
<ifName>eth0</ifName>
</interface>
</interfaces>
</top>
</filter>
</get>
<rpc-reply message-id="101” xmlns=“urn:ie
<data>
<top xmlns="http://example.com/ns/dhc
<interfaces>
<interface>
<ifName>eth0</ifName>
<ifInOctets>45621</ifInOctets>
<ifOutOctets>774344</ifOutOctet
</interface>
</interfaces>
</top>
</data>
</rpc-reply>

118. NETCONF <close-session>
Operation
• Polite way of disconnecting
<rpc message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">
<close-session/>
</rpc>
xmlns="urn:ietf:params:xml:ns:netconf:base:
<rpc-reply message-id="101”
1.1">
<ok/>
</rpc-reply>

119. NETCONF <kill-session>
Operation
• Not so polite way of disconnecting another session
Releases any locks, aborts any confirmed commit related to
session
<rpc message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">
<kill-session>
<session-id>17</session-id>
</kill-session>
</rpc>
<rpc-reply message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:
1.1">
<ok/>
</rpc-reply>

120. YANG
?
• Data modeling language
• Configuration data
• State data
• Tree structure
• Close to device
• Managing device features
• Data and Types
• Constraints
• Augmentation
• Reusable structures
• Extensions
• SMI translation
• XML
• NETCONF Transport Encoding
• YANG – XML Model mapping
acme-
­
‐box module
properties container
interfaces container
name: string, config
name: string, config
interface: list, index = name
oper-
­
‐state: enum, config

121. YANG
?

122. YANG Module
Contents
Header information
Imports & Includes
Type definitions
Configuration & Operational
data declarations
Action (RPC) & Notification declarations

123. YANG
Header
URI

124. YANG Base
Types
• Most YANG elements have a
data type
• Type may be a base type or
derived type
• Derived types may be simple
typedefs or groupings
(structures)
• There are 20+ base types to
start with
• And more in modules like
• ietf-yang-types, RFC 6021
Type Name Meaning
int8/16/32/64 Integer
uint8/16/32/64 Unsigned integer
decimal64 Non-integer
string Unicode string
enumeration Set of
alternatives
boolean True or false
bits Boolean array
binary Binary BLOB
leafref Referenc
e
“pointer”
identityref Unique identity
empty No value, void
…and more

125. Common YANG
Types
• Commonly used
YANG types defined
in RFC 6021
• Use
import “ietf-yang-types” {
prefix yang;
}
to reference these
types as e.g.
type
yang:counter64
;
www.rfc-editor.org/rfc/rfc6021.txt
counter32/64 ipv4-address
gauge32/64 ipv6-address
object-
identifier
ip-prefix
date-and-time ipv4-prefix
timeticks ipv6-prefix
timestamp domain-name
phys-address uri
ip-version mac-address
flow-label bridgeid
port-number vlanid
ip-address … and more

126. IoT Systems Management with NETCONF-YANG
Ref: Internet of Things: A Hands-on Approach by Arshdeep Bahga and Vijay K. Madisetti