Page tree

This is an archive of the ONOS 1.0 wiki. For the current ONOS wiki, look here.

Skip to end of metadata
Go to start of metadata



Revision History









Initial Draft



Adding Flowcharts and updates to library used,



Changed the architecture diagram and flow diagrams.,








Table of Contents

1.          Introduction  

2.          What is ONOS?  

3.          What is NETCONF? 

4.          NETCONF plugin for ONOS  

5.          NETCONF Plugin Architecture 

6.          Flow Diagrams  




1.            Introduction

This document defines the NETCONF plugin on South bound interface of ONOS operating system. It defines high level architecture of the plugin which can be used to understand, develop and test the plugin.

2.            What is ONOS?

ONOS is an open source SDN operation system.

It is used as a Central Network Management Controller to view, manage and program network devices. ONOS architecture is unique. It enables the operating system to modularize different components and also gives compatibility to add more protocols and user-defined data models in future.

One of the protocol which ONOS supports in South bound tier is NETCONF.



3.            What is NETCONF?

Network Configuration Protocol, in short NETCONF is a standard protocol used by major network device providers in their devices. It allows network administrators to view, modify, delete and manage configurations on network devices.

NETCONF uses simple XML based data encoding and is used over a remote procedure call.


4.            NETCONF plugin for ONOS

NETCONF support is added in to ONOS as a plugin.

This plugin in placed in the lower layer of ONOS architecture which communicates to ONOS using the southbound API and communicates to different network devices which support NETCONF protocol. This plugin is used by ONOS Applications to communicate with NETCONF enabled devices.


5.            NETCONF Plugin Architecture



As part of Basic Architecture there are 3 main components that will define the functionality of NETCONF South Bound Plugin.

  • Netconf Processor: This will be responsible for building, parsing, sending and processing NETCONF Messages. JNC client library is used for sending request and processing the response from the device. One of the main functionality of this component is to process ‘Device Capabilities’. At the time of initialization plugin will fetch the details of all the NETCONF Devices. For each device NETCONF Processor will build a ‘Netconf Hello Message’ and send it to the Device and as a response each device will send a ‘list of Capabilities’. The capability response for each device will be fetched and stored in the NETCONF Plugin Store.
  • Netconf Service: This will be responsible for handling abstraction between ONOS core and Plugin layers. Service request can be of 2 types, one to get capability information and second is to execute standard NETCONF operations, on NETCONF devices.
  • Store: This will be an in-memory store within NETCONF Plugin which will store NETCONF device information as:



Capabilities List

Login Information (SSH Key)




6.            Flow Diagrams

NETCONF Processor: NETCONF Device Identification.

When the NETCONF Plugin comes up, it will try to fetch the device details of all the NETCONF Devices, and for each of the device it will retrieve the NETCONF capabilities from the server. From the NETCONF device response we will be storing the NETCONF Specific Device information on to NETCONF Plugin Store. The corresponding flow is shown in the diagram below:




Netconf Servive: Executing NETCONF Operations.

Whenever Application tries to execute standard NETCONF Operation, it will notify NetconfProvider through ‘NetconfService’.NetconfService component is part of NETCONF Provider. NetconfService will expose listeners to ONOS for executing NETCONF Operation. ‘NetconfService’ will build ‘XML’ request using JNC client library and it will also exceute given operation using JNC’s ‘sendRequest’ api.Before going to actual device, listerner will search NETCONF plugin store, for the data. The corresponding flow is shown in the diagram below:




  • No labels