In contemporary SDN world, ONAP (Open Network Automation Platform) is quite a trend. ONAP is a big project composed from 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.

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

SDNC deployment architecture

ONAP SDNC deployment is composed from several Docker containers. One of this 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. Next one runs relational database, which is central point of SNDC deployment and each container is using it. Finally there is the container which runs the SDNC controller itself. This is the one we are in particular interest of, because it has all the logic behind 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 technical aspects behind this migration in 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 comparison of our Pantheon SDNC container with vanilla SDNC container:


Vanilla SDNC container

Pantheon SDNC container

Initialization time[1]

388 s

147 s

Memory usage after startup

1,125 GiB

613,1 MiB

Memory usage after test graph[2] execution

1,246 GiB

937 MiB

Average execution time of test graph

1,49 s

1,2 s

Average cpu[3] usage during test graph execution

115,27 %

108,06 %

[1]Execution time of init script running in containers

[2]Graph used for testing reads data from MD-SAL and writes them to log 1000 times in 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 short time and achieve measurable improvements. Click here to read more about the migration process!


If you are interested in further SDNC performance and architecture optimizations, please subscribe ( or contact