Vector Packet Processing 102: Honeycomb & hc2vpp

Welcome to the second part of our VPP Introduction series, where we will talk about details of the Honeycomb project. Please visit our previous post on VPP Plugins & Binary API, which is used in Honeycomb to manage the VPP agent.

What is Honeycomb?

Honeycomb is a generic, data plane management agent and provides a framework for building specialized agents. It exposes NETCONF, RESTCONF and BGP as northbound interfaces.

Honeycomb runs several, highly functional sets of APIs, based in ODL, which are used to program the VPP platform. It leverages ODL’s existing tools and integrates several of its existing components (YANG Tools, MD-SAL, NETCONF/RESTCONF…).  In other words – it is a light on resources, bare bone version of OpenDaylight.

Its translation layer and data processing pipelines are classified as generic, which makes it extensible and usable not only as a VPP specific agent.

Honeycomb’s functionality can be split into two main layers:

  • Data Processing layer – pipeline processing for data from Northbound interfaces, towards the Translation layer
  • Translation layer – handles mainly configuration updates from data processing layer + reads and writes configuration-data
  • Plugins – extend Honeycombs usability

Honeycomb mainly acts as a bridge between VPP and the actual OpenDaylight SDN Controller.

Examples of VPP x Honeycomb integrations

We’ve already showcased several use cases on our Pantheon Technologies’ YouTube channel:

For the purpose of integrating VPP with Honeycomb, we will further refer to the project hc2vpp, which was directly developed for VPP usage.

What is hc2vpp?

This VPP specific build is called hc2vpp, which provides an interface (somewhere between a GUI and a CLI) for VPP. It runs on the same host as the VPP instance and allows to manage it off-the-box. This project is lead by Pantheons own Michal Čmarada.

Honeycomb was created due to a need for configuring VPP via NETCONF/RESTCONF. During the time it was created, NETCONF/RESTCONF was provided by ODL. Therefore, Honeycomb is based on certain ODL tools (data-store, YANG Tools, others). ODL as such uses an enormous variety of tools. Honeycomb was created as a separate project, in order to create a smaller footprint. After its implementation, it exists as a separate server and starts these implementations from ODL.

Later on, it was decided that Honeycomb should be split into a core instance, and hc2vpp would handle VPP related parts. The split also occurred, in order to provide the possibility of creating a proprietary device control agent. hc2vpp (Honeycomb to VPP) is a configuration agent, so that configurations can be sent via NETCONF/RESTCONF. It translates the configuration to low level APIs (called Binary APIs).

Honeycomb and hc2vpp can be installed in the same way as VPP, by downloading the repositories from GitHub. You can either:

Install Honeycomb

Install hc2vpp

For more information, please refer to the hc2vpp official project site.

In the upcoming post, we will introduce you to the Ligato VPP Agent.

You can contact us at

Explore our Pantheon GitHub.

Watch our YouTube Channel.

Vector Packet Processing 101: VPP Plugins & Binary API

In the first part of our new series, we will be building our first VPP platform plug-in, using basic examples. We will start with a first-dive into plugin creation and finish with introducing VAPI into this configuration.

If you do not know what VPP is, please visit our introductory post regarding VPP and why you should consider using it.

Table of contents:

  • How to write a new VPP Plugin
    • 1. Preparing your new VPP plugin
    • 2. Building & running your new plugin
  • How to create new API messages
  • How to call the binary API
    • Additional C/C++ Examples

How to write a new VPP Plugin

The principle of VPP is, that you can plugin a new graph node, adapt it to your networks purposes and run it right off the bat. Including a new plugin does not mean, you need to change your core-code with each new addition. Plugins can be either included in the processing graph, or they can be built outside the source tree and become an individual component in your build.

Furthermore, this separation of plugins makes crashes a matter of a simple process restart, which does not require your whole build to be restarted because of one plugin failure.

1. Preparing your new VPP plugin

The easiest way how to create a new plugin that integrates with VPP, is to reuse the sample code at “src/examples/sample-plugin”. The sample code implements a trivial “macswap” algorithm that demonstrates the plugins run-time integration with the VPP graph hierarchy, API and CLI.

  • To create a new plugin based on the sample plugin, copy and rename the sample plugin directory

cp -r src/examples/sample-plugin/sample src/plugins/newplugin

#replace 'sample' with 'newplugin'. as always, take extra care with sed!
cd src/plugins/newplugin
fgrep -il "SAMPLE" * | xargs sed -i.bak 's/SAMPLE/NEWPLUGIN/g'
fgrep -il "sample" * | xargs sed -i.bak 's/sample/newplugin/g'
rm *.bak*
rename 's/sample/newplugin/g' *

There are the are following files:

    • node.c – implements functionality of this graph node (swap source and destination address) -update according to your requirements.
    • newplugin.api – defines plugin’s API, see below
    • newplugin.c, newplugin_test.c – implements plugin functionality, API handlers, etc.
  • Update CMakeLists.txt in newplugin directory to reflect your requirements:




  COMPONENT vpp-plugin-newplugin
  • Update sample.c to hook your plugin into the VPP graph properly:
VNET_FEATURE_INIT (newplugin, static) = 
 .arc_name = "device-input",
 .node_name = "newplugin",
 .runs_before = VNET_FEATURES ("ethernet-input"),
  • Update newplugin.api to define your API requests/replies. For more details see “API message creation” below.
  • Update node.c to do required actions on input frames, such as handling incoming packets and more

2. Building & running your new plugin

  • Build vpp and your plugin. New plugins will be built and integrated automatically, based on the CMakeLists.txt
make rebuild
  • (Optional) Build & install vpp packages for your platform
make pkg-deb
cd build-root
sudo dpkg -i *.deb
  • The binary-api header files you can include later are located in build-root/build-vpp_debug-native/vpp/vpp-api/vapi
    •  If vpp is installed, they are located in /usr/include/vapi
  • Run vpp and check whether your plugin is loaded (newplugin has to be loaded and listed using the show plugin CLI command)
make run
load_one_plugin:189: Loaded plugin: (Network Address Translation)
load_one_plugin:189: Loaded plugin: (Sample VPP Plugin)
load_one_plugin:189: Loaded plugin: (network delay simulator plugin)
DBGvpp# show plugins
 Plugin Version Description
 1. 19.01-rc0~144-g0c2319f Inbound OAM
 x. 1.0 Sample VPP Plugin

How to create new API messages

API messages are defined in *.api files – see src/vnet/devices/af_packet.api, src/vnet/ip/ip.api, etc. These API files are used to generate corresponding message handlers. There are two types of API messages – non-blocking and blocking. These messages are used to communicate with the VPP Engine to configure and modify data path processing.

Non-blocking messages use one request and one reply message. Message replies can be auto-generated, or defined manually. Each request contains two mandatory fields – “client-index” and “context“, and each reply message contains mandatory fields – “context” and “retval“.

  • API message with auto-generated reply

autoreply define ip_table_add_del
 u32 client_index;
 u32 context;
 u32 table_id;
  • API message with manually defined reply
define ip_neighbor_add_del
 u32 client_index;
 u32 context;
 u32 sw_if_index;
define ip_neighbor_add_del_reply
 u32 context;
 i32 retval;
 u32 stats_index;

Blocking messages use one request and series of replies defined in *.api file. Each request contains two mandatory fields – “client-index” and “context“, and each reply message contains mandatory field – “context“.

  • Blocking message is defined using two structs – *-dump and *_details

define ip_fib_dump
 u32 client_index;
 u32 context;
define ip_fib_details
 u32 context;

Once you define a message in an API file, you have to define and implement the corresponding handlers for given request/reply message. These handlers are defined in one of component/plugin file and they use predefined naming – vl_api_…_t_handler – for each API message.

Here is an example for existing API messages (you can check it in src/vnet/ip component):

#define foreach_ip_api_msg \
_(IP_FIB_DUMP, ip_fib_dump) \
_(IP_NEIGHBOR_ADD_DEL, ip_neighbor_add_del) \
static void vl_api_ip_neighbor_add_del_t_handler (vl_api_ip_neighbor_add_del_t * mp, vlib_main_t * vm)
static void vl_api_ip_fib_dump_t_handler (vl_api_ip_fib_dump_t * mp)
 send_ip_fib_details (am, reg, fib_table, pfx, api_rpaths, mp->context);

Request and reply handlers are usually defined in api_format.c (or in plugin). Request uses a predefined naming – api_… for each API message and you have to also define help for each API message :

static int api_ip_neighbor_add_del (vat_main_t * vam)
  /* Construct the API message */
  /* send it... */
  S (mp);
  /* Wait for a reply, return good/bad news */
  W (ret);
  return ret;
static int api_ip_fib_dump (vat_main_t * vam)
  M (IP_FIB_DUMP, mp);
  S (mp);
  /* Use a control ping for synchronization */
  MPING (CONTROL_PING, mp_ping);
  S (mp_ping);
  W (ret);
  return ret;
#define foreach_vpe_api_msg \
_(ip_neighbor_add_del, \
 "(<intfc> | sw_if_index <id>) dst <ip46-address> " \
 "[mac <mac-addr>] [vrf <vrf-id>] [is_static] [del]") \
_(ip_fib_dump, "") \

Replies can be auto-generated or manually defined.

  • auto-generated reply using define foreach_standard_reply_retval_handler, with predefined naming
  • manually defined reply with details

How to call the binary API

In order to call the binary API, we will introduce VAPI to our configuration.

VAPI is the high-level C/C++ binary API. Please refer to src/vpp-api/vapi/ for details.

VAPI’s multitude of advantages include:

  • All headers in a single place – /usr/include/vapi => simplifies code generation
  • Hidden internals – one no longer has to care about message IDs, byte-order conversion
  • Easier binapi calls – passing user provided context between callbacks

We can use the following C++ code to call our new plugins’s binary API.

#include <cstdlib>
#include <iostream>
#include <cassert>

//necessary includes & macros
#include <vapi/vapi.hpp>
#include <vapi/vpe.api.vapi.hpp>

//include the desired modules / plugins
#include <vapi/newplugin.api.vapi.hpp>

using namespace vapi;
using namespace std;

//parameters for connecting
static const char *app_name = "test_client";
static const char *api_prefix = nullptr;
static const int max_outstanding_requests = 32;
static const int response_queue_size = 32;

#define WAIT_FOR_RESPONSE(param, ret)      \
  do                                       \
    {                                      \
      ret = con.wait_for_response (param); \
    }                                      \
  while (ret == VAPI_EAGAIN)

//global connection object
Connection con;

void die(int exit_code)
    //disconnect & cleanup
    vapi_error_e rv = con.disconnect();
    if (VAPI_OK != rv) {
        fprintf(stderr, "error: (rc:%d)", rv);


int main()
    //connect to VPP
    vapi_error_e rv = con.connect(app_name, api_prefix, max_outstanding_requests, response_queue_size);

    if (VAPI_OK != rv) {
        cerr << "error: connecting to vlib";
        return rv;

        Newplugin_macswap_enable_disable cl(con);

        auto &mp = cl.get_request().get_payload();

        mp.enable_disable = true;
        mp.sw_if_index = 5;

        auto rv = cl.execute ();
        if (VAPI_OK != rv) {
            throw exception{};

        WAIT_FOR_RESPONSE (cl, rv);
        if (VAPI_OK != rv) {
            throw exception{};

        //verify the reply
        auto &rp = cl.get_response ().get_payload ();
        if (rp.retval != 0) {
            throw exception{};
    catch (...)
        cerr << "Newplugin_macswap_enable_disable ERROR" << endl;


Additional C/C++ Examples

Furthermore, you are encouraged to try the minimal VAPI example provided in This example creates a loopback interface, assigns it an IPv4 address and then prints the address.
Follow these steps:

  • Install VPP
  • Extract the archive, build & run examples
mkdir build; cd build
cmake ..

#c example
sudo ./vapi_minimal
#c++ example
sudo ./vapi_minimal_cpp

In conclusion, we have:

  • successfully built and ran our first VPP plugin
  • created and called an API message in VPP

Our next post will introduce and highlight the key reasons, why you should consider Honeycomb/hc2vpp in your VPP build.

You can contact us at

Explore our Pantheon GitHub. Follow us on Twitter.

Watch our YouTube Channel. @ 2020 Vision Executive Summit in Lisbon

I was sent to Lisbon by, in order to attend the annual 2020 Vision Executive Summit. Here are my experiences and insights into this event.

The 2020 Vision Executive Summit, presented by Light Reading, was focused mainly on the pending revolution of 5G networks, automation, Edge Computing, IoT, security, etc. It hosts a variety of vendors and service providers, who provide insights into the telecom industry’s current trends and emerging topics.

Themes of the summit

In case of 5G, we have seen a huge opportunity in discussing’s future involvement and plans in this revolution. The challenges surrounding 5G were discussed by industry leaders with hands-on experience. This was beneficial, since we were confronted with the harsh reality of 5G. Due to it being a technology in-progress, many questions are still open. What will be the use-cases? What should we prepare for and when?

Nobody really knows how it may turn out, when it will become widely available for consumers, or if the world is even prepared for it. But it was a great opportunity to meet the people, whose bread and butter consists of building the future 5G network. It was an invaluable experience, to see a realistic view from industry-insiders and their perception of the future. It was a collective of equally-minded individuals and companies in the fields relevant to’s vision.

Another heavily discussed topic was security. While it is no secret that technology is successfully becoming an important part of our lives. Companies have to heavily rely on a defense against potential security threats and cyber attacks. Panels were held regarding the importance of security measures in expanding networks and the need for flexible and agile security solutions.

Subsequently, Edge Computing, which brings the distribution of data closer to the consumer, was also mentioned and discussed, in regards to its vulnerabilities and future. In this case, it was said with certainty that if you are the type of parent that plans your child’s future for them, make them study cyber security. The investment will return sooner than you could imagine.

Our experience at the summit

Our vision in attending this summit was to find out, if this summit is the right fit for us (spoiler alert – it was) check on the newest trends in our field and in which direction are they developing. The discussions were open and involved the real thoughts and views, without the PR and marketing stuff.

Lisbon is an interesting city, since it is more hidden from the eye of a classic tourist. It reminded me, in a way, of San Francisco. This was mainly due to trams riding uphill and the many uphill roads one has to take, in order to get somewhere. It was surprising though, that the city is making it a point to keep the original architecture of the city in tact and without major reconstructions.

As for the venue itself, the Intercontinental Hotel in Lisbon was nothing short of wonderful. Another highlight was the gala dinner. It was the perfect opportunity for casual networking, in the pompous and spectacular setting of Palacio de Xebregas. I have also experienced my first tuk-tuk ride, where I had to consider whether my life was worth the visit.

In conclusion – it was. I am looking forward to the new business-partners and connections has made at the 2020 Vision Executive Summit.

You can contact us at

Explore our Pantheon GitHub.

Watch our YouTube Channel. core becomes Open-Source, the proven supporter of open-source software and its communities, and leader in Software Defined Networking (SDN) and the OpenDaylight (ODL) platform, decided to open-source the core components of the current go-to SDN controller development kit:

Last Open Networking Summit, USA witnessed the announcement of This ONS will be the place where all OpenDaylight users will remember.

Today, continues to push forward the open-source community projects and its commercial applications developed on open-source software, especially the core.

What is journey started when we realized the way to move the upstream project to the direction we envisioned was to provide a solution rather than talk about it. Therefore we’ve focused on a solution of the biggest pain point of current ODL, and turned it into the idea-bearer of the whole product. We’ve taken the biggest obstacle – Apache Karaf, out of the ODL developers lives, and hence improving their efficiency tremendously.

On the other hand the commercial product is available for purchase is developed using the same core which gets open-sourced today. We are tirelessly adding new features with the demand and cooperation with our customers. Such as the Network Topology Visualisation Component, Go/Java/Python RESTCONF clients, improved RESTCONF notifications with HTTP 2.0 support, improved southbound NETCONF plugin with the implemented support of YANG actions, NETCONF simulator to name a few.

Our vision from the start was to enhance the commercial version of with bleeding edge features and improvements that are not yet in open-source ODL. This will leverage users capability to speed up their development and deployment. Today users will get the chance to experience these changes, instead of waiting until such improvements appear in the upstream or developing themselves. released core components under Eclipse Public License v1.0 as a continuous support to the community.

Future of SDN

We believe this generous act will result in spinning up new projects based on OpenDaylight components making them faster and cheaper to develop and will give you a competitive edge in today’s fast evolving world of micro service and cloud-oriented deployments.

We encourage all OpenDaylight users, Data Center managers, Telco and Service Provider DevOps to give a try with their existing applications. It will be amaze you.

Today, will officially release the core as free and open-source software at the event. Please join us in the Open Networking Summit Europe/Amsterdam at booth #14.

There is more to come, as we will reveal how cuts down the software development costs and time, helping our customers to consume complex data center management features with ease.

Stay tuned and watch this space for the other great announcements around which will take space in the event. Be there to witness the amazing.

Meet Martin Varga – @ ONS 2018

Martin Varga represents as the Technical Business Development Manager and is responsible for the growth of the company’s business portfolio and goal to establish new partnerships. Martin has over two decades of professional experience in marketing, sales management, and international business development fields.

He has acquired many titles in his long career, ranging from Artist Manager to COO. He is an excellent negotiator and peoples person.

Recently, Martin had started to be very interested in the Hi tech business, especially in the networking field, which is on the rise nowadays and will be for the next decades. He quickly got absorbed in the networking field and discovered his new passion. Hence he accepted the challenge and is using all his previously acquired experience to expand the business development for

Connect with Martin via his LinkedIn.

Martin will be available to establish new business relationships with international partners and to discover new market share. He will be representing the silver sponsor of Open Networking Summit Europe which will take place on Sep 25-27 in Amsterdam.

Join Martin at’s booth #14 in the event possibly to shake hands into a partnership which will last. runs 5G on xRAN

In April 2018, the xRAN forum released the Open Fronthaul Interface Specification. The first specification made publicly available from xRAN since its launch in October 2016. The released specification has allowed a wide range of vendors to develop innovative, best-of-breed remote radio unit/head (RRU/RRH) for a wide range of deployment scenarios, which can be easily integrated with virtualized infrastructure & management systems using standardized data models.

This is where came to the scene. We became one of the first companies to introduce full stack 5G compliant solution with this specification.

Just a few days spent coding and utilizing the readily available components, we created a Radio Unit (RU) simulator and an SDN controller to manage a group of Radio Units.

Now, let us inspect the architecture and elaborate on some important details.

We have used, specifically the generic NETCONF simulator, to set up an xRAN Radio Unit (RU) simulator. xRAN specifies YANG models for 5G Radio Units. NETCONF device library is used as a base which made it easy to add custom behavior and 5G RU is ready to stream data to a 5G controller.

The code in the controller pushes the data collected from RUs into Elasticsearch for further analysis. RU device emits the notifications of simulated Antenna Line Devices connected to RU containing:

  • Measured Rx and Tx input power in mW
  • Tx Bias Current in mA (Internally measured)
  • Transceiver supply voltage in mV (Internally measured)
  • Optional laser temperature in degrees Celsius. (Internally measured)

*We used device xRAN-performance-management model for this purpose. as a 5G controller

With we created an OpenDaylight based SDN controller that can connect to RU simulators using NETCONF. Once RU device is connected, telemetry data is pushed via NETCONF notifications to the controller, and then directly into Elasticsearch.
Usually, log stash is required to upload data into Elasticsearch. In this case, it is the 5G controller that is pushing device data directly to Elasticsearch using time series indexing.
On Radio Unit device connect event, monitoring process automatically starts. RPC-ald-communication is called on RU device collecting statistics for:

  • The Number of frames with incorrect CRC (FCS) received from ALD – running counter
  • The Number of frames without stop flag received from ALD – running counter
  • The number of octets received from HDLC bus – running counter

*We used xran-ald.yang model for this purpose.
The 5G controller is also listening to notifications from the RU device mentioned above.

Elasticsearch and Kibana

Data collected by the 5G controller via RPC calls and notifications are pushed directly into Elasticsearch indices. Once indexed, Elasticsearch provides a wide variety of queries upon stored data.
Typically, we can display several faulty frames received from “Antenna Line Devices” over time, or analyze operational parameters of Radio Unit devices like receiving and transmitting input power.
Such data are precious for Radio Unit setup, so the control plane feedback loop is possible.

By adding Elasticsearch into the loop, data analytics or the feedback loop became ready to perform complex tasks. Such as: Faulty frame statistics from the “Antenna Line Devices” or the  Radio Unit operational setup

How do we see the future of xRAN with

The benefit of this solution is a full stack xRAN test. YANG models and its specifications are obviously not enough considering the size of the project. With 5G xRAN, we invite the Radio Unit device vendors and 5G network providers to cooperate and build upon this solution. Having the Radio Unit simulators available and ready allows for quick development cycle without being blocked by the RU vendor’s bugs. has been used as a 5G rapid application development platform which enables quick xRAN Radio Unit monitoring system setup.
We can easily obtain xRAN Radio Unit certification against ‘ 5G controller’ and provide RU simulations for the management plane.

Visit page, and check out our GitHub for more details.

Meet Robert Varga – @ ONS 2018

Robert Varga is’s  Chief Technology Officer who has almost two decades of Information Technology Industry experience ranging from being a C code monkey, through various roles in telecommunications’ IT operations to architecting bleeding edge software platforms.

Robert has a deep expertise in Software Defined Networking, its applications and the OpenDaylight platform.

Within those decades, some of the technologies he had experience are: C/C++, Java, Python, various UNIX-like systems and database systems.

Robert has a very strong background in design, development, deployment, and administration of large-scale platforms with the primary focus on high availability and security.

Robert has been involved in OpenDaylight from its start, architecting, designing and implementing the MD-SAL. He is the most prolific OpenDaylight contributor and a member of the OpenDaylight Technical Steering Committee, representing kernel projects. His code contributions revolve around key infrastructure components, such as YANG Tools, MD-SAL and Clustered Data Store. He also designed and implemented the first versions of the BGP and PCEP plugins.


Source: Bitergia Analytics

Until today, Robert Varga had made 11,368 commits in 66 ODL projects over the course of ODL’s lifespan. That is 621,236 added and 524,842 removed lines of code and that translates roughly around 12 great novels written in </code>. ODL continues to be a great example of what an open-source software is and how international contributors can collaborate beautifully to create the next great thing.  There are currently only 13 TCLs in ODL who help steer the project forward and lead the ODL to be the most successful SDN controller in the world. He is proudly one of the ODL Technical Steering Committee Members and a committer to a range of projects.

The all-time top contributor of ODL  Robert Varga, Chief Technology Officer of makes the company proud to be among the top contributor of such innovative, successful project.

Robert shares the’s ambition to create the biggest and most successful open-source Software Defined Networking (SDN) controller in the world.

Robert will be available to share his deep expertise in the field and representing the silver sponsor of Open Networking Summit Europe which will take place on Sep 25-27 in Amsterdam.

Join Robert at’s booth #14 in the event to get a glimpse of the Software Defined Networking future.


Meet Štefan Kobza – @ ONS 2018


Štefan Kobza is Chief Operation Officer at with almost two decades of professional Information Technology industry experience.

He started his career as a software developer and built his way up. Štefan has worked on different projects ranging from developing proprietary code for major networking vendors to rating and billing services mainly in computer networking and telecommunication industries. All of his coding experiences helped Štefan to understand his game and stay on top of the projects he is involved and for’s current customers to provide the highest quality engineering services.

Štefan has taken part in the process of defining some IETF RFCs ¹ ², which was an experience on its own.

Lately, he had developed a special interest for open-sourced projects and its communities.

Understanding the daily life of a software developer, Štefan helps in building an ever growing and ever improving environment that helps provide the highest quality engineering services.

You can find his published articles and activities on his LinkedIn profile.

Besides leading day-to-day business in, Štefan also watches closely the development around OpenDaylight, OPNFV, ONAP, FD.IO, Sysrepo, Contiv, Ligato, and others.

Find Štefan representing the silver sponsor, at booth #14 in the Open Networking Summit Europe to exchange ideas and to get a glimpse of the Software Defined Networking future.

Save the date and get your tickets. #ons2018, Amsterdam Sep 25-27 releases version 9.0

OpenDaylight Fluorine 9 is proud to announce the release of 9.0 following the official  OpenDaylight Fluorine release. has been adapted to reflect the latest upstream changes and made fully compatible with.

Check out our latest release on our GitHub account.

Here are some noteworthy improvements what OpenDaylight Fluorine established:

  •  Yangtools cleanup and refactoring.
  •  Streamlined generated Yang module APIs.
  •  Improved Java bindings.
  •  NETCONF and RESTCONF improvements.

The biggest ODL improvement is the new set of core services provided by the MD-SAL project. Older services provided previously by the controller project have been marked as dprecated and will be removed in future ODL/ releases. provides new MD-SAL services as well as deprecated controller implementations.

Please see Services for reference.

If your application uses any of the deprecated marked services, you should consider refactoring. Contact us for any troubleshooting requirements.

In addition to the latest ODL improvements, has more to offer:

  • Up-to-date web server Jetty 9.4.11.v20180605 with better HTTP2 support.
  • RESTCONF implementations are now in compliance with HTTP2.
  • YANG actions implementation as it was defined in RFC 7650.
  • gNMI / OpenConfig south-bound plugin.
  • Minor changes leading the controller to startup faster
  • Improved Javadoc for main APIs.
  • The easier pathway towards JDK 11 adoption.
  • dependency injection integration.
  • And many more, please check them out on the web.

List of new and deprecated services:

List of new MD-SAL services:  List of deprecated services:



















org.opendaylight.controller.sal.binding.api.RpcProviderRegistry by

Meet Juraj Veverka – @ ONS 2018

Juraj Veverka is’s Technical Leader and Solution Design Architect who has over 15 years of technical experience. Juraj has a deep expertise in design and implementation of Software Defined Networking applications using the OpenDaylight platform. Some of the technologies he uses from his toolbox are Java, Python, JEE7, SpringBoot, GRPC, OpenDaylight, ONAP, Yang, Netconf, Restconf, OpenFlow, BGP,, C/C++, HTML.

Juraj has a Telecommunication and Electrical Engineering degree from the University of Zilina, Slovakia. Juraj shares the company’s mission to create the best development stack for SDN applications and has a passion for Java and embedded platforms.

You can find his published articles on his LinkedIn profile and see what he is working on, on GitHub.

Juraj will be available to share his deep expertise in the field and representing the silver sponsor of Open Networking Summit Europe which is going to take place on Sep 25-27 in Amsterdam.

Find at booth #14 in the event to get a glimpse of the Software Defined Networking future.