Control plane support

Control plane functionalities are provides via SDN controllers or via standard IP routing protocols. SDN support is provided by using the NETCONF/YANG protocol for network management, control and telemetry.

Routing is supported via synchronization of the IP FIB and the IP RIB as implemented by one of the routing protocols in FRR. Without loss of generality we have reported below one example of IGP routing via OSPF for IPv6.

The VPP IP FIB can be controlled and updated by one FRR routing protocol which is used for routing over locators and also over hICN name prefixes.


Getting started

NETCONF/YANG support is provided via several external components such as libyang, sysrepo, libnetconf and netopeer. The hicn project provides a sysrepo plugin and a YANG model for two devices: the VPP based hicn virtual switch and the portable forwarder. The YANG model for the VPP based hICN vSwitch is based the full hICN C API exported by the VPP plugin with the addition of some VPP APIs such as interface and FIB management which are required by the hICN plugin.

To install libyang, sysrepo, libnetconf and netopeer2 for Ubuntu18 amd64/arm64 or CentOS 7 and ad-hoc repository is available and maintained in bintray at

For instance in Ubuntu 18 LTS:

Install the sysrepo YANG data store and a NETCONF server:

echo "deb [trusted=yes] bionic main" \
                                            | tee -a /etc/apt/sources.list
apt-get update && apt-get install -y libyang sysrepo libnetconf2 netopeer2-server

Install the VPP based hICN virtual switch:

curl -s | bash
apt-get update && apt-get install -y hicn-plugin vpp-plugin-dpdk hicn-sysrepo-plugin

The hICN YANG models are installed under /usr/lib/$(uname -m)-linux-gnu/modules_yang.

Configure the NETCONF/YANG components:

bash /usr/bin/ sysrepoctl /usr/lib/$(uname -m)-linux-gnu/modules_yang root
bash /usr/bin/ sysrepocfg openssl
bash /usr/bin/ sysrepocfg genkey

You can manually install the yang model using the following bash script:

command -v sysrepoctl > /dev/null
if [ $? != 0 ]; then
    echo "Could not find command \"sysrepoctl\"."
     exit ${EXIT_CODE}
sysrepoctl --install --yang=path_to_hicn_yang_model

YANG model

hicn.yang can be found in the yang-model. It consists of two container nodes:

|--+ hicn-conf: holds the configuration data;
|  |--+ params: contains all configuration parameters;
|--+ hicn-state: provides the state data
|  |--+ state,
|  |--+ strategy,
|  |--+ strategies,
|  |--+ route,
|  |--+ face-ip-params
and corresponding leaves.

A controller can configure these parameters through the edit-config RPC call. This node can be used to enable and to initialize the hicn-plugin in VPP instance. hicn-state container is used to provide the state data to the controller. It consists of state, strategy, strategies, route, and face-ip-params nodes with the corresponding leaves. In the hicn model a variety of RPCs are provided to allow controller to communicate with the hicn-plugin as well as update the state data in hicn-state.


To setup the startup configuration you can use the following script:

command -v sysrepocfg > /dev/null
if [ $? != 0 ]; then
    echo "Could not find command \"sysrepocfg\"."
     exit ${EXIT_CODE}
sysrepocfg -d startup -i path_to_startup_xml -f xml hicn

startup.xml is placed in the yang-model. Here you can find the content:

<hicn-conf  xmlns="urn:sysrepo:hicn">

It contains the leaves of the parameters in hicn-conf node which is used as the startup configuration. This configuration can be changed through the controller by subscribing which changes the target to the running state. hicn yang model provides a list of RPCs which allows controller to communicate directly with the hicn-plugin. This RPCs may also cause the modification in state data.

In order to run different RPCs from controller you can use the examples in the controler_rpcs_instances.xml in the yang-model. Here you can find the content:

<node-params-get xmlns="urn:sysrepo:hicn"/>

<node-stat-get xmlns="urn:sysrepo:hicn"/>

<strategy-get xmlns="urn:sysrepo:hicn">

<strategies-get xmlns="urn:sysrepo:hicn"/>

<route-get xmlns="urn:sysrepo:hicn">

<face-params-get xmlns="urn:sysrepo:hicn">

<hicn-enable xmlns="urn:sysrepo:hicn">

<hicn-disable xmlns="urn:sysrepo:hicn">

Run the plugin

First, verify the plugin and binary libraries are located correctly, then run the vpp through (service vpp start). Next, run the sysrepo plugin (sysrepo-plugind), for debug mode: sysrep-plugind -d -v 4 which runs with high verbosity. Now, the hicn sysrepo plugin is loaded. Then, run the netopeer2-server which serves as NETCONF server

Connect from netopeer2-cli

In order to connect through the netopeer client run the netopeer2-cli. Then, follow these steps:

  • connect –host XXX –login XXX

  • get (you can get the configuration and operational data)

  • get-config (you can get the configuration data)

  • edit-config –target running –config

With the default netopeer2-server configuration the authentication required by netopeer2-cli reflects the ssh authentication (username and password or public key). For other means of authentication please refer to netopeer2-server documentation (e.g., netopeer2/server/configuration/

You can modify the configuration but it needs an xml configuration input.

<hicn-conf  xmlns="urn:sysrepo:hicn">
  • user-rpc (you can call one of the rpc proposed by hicn model but it needs an xml input)

Connect from OpenDaylight (ODL) controller

In order to connect through the OpenDaylight follow these procedure:

  • run karaf distribution (./opendayligh_installation_folder/bin/karaf)

  • install the required feature list in DOL (feature:install odl-netconf-server odl-netconf-connector odl-restconf-all odl-netconf-topology or odl-netconf-clustered-topology)

  • run a rest client program (e.g., postman or RESTClient)

  • mount the remote netopeer2-server to the OpenDaylight by the following REST API:

    PUT <http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/hicn-node>`

    with the following body:

    <node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
      <host xmlns="urn:opendaylight:netconf-node-topology">Remote_NETCONF_SERVER_IP</host>
      <port xmlns="urn:opendaylight:netconf-node-topology">830</port>
      <username xmlns="urn:opendaylight:netconf-node-topology">username</username>
      <password xmlns="urn:opendaylight:netconf-node-topology">password</password>
      <tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only>
      <keepalive-delay xmlns="urn:opendaylight:netconf-node-topology">1</keepalive-delay>

    Note that the header files must be set to Content-Type: application/xml, Accept: application/xml.

  • send the operation through the following REST API:

POST http://localhost:8181/restconf/operations/network-topology:network-topology/topology/topology-netconf/node/hicn-node/yang-ext:mount/ietf-netconf:edit-config

The body can be used the same as edit-config in netopeer2-cli.

Connect from Cisco Network Services Orchestrator (NSO)

To connect NSO to the netopeer2-server, first, you need to write a NED package for your device. The procedure to create NED for hicn is explained in the following:

Place hicn.yang model in a folder called hicn-yang-model, and follow these steps:

  • ncs-make-package –netconf-ned ./hicn-yang-model ./hicn-nso

  • cd hicn-nso/src; make

  • ncs-setup –ned-package ./hicn-nso –dest ./hicn-nso-project

  • cd hicn-nso-project

  • ncs

  • ncs_cli -C -u admin

  • configure

  • devices authgroups group authhicn default-map remote-name user_name remote-password password

  • devices device hicn address IP_device port 830 authgroup authhicn device-type netconf

  • state admin-state unlocked

  • commit

  • ssh fetch-host-keys

At this point, we are able to connect to the remote device.

Release note

The current version is compatible with the 20.01 VPP stable and sysrepo devel.

Routing plugin for VPP and FRRouting for OSPF6

This document describes how to configure the VPP with hicn_router plugin and FRR to enable the OSPF protocol. The VPP and FRR are configured in a docker file.

DPDK configuration on host machine

Install and configure DPDK:

make install T=x86_64-native-linux-gcc && cd x86_64-native-linux-gcc && sudo make install
modprobe uio
modprobe uio_pci_generic
dpdk-devbind --status
the PCIe number of the desired device can be observed ("xxx")
sudo dpdk-devbind -b uio_pci_generic "xxx"

VPP configuration

Run and configure the VPP (hICN router plugin is required to be installed in VPP):

vpp# set int state TenGigabitEtherneta/0/0 up
vpp# set int ip address TenGigabitEtherneta/0/0 a001::1/24
vpp# create loopback interface
vpp# set interface state loop0 up
vpp# set interface ip address loop0 b001::1/128
vpp# enable tap-inject  # This creates the taps by router plugin
vpp# show tap-inject # This shows the created taps
vpp# ip mroute add ff02::/64 via local Forward  # ff02:: is multicast ip address
vpp# ip mroute add ff02::/64 via TenGigabitEtherneta/0/0 Accept
vpp# ip mroute add ff02::/64 via loop0 Accept

Setup the tap interface:

ip addr add a001::1/24 dev vpp0
ip addr add b001::1/128 dev vpp1
ip link set dev vpp0 up
ip link set dev vpp1 up

FRR configuration

Install FRR in Ubuntu 18 LTS:

Run and configure FRRouting (ospf):

/usr/lib/frr/ start &
configure terminal
router ospf6
area range a001::1/24
area range b001::1/128
interface vpp0 area
interface vpp1 area
add  "no ipv6 nd suppress-ra" to the first configurtion part of the /etc/frr/frr.conf

After the following configuration, the traffic over tap interface can be observed via tcpdump- i vpp1. The neighborhood and route can be seen with the show ipv6 ospf6 neighbor/route command.