Skip to end of metadata
Go to start of metadata

Project Name:

  • Proposed name for the project:  SDN Controller (SDN-C)
  • Proposed name for the repository: sdnc SDNC

Project description:

The SDN-C project provides a global network controller, built on the Common Controller Framework, which manages, assigns and provisions network resources.   As a "global" controller, the SDN-C project is intended to run as one logical instance per enterprise, with potentially multiple geographically diverse virtual machines / docker containers in clusters to provide high availability.  The project also will support the ability to invoke other local SDN controllers, including third party SDN controllers.


  • The following features are in scope for the SDN-C project for ONAP release 1:
    • Enhancements to support the ONAP release 1 use cases (vCPE, VoLTE)
      • Yang models, 
      • Directed graphs
      • New Adapters needed to support use cases (details to be determined during planning phase)
    • Support for third party controllers:
      • Adapter to allow DG to connect to netconf devices (netconf-lite)
    • High availability (local)
  • The following features will be defined for the project:
    • Configuration versioning : ability to roll back the configuration
    • CLI adaptor : abstraction layer for CLI adaptor
    • Support for third party controllers:
      • Adapter layer to interface with downstream controllers
    • Support for geographically distributed network resources
    • QoS support

Architecture Alignment:

    • How does this project fit into the rest of the ONAP Architecture?
      • This project provides the global network controller used by ONAP to manage network resources
    • How does this align with external standards/specifications?
    • Are there dependencies with other open source projects?
      • OpenDaylight
      • ONAP Common Controller SDK
      • Service Orchestrator (main client calling SDN-C)
      • Microservice Bus (if that is used for the SO - SDNC interface)

        The slide below is the high level architecture vision for the SDN Controller showing all the various components in the vision and relationship to other entities. Not all of this vision is implemented in ONAP but it helps to show the breadth and depth of direction.

The picture below shows an example of an SDNC platform based component and the major components like the Admin portal, DG Builder and the mysql RDBMS as well as examples of adapters that might be used by SDNC-G or APPC in their applications.

This diagram shows how applications on top of the SDNC platform relate to the SDNC platform. SDNC-G can have its own client tables, execute nodes , configure nodes and is uniquely defined by its Directed Graphs and Service YANG models.

The platform provides the SLI, the Mysql database and the installation and startup of Opendaylight. Application can chose to use the DMaaP client provided by the SDNC platform or build their own as needed. Using DMaaP to publish events is a new feature required for some applications so that is part of the application and not part of the platform right now.


    • Primary Contact Person: Dan Timoney (AT&T), Parviz Yegani (Futurewei Technologies)

Names, gerrit IDs, and company affiliations of the committers:

Names and affiliations of any other contributors:

Key Project Facts

Project Name:

  • JIRA project name: sdnc
  • JIRA project prefix: sdnc

Repo name:

  • org.onap.sdnc/architecture
  • org.onap.sdnc/features
  • ...

Lifecycle State: incubation
Primary Contact: Dan Timoney (AT&T), Parviz Yegani (Futurewei Technologies)
Project Lead: Dan Timoney (AT&T), Parviz Yegani (Futurewei Technologies)
mailing list tag [sdnc] 

*Link to TSC approval: 
Link to approval of additional submitters: 


  • Meeting TBA 
  • IRC - #onap-sdnc 
  • Mailing List:     To subscribe click here.

  • No labels


  1. Hi,

    Can you please elaborate on the "CLI Adapter"? I see in APPC project that there are modules for appc-ssh-adapter (1) and appc-dispatcher (2), that seem to be in the context of CLI execution on a device. Is the plan to leverage these adapters and provide an abstraction layer? If so what is the reason behind doing it in SDNC? Is there any documentation about how to use these appc adapters?




    1. appc-dispatcher is a module that invokes the appropriate DG based upon the Action and the VNF-type. It parses the APP-C Action request and passes it to the working code.  It should have nothing to do with CLI interface support.

      1. Thanks for clarifying Reuben. The submodule name (appc-command-executor) made me think so. Good to know that APPC has the CLI adapters to use with devices that are not fully NETCONF+Yang compliant.
        How does the Directed Graphs interact with the appc-ssh-adaptor? I only see the plugin for REST API calls.

  2. We have CLI adapters in SDNC and APPC that generally use a ssh connections to send commands and parse responses. Rollback is a pain if its not a netconf session. Why wouldn't we use netconf with the vCPE ? or are we just talking in general we want a CLI adaptor specific to vCPE from a specific vendor ?

    1. The interest in the CLI adapter came up during discussion to account for controlling devices that did not support netconf.

      Also, wouldn't the CLI adapter(s) become part of the Controller Framework project that can be used by both sdnc and appc projects - or are they too specialized per device/use case?

  3. I think the APPC CLI adaptor is already open sourced since its more about applying a template to the device (I think).  I don't think we have current plans to open source the SDNC one's since they have some proprietary parsing but it depends on the use cases we need for ONAP. The actual ssh part is simple and re-usable but the harder problem is dealing with vendor variations in how to do an update (lists in particular are a pain via CLI in some cases when the vendor doesn't support a add/delete but instead you have to recreate the whole list). That being said - where it makes sense we are open for making more available in open source where it could be re-used.

    1. I fully subsribe to the ssh/CLI interface to manage devices not supporting netconf (it is currently a lack in OpenDaylight).

      Have you considered using an expect librayry (Expect4j, ExpectIt, ...) to help the ssh/CLI driving? 

  4. I updated the writeup above a bit to fit better in the template.  Summary of changes:

    • Added a short description of the sdnc project, describing it as the ONAP platform's global network controller.
    • Moved the former contents of "project description" to the "scope" section, since that seemed to be a better fit, with some minor editorial changes.
  5. Do we want to also include an opensource IPAM like phpipam as a optional component/container for resource assignment for use case/CI/CD ?

  6. The Use Case will need to document the devices that need to be configured and the resource assignments that need to be made. This can be done in the planning phase but will impact the amount of work to be done if non-netconf devices are being used.

    1. We will add this part of the equipment requirements in VoLTE's Use Case

  7. Do any of the use cases require an SDNC application to also be a local controller for configuration of owner operated cloud (e.g. or leaf/spine equipment ) or is that out of scope for R1 ?

  8. Added a figure to illustrate the detailed view of the SDN-C software platform architecture. This can be used as a reference for adding any new functionality to support the features targeted for ONAP Release 1.

    1. the current diagram is not show how SDN-C is supporting the third party SDN controller. is there anything more detail?

  9. Added a place holder for regular weekly meetings plus the IRC link.

    1. is there any weekly meeting? I'd like to attend.

  10.     Is upstreaming to OpenDaylight the ONAP SDN-C code will be considered?

    1. The one reservation I would have here is that there seemed to be some interest in other SDN controller frameworks (notable ONOS) expressed at the Middletown, NJ developer event.  While we are based on OpenDaylight today,  most of the SDN-C code is actually just OSGi modules and would run just fine in other OSGi containers.  

      That having been said, if we find a need to change any of the base functionality within ODL itself, then I absolutely agree that we should upstream those changes back to OpenDaylight. However, I think we need to be careful to keep this project separate as much as possible so that we're not tightly coupled.

      1. I am interested in seeing how we could integrate ONAP (SDNC & APPC) with ONOS controller (instead of ODL), is there a specific tutorial or document that describes how I could combine SDNC's code with ONOS's OSGi modules? This would mean ONAP will now use ONOS controller to do the network and orchestration control. 

  11. Should the SDN-C be a universal mediation gateway between the network elements and other ONAP components? Example: network element data collect for DCAE. Should it be direct or using SDN-C? Is there any relation with the OpenDaylight:TSDR project?

  12. Is the SDN-C really responsible of network resources management and network function integrity? (or is it the Service Orchestrator)? I think it is a very important question (at least for underlay scenarios) to anticipate multi-controllers scenarios (e.g. network with thousands of devices), real-time scenarios, ...

    1. In VoLTE usecase, we have requirements for both underlay and overlay. Does SDN-C considering both underlay and overlay? or overlay only?

  13. Network resources include the underlay and overlay resources of WAN connection or connections in the cloud, which is also can be used between VNFs or be used between the VNF components.  could the SDN-C describe the managed netwrok resource scope? is it in charge of E2E connections for the service? How does it integrite with the SO, App-c, and VF-C? How does it integrite with the local SDN controllers? Thank you.

  14. Please, could you explain what "geo diversity" stands for? (Does it mean huge networks with several geographical/management areas ?)

    1. geo-diversity refers to structuring functionality in such a way that a single site disaster could be handled by components running in other locations.  Thus, any impact to the network which would be localized in any single geographic location could be accommodated through the operation of remote (i.e., geographically diverse) components running at other sites.

  15. I also would like to consider the following JIRA items as part of this proposal if these are not solve earlier:

    SDNC-1 - Getting issue details... STATUS

    SDNC-4 - Getting issue details... STATUS

    SDNC-6 - Getting issue details... STATUS if the epic is approved (COMMON-10)

  16. Added "Key Project Facts" and renamed "geo diversity" to "Support for geographically distributed network resources" to address Oliver's question.

  17. I'd like to know the details of the feature "Support for third party controllers". How to support the 3 party controllers? Is there any requirements to the third party controllers?

  18. Follow up on Linyong's question above, I am also trying to understand the following item in the Scope of Work:

    "Support for third party controllers:

    • Adapter to allow DG to connect to netconf devices (netconf-lite)"

    May I know what exactly is netconf-lite? And its relationship with supporting 3rd party controller?


  19. Netconf-lite is an adaptor that allows directed graphs to connect to devices that adhere to the NETCONF protocol.  If a third party controller exposes a NETCONF interface, then netconf-lite could be used to interface to that controller

  20. Netconf-lite also adds support for multiple device transaction locking. Lock 1, Lock 2, Lock 3 ; Edit Config 1,2,3, check commit 1,2,3 , commit 1, 2,3, unlock 1,2,3. If check comit 1 ,2 or 3 fails can use netconf rollback before the commits.

  21. Thanks to Dan Timoney and Brian Freeman for the answer. Will this Netconf-lite adapter code be added in SDN-C codebase or APP-C codebase or even the common controller framework for Release 1? I saw there is a Netconf adapter in current APPC codebase with limited features. I guess this Netconf-lite will replace that?

  22. I would be the the common controller and then applications like SDNC or APPC could use it as needed. I don't think APPC will change existing DGs to use netconf lite. They will wait till they have a use case that requires the additional functionality.

    1. Thanks for the clarification.

  23. Can the Scope part try to define What capability plan to support for R1 use case? what's the sample input and output to SDN-C(in a black box way)?

    For example: what's kind of service/function can SDNC support for vCPE or VoLTE usecase(assuming DG was write correctly) ? I understand It only support overlay network only,  but what kind of overlay: VxLAN or IP port assignment. the output is Neutron API, can we have a sample (similar CLI command: create subnet, create IP , create Port, bind IP to port ...)

    1. I think the information you're looking for is in the SDNC Amsterdam release planning template - here's the link : Release Planning Template : SDNC Amsterdam Release

      The more detailed view really will be captured as Epics and User Stories in Jira.  The release planning template has a live link to those Epics and User Stories, so as we flush out the details the release planning template will get more meat to it.

  24. Couple of questions on the new diagram being posted by Brian

    1) If I understand correctly ODL maintains config and operational data in MD-SAL data store. Is this data synchronized with A&AI inventory ? 

    2) From the description above I assume MySQL DB is used only for storing the DG data .Is the metrics collected by SDNC is meant to be stored in MySQL DB/MD-SAL and shared with ONAP DCAE ? I see in the first diagram a local network DCAE. Is this a logical function that is originally implemented in ONAP DCAE or this is planned to be built using some of the exesting ODL projects like TSDR ? 

    3) I see in Common Controller SDK project, a new cloudify based component is planned to be integrated with SDNC. This will be a common microservice shared by all controller functions ? If so will the API Handlers, functions which convert artifacts from SDC will cease to exist post this integration ? 

    1. 1)  It's generally best to think of the MD-SAL data store as a local cache of data that is critical to the operation of the controller, where A&AI is a more global view of the service.  There is some data in MD-SAL that is not maintained in A&AI, since it is really only of interest to the controller itself (things like its internal state).  There is other data in MD-SAL that is a local cache of data that is mastered in A&AI.  For that data, the controller synchronizes its data with A&AI.

      2) The local MySQL DB is used for more than just the DG data.  It also is used to store data that is a better fit for a relational database than a network database, such as resource inventories (e.g. tables of VLAN tags available for assignment).    I believe that local DCAE in the first diagram is an older view, before there was a separate DCAE function (Brian - please keep me honest if I got that wrong!)

      3) The CCSDK project really serves 3 distinct types of controllers : SDN Controller, DCAE , and OOM.  The cloudify based component is more directly applicable to the OOM project, at least for release 1.

      1. 2) The local MySQL DB is used for more than just the DG data.  It also is used to store data that is a better fit for a relational database than a network database, such as resource inventories (e.g. tables of VLAN tags available for assignment).  

        >>>>> The data stored in local MySQL DB is accessed only by SDN-C? Or anyone else in ONAP? If the data is accessed only by SDN-C, is that means all projects should have a local relational database? And where should we store the global data which is better fit for a relational database? If anyone else in ONAP could access the data, is that means SDN-C is a global data store like A&AI?

  25. Thomas,

        Welcome!, it is very good to see you here at ONAP - your book is on both of my shelves -


  26. Few questions:

    1.) Is there a set of "basic" L2/L3 (or even higher layer) network service definitions that are exposed through the controller APIs ? If so, could someone provide a pointer to where to look for details ?

    2.) Is there any detail on how hierarchy of controllers is expected to look like, such as say site-resident "datacenter" or "NFVI-PoP" level controllers - even if the controllers at each level are ODL based ? How are the control process responsibilities divided between the levels ? Any insight on scaling targets - i.e. how many lower level controllers should top level controller cluster support ? If this exist, pointer would be welcome ? 

    Asking because #1 ultimately affects what needs to be supported in underlying infrastructure under/overlay networks, and #2 affects scalability and what should be done where...

    Thank you,