M.Tech Internet of Things Unit - IV.pptx

M.Tech Internet of Things Unit - IV

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 N e i g hb or table OSPF Link state database IP routing table Forwarding table Data plane Adjacent Router Adjacent Router Data plane Control plane OSPF R o u t i ng R o u t i ng Control plane OSPF S w i t c h i ng S w i t c h i ng 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 R o u t i ng Traffic E n g i n ee ri n g Other A pp li c a t io n s Well-defined API Network Map Abstraction F o r w a r d i ng F o r w a r d i ng F o r w a r d i ng F o r w a r d i ng Separation of Data and Control Plane Network V i r t u a li z a ti o n Security Data Palne Control Plane Application Plane I n s t ru c ti on s I n s t ru c ti on s I n s t ru c ti on s I n s t ru c ti on s

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: I nstall OpenDaylight Controller on local Linux machine U se 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 DPI Load Balancer NAT VIRTUAL APPL I ANCES 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, NFV

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

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 Jain

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, NFV

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, NFV

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 CG N A T DNS

53. NFV : Network function Virtualization Internet Traditional LTE Network CGN A T PGw HLR/HSS MME OCS PCRF DNS Specialized Appliances / Purpose Build Combination of Capacity & Functionality Rout e r Swit c h

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 N e t w o r k Components of NFV MME M SC CRAN PC R F S M SC Switch Ro u ter Virtual Machines Virtual Machines H LR P Gw Each Application running on One or Multiple VMs Generic Hardware Virtual Machines v S M SC vM SC v H LR vSGSN vGGSN NFV LTE network

57. NFV Architecture NFV Layers OSS / BSS Orchestration Service , VNF & Infra description E M 1 VNF1 v S M S C E M 2 VNF2 v M S C E M 3 VN F3 v H LR Virtual C o mpu te Virtual Memory Virtual Net w ork Virtualization Layer Compute Memory Network VNF Manager VIM Virtualized Infrastructure Manager NF - Vi NFVI V e- V n fm Se - Ma Os - Ma O r -V n fm V i -V n fm O r - Vi NFV Management & Orchestration VNF ( Virtual Network Function) NFVI (Network Function Virtualization Infrastructure) Manage Ph ysical part in NFVI Hypervisor : R esponsible 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 E M 1 E M 2 E M 3 Virtual C o mpu te Virtual Memory Virtual Net w ork Virtualization Layer Compute Memory Network VNF Manager VIM Virtualized Infrastructure Manager NF - Vi NFVI Ve-Vnfm Se - Ma Os - Ma Or - V n fm V i -V n fm O r - Vi NFV Management & Orchestration VNF A VNF is the basic block in NFV Architecture , Example :- vIMS vMME vMSC vSwitch vRouter EM (Element Management) F CAPS of Application such as Link down , KPI Degradation etc. VNF ( Virtual Network Function) VNF Manager Life cycle VNFs : setting up/ Maintaining Tearing down F CAPS of Virtualization and VNF NFV Architecture VNF1 v S M S C VNF2 v M S C VN F3 v H LR VM VM VM VM VM VM

59. NFV Architecture FCAPS Layers OSS / BSS Orchestration Service , VNF & Infra description E M 1 E M 2 E M 3 Virtual C o mpu te Virtual Memory Virtual Net w ork Virtualization Layer Compute Memory Network VNF Manager VIM Virtualized Infrastructure Manager NF - Vi NFVI Ve-Vnfm Se- Ma Os - Ma O r -V n fm V i -V n fm O r - Vi NFV Management & Orchestration VNF ( Virtual Network Function) VNF1 v S M S C VNF2 v M S C VN F3 v H LR 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 Orc h es t rat io n Service , VNF & Infra description E M 1 V NF 1 E M 2 V NF 2 E M 3 V NF 3 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 O r -V n fm V i -V n fm O r - 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 CMIP protocol takes more system resources than SNMP by a factor of ten  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 SNMP SNMP SNMP Managed Devices Network Management Architecture Router Printer Host

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: When it responds to a request from an SNMP manager and 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.

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

77. 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  

78. 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.  

79. 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.

80. 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.

81. 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.

82. 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.

83. 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.

84. How Does NETCONF Work?

85. 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.

86. Establishing a NETCONF Session

87. NETCONF Protocol Framework

88. NETCONF Message Format

89. 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

90. 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 .

91. 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.

92. 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.

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

94. Network management architecture based on NETCONF and YANG

95. NETCON F an d YAN G i n Context N E T C O NF YANG Modules YANG Modules YANG Modules YANG Modules Mana ge ment Applications MAY 27, 2013

96. 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 P roto c o l Remote primitives to view and manipulate the data Encoding of the data as defined by the data- model Data-Model Protocol MAY 27, 2013

97. Confusio n an d 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, … Da t a- M odel MIB Modules YANG Modules Protocol The SNMP Protocol NETCONF MAY 27, 2013

98. YAN G – A Dat a Modelin g Languag e fo r Networkin g 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 MAY 27, 2013

99. Wh o ? 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 MAY 27, 2013

100. Languag e Bindings MAY 27, 2013

101. Momentu m MAY 27, 2013

102. Wha t make s NETCONF/ Y AN G different? SNMP NETCONF SOAP REST Standard IETF IETF W3C - Resources OIDs Paths URLs Data models Defined in MIBs Y A N G Core Models Data Modeling Language SMI YANG (WSDL, not data) Undefined, (WSDL), WADL, text… Mana ge ment Operations SNMP NETCONF In the XML Schema, not st a n da r d i z ed HTTP operations Encoding BER XML XML XML, JSON,… Transport Stack UDP S SH TCP SSL H T TP TCP SSL H T TP TCP “RESTConf” MAY 27, 2013

103. Commo n Operation s 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>

104. NETCON F <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> MAY 27, 2013

105. NETCON F <get-config > Operation message- MAY 27, 2013 <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>

106. NETCON F <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- MAY 27, 2013 <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1" id="1"> <ok/> </rpc-reply>

107. NETCON F <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://[email protected]: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> MAY 27, 2013

108. NETCON F <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"> MAY 27, 2013 <rpc-reply message-id="101” <ok/> </rpc-reply>

109. NETCON F <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: MAY 27, 2013 <rpc-reply message-id="101” 1.1"> <ok/> </rpc-reply>

110. NETCON F <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> MAY 27, 2013

111. NETCON F <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: MAY 27, 2013 <rpc-reply message-id="101” 1.1"> <ok/> </rpc-reply>

112. NETCON F <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> MAY 27, 2013

113. Y AN G ? 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 a c me -­‐ b o x m o dule properties container interfaces container name: string, config name: string, config interface: list, index = name ope r -­‐ stat e : enu m , con fig MAY 27, 2013

114. Y AN G ? MAY 27, 2013

115. Y AN G Modul e Content s Header information MAY 27, 2013 Imports & Includes Type definitions Configuration & Operational data declarations Action (RPC) & Notification declarations

116. Y AN G Heade r URI MAY 27, 2013

117. Y AN G Bas e T ype s 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   al te rna t i v es boolean True or false bits Boolean array binary Binary BLOB leafref R eference   “pointer” identityref Unique identity empty No value, void …and m o re

118. MAY 27, 2013 Commo n Y AN G T ypes 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

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