Brief Project Overview (brief as it should be known)

SDNC is a network controller based on CCSDK, which provides most of the base functionality used to implement the network controller. The SDNC project assembles those components, adding real-time configurable service logic (aka directed graphs) to implement network controller instances or "personas".


New component capabilities for Guilin, i.e. the functional enhancements.

The following table lists the new functional requirements CCSDK is committing to support for the Frankfurt Release:

RequirementsCompanies Supporting Requirement

REQ-325 - Getting issue details... STATUS

Fujitsu

REQ-345 - Getting issue details... STATUS

IBM

REQ-342 - Getting issue details... STATUS

Huawei, IBM, Wipro

REQ-347 - Getting issue details... STATUS

Huawei, CMCC, Wipro

REQ-322 - Getting issue details... STATUS

IBM

REQ-341 - Getting issue details... STATUS

T-Mobile, Orange

REQ-352 - Getting issue details... STATUS

Ericsson

IBM


Minimum Viable Product

The following epics represent the minimum viable product of the CCSDK Guilin Release:

Key Summary T Created Updated Due Assignee Reporter P Status Resolution
Refresh

The following epics are also in scope for Guilin, but are not considered of the minimum viable product.  In the event of unanticipated resource constraints, these could be reduced in scope or deferred without impacting any functionality deemed by the TSC as critical for Guilin.

Key Summary T Created Updated Due Assignee Reporter P Status Resolution
Refresh

These requirements require enhancements to existing SDNC functionality, as opposed to new interfaces. 

New or modified interfaces

SDNC originally provided 2 interfaces with overlapping capabilities:

  • VNF-API
  • GENERIC-RESOURCE-API

All the capabilities of VNF-API are now also provided by GENERIC-RESOURCE-API.  Our existing ONAP use cases have been updated to use GENERIC-RESOURCE-API instead of VNF-API.  Therefore, our plan is remove the code for VNF-API in the Guilin release.

For Guilin, we plan to provide 2 implementations of GENERIC-RESOURCE-API:

  • The current implementation, implemented as an OSGi feature deployed in the OpenDaylight karaf container.
  • A new springboot-based microservice, which runs in a pod outside of OpenDaylight

The new springboot-based implementation will be considered  a Proof of Concept in Guilin, with a goal of making it the default implementation in R8 Honolulu release.

If they are modified, are the backwards compatible?


Interface naming (point to an example)

CCSDK provides the following APIs which are exposed by SDNC:

  • ASDC-API : RESTCONF interface used to process certain non-TOSCA artifacts distributed by SDC (license model updates).
  • dataChange : RESTCONF interface pub/sub interface that allows controller to be notified on data change events (note: not currently used in ONAP use cases)
  • LCM : RESTCONF interface used to handle LifeCycle Management events
  • SLI-API : RESTCONF interface to service logic interpreter.  Used primarily for health check.
  • selfservice-api : gRPC interface used with CDS
  • oofpcipoc-api : RESTCONF interface used for OOF/PCI integration

SDNC itself also provides the following interfaces, not found in CCSDK:

  • GENERIC-RESOURCE-API : supports assignment of network resources, via automation and preloaded data]

Reference to the interfaces.

All APIs have Swagger documentation, which is referenced in readthedocs

What are the system limits?

Due to limitations inherent in OpenDaylight clustering - which is based on akka - SDNC should always be run with an odd number of replicas. This is needed to guarantee there can be no "ties" in the akka leader election procedure.

Involved use cases, architectural capabilities or functional requirements.


SDNC is used in the following use cases:

  • vFW
  • vDNS
  • vCPE
  • VoLTE
  • CCVPN
  • 5G
  • BBS


Listing of new or impacted models used by the project (for information only).

None




  • No labels