In the contemporary SDN world, ONAP (Open Network Automation Platform) is quite a trend. ONAP is a big project composed of a number of sub-projects (or components if you like), which together form a platform for orchestration and automation of network functions. There are big companies involved in ONAP and its development is speeding up rapidly.

SDN-C is one of many ONAP’s components, which is essentially OpenDaylight with added functionality for the execution of directed graphs.

SDN-C deployment architecture

ONAP SDN-C deployment is composed of several Docker containers. One of these containers runs Directed Graph Builder. It’s a web UI you can use to build directed graphs in a user-friendly manner.

Another container runs Admin Portal, which is another web UI for SDNC.

The next one runs the relational database, which is the central point of SNDC deployment and each container is using it.

Finally, there is a container that runs the SDNC controller itself. This is the one we are in particular interested in because it has all the logic behind the execution of directed graphs.

We found out that the SDNC container takes more than 300 seconds to initialize and it consumes 1,125 GiB of RAM after initialization. We were thinking – could we do something to make it more efficient? comes to the rescue!

Migration of SDNC to

As we already mentioned, SDNC is based on Opendaylight and what we wanted to achieve is make it more efficient and more suitable for microservice deployments. This is exactly the use case for We decided to migrate SDNC from Opendaylight to and build our own Docker image for it.

We cover some of the technical aspects behind this migration in a separate article, here we will only summarize our achievements:

  • Ability to execute directed graphs (you can see it in action in our video)
  • Less memory usage
  • Quicker startup time

Here is a simple table with a comparison of our Pantheon SDNC container with vanilla SDNC container:

Vanilla SDN-C SDN-C container
Initialization time[1]388 s147 s
Memory usage after startup1,125 GiB613,1 MiB
Memory usage after test graph[2] execution1,246 GiB937 MiB
Average execution time of test graph1,49 s1,2 s
Average cpu[3] usage during test graph execution115,27 %108,06 %

[1]The execution time of init script running in containers

[2]The graph used for testing reads data from MD-SAL and writes them to log 1000 times in a loop.

[3]Containers have available 4 CPU cores


Thanks to the migration exercise we proved that even a quite complex application can be migrated to in a short time and achieve measurable improvements. Click here to read more about the migration process!

If you are interested in further SDN/C performance and architecture optimizations, contact us!