Table of Contents

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.

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.

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.

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.

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:

Flow Diagrams

NETCONF Processor: NETCONF Device Provider

When the NETCONF Plugin comes up, it will try to fetch the device details like, username, password, hostIp and port information from the configuration file and for each device information it will build a NetconfDevice Object and send a Hello Message to the device. The same NetconfDevice object will receive the response from the device, retrieve Capability list and persist the same in the Plugin Store.Once the NETCONF capabilities are successfully discovered, the Provider will use ‘deviceConnected’ api to persist the information on the core.The corresponding flow is shown in the diagram below:

NETCONF Service: 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:

Coding Framework

ONOS interacts with the underlying NETCONF device using 'Providers'. Each sub-systems of ONOS, which includes 'device', 'link', 'host', 'packet' and 'flow', should have a separate modules helping the interaction between ONOS and NETCONF devices. ONOS wiki provides a set of instructions to create new Provider module:

Project Skeleton setup 

 Each Provider implementation should be placed under ${ONOS_ROOT}/providers/. The layout for one of the provider, NetconfDeviceProvider, can be summarized as below:

${ONOS_ROOT}/providers/pom.xml (provider parent POM file)

                      |

                      /netconf/pom.xml (netconf providers POM)

                           |

                           /link/pom.xml (provider-specific POM)

                                |

                                /src/main/java/org/onosproject/provider/netconf/device/impl/NetconfDeviceProvider .java (the provider)

                                    |                                                |

                                    |                                                /package-info.java (optional package-wide documentation/annotations)

                                    |

                                    /test/java/org/onosproject/providers/netconf/device/impl/ (Unit tests should go here)

Add and edit POM files

As part of adding a new provider we need to modify 3 important POM files:

• Provider-specific : The POM which is very specific to a provider and subsystem. e.g. ${ONOS_ROOT}/providers/netconf/device/pom.xml
• Providers : The POM which is very specific to Protocol and will manage all the other POM’s which are specific to subsystem. e.g. ${ONOS_ROOT}/providers/netconf/pom.xml
• Provider root : all Providers e.g. ${ONOS_ROOT}/providers/pom.xml

Class Hierarchy

All the provider implementations, including NetconfDeviceProvider class, should implement Provider interface. The implementation for provider-id is already part of ‘AbstractProvider’, so our new ‘NetconfDeviceProvider’ will be extending to get the default implementation for ‘Provider-Id’.

Assumptions

• Current goal is to only demonstrate ACL model. Other models are for future scope.
• Generation of NETCONF xml messages and parsing of NETCONF xml response from devices is to be considered for future scope. Currently we can take an assumption that we will get NETCONF xml messages from ONOS core. We can take an assumption that the NETCONF xml response from devices need not be parsed and it can be send to ONOS core as is. The intelligence to be put in the plugin to generate NETCONF xml messages for a request from ONOS core is to be considered for future scope. Also, the intelligence to be put into plugin to parse the NETCONF xml response from devices and extract the information to be passed to ONOS core is to be considered for future scope.
• NETCONF device details – IP, login and password to be currently hardcoded into a file and the provider will pick it from there. Eventually, ONOS will expose a config API so you can do it dynamically, but this is future work. Hardcoding is fine for now.
• If we ever need to adjust topology (i.e., how are NETCONF switches connected on data plane), we can inject this information into ONOS NETCONF through REST API. This is done in the ConfigProvider. Don’t worry about this for now. This is to be considered for future scope.