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.

Scope:

  • 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?
      • NETCONF, YANG
    • 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.



Resources:

    • 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] 
Committers:

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

Collaboration:

  • Meeting TBA 
  • IRC - freenode.net #onap-sdnc 
  • Mailing List: onap-sdnc@lists.onap.org     To subscribe click here.

  • No labels

41 Comments

  1. undefined undefined

    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: https://gerrit.onap.org/r/gitweb?p=appc.git;a=tree;f=appc-adapters/appc-ssh-adapter;h=56c169ccc38ff37c820d0e2bb122d55f9a0e430c;hb=5f45405d2e3e8c9470bb9a500699dd9cd73d1683

    2: https://gerrit.onap.org/r/gitweb?p=appc.git;a=tree;f=appc-dispatcher;h=9a7e3f736bbdb4a8c4037fc93821bbc95405ed6d;hb=5f45405d2e3e8c9470bb9a500699dd9cd73d1683

    Thanks.

    1. Reuben Klein

      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. undefined undefined

        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. Brian Freeman

    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. Eric Multanen

      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. Brian Freeman

    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. Olivier Augizeau

      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. Dan Timoney

    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. Brian Freeman

    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. Brian Freeman

    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. Yan Yang

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

  7. Brian Freeman

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

  8. Parviz Yegani

    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. Tao Shen

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

  9. Parviz Yegani

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

    1. Tao Shen

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

  10. Olivier Augizeau

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

    1. Dan Timoney

      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. Ganesh Chandrasekaran

        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. Olivier Augizeau

    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. Olivier Augizeau

    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. Tao Shen

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

  13. maopeng zhang

    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. Olivier Augizeau

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

    1. Reuben Klein

      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. Catherine Lefevre

    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. Parviz Yegani

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

  17. Linying Huan

    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. Cheng (Ian) Liu

    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?

    Thanks!

  19. Dan Timoney

    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. Brian Freeman

    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. Cheng (Ian) Liu

    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. Brian Freeman

    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. Cheng (Ian) Liu

      Thanks for the clarification.

  23. jianguo zeng

    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. Dan Timoney

      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. Manoj Nair

    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. Dan Timoney

      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. Zhuoyao Huang

        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. Michael O'Brien

    Thomas,

        Welcome!, it is very good to see you here at ONAP - your book is on both of my shelves - https://www.amazon.ca/Network-Function-Virtualization-Ken-Gray/dp/0128021195

    /michael

  26. Pasi Vaananen

    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,

    Pasi