Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The SDN-C project provides a global network controller, built on the Common Controller SDK, 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.

In the Amsterdam Beijing release, the SDN-C project will be used to manage, assign and provision network resources for the Amsterdam Beijing release use cases, listed in the Use Cases section below.

...

The use cases supported in the Amsterdam Beijing release are:

  • Virtual Domain Name Server (vDNS)
  • Virtual Firewall (vFW)
  • Virtual Voice over LTE (vVoLTE)
  • Virtual Customer Premise Equipment (vCPE)

...

The Minimum Viable Product for Amsterdam Beijing is the set of capabilities needed to support the use cases listed above. 

...

One critical long term objective for the SDN-C project is support for integration with other third party SDN Controllers (e.g. Open Contrail), well as integration with the SDN Agent project from Open-O.  For the Amsterdam Beijing release, since our primary goal is to support the user use cases identified above and to improve platform maturity, the degree to which we support such integration will be dictated by the needs of those use cases.  However, we do want to bear in mind that such integration is critical and will be included in our release plans going forward.  

...

  • Active and Available Inventory (A&AI)
  • Common Controller SDK (CCSDK).
  • Service Design and Creation (SDC)
  • Data Movement as a Platform (DMaaP)
  • Documentation
  • Integration
  • External API
  • Modeling
  • Multi VIM/Cloud
  • PolicyNote: not sure if this applies to release 1.  Will depend on whether needed to support release 1 use cases

Architecture

High level architecture diagram

...

Refering to CII Badging Security Program and Platform Maturity Requirements, fill out the table below by indicating the actual level , the targeted level for the current release and the evidences on how you plan to achieve the targeted level.

AreaActual LevelTargeted Level for current ReleaseHow, EvidencesComments
Performance00
1
Awaiting guidance from Benchmark subcommittee
  • 0 -- none
  • 1 – baseline performance criteria identified and measured
  • 2 & 3 – performance improvement plans created & implemented
Stability0
2SDNC will perform 72 hour soak at component level. We assume that integration team will also do a 72 hour ONAP soak which includes SDNC.
1
  • 0 – none
  • 1 – 72 hours component level soak w/random transactions
  • 2 – 72 hours platform level soak w/random transactions
  • 3 – 6 months track record of reduced defect rate
Resiliency12In Beijing, CCSDK will support a clustered OpenDaylight configuration in Kubernetes, as well as a clustered database, to allow for automated detection and recovery within a site. SDNC will use that configuration to meet this requirement.
  • 0 – none
  • 1 – manual failure and recovery (< 30 minutes)
  • 2 – automated detection and recovery (single site)
  • 3 – automated detection and recovery (geo redundancy)
Security01SDNC will improve test coverage to > 50%
  • 0 – none
  • 1 – CII Passing badge + 50% Test Coverage + 50% test coverage
  • 2 – CII Silver badge; internal communication encrypted; role-based access control and authorization for all calls
  • 3 – CII Gold
Scalability01SDNC can be scaled either by adding additional OpenDaylight containers and/or database containers, or by deploying multiple instances of SDNC cluster.
  • 0 – no ability to scale
  • 1 – single site horizontal scaling
  • 2 – geographic scaling
  • 3 – scaling across multiple ONAP instances
Manageability11SDNC will support ONAP standard logging.
  • 1 – single logging system across components; instantiation in < 1 hour
  • 2 – ability to upgrade a single component; tracing across components; externalized configuration management
Usability11See readthedocs and wiki.
  • 1 – user guide; deployment documentation; API documentation
  • 2 – UI consistency; usability testing; tutorial documentation

API Incoming Dependencies

...

API NameAPI DescriptionAPI Definition DateAPI Delivery dateAPI Definition link (i.e.swagger)
HealthcheckAPI used to verify that platform is available and healthyIncluded in seed codeDelivered in seed codeTBD (requested Confluence OPEN API to be installed so this can be published on ONAP Wiki)
Generic VNF APIAPI used to request resources for VNFs. Will be deprecated in Beijing in favor of Generic Resource API.Included in seed codeDelivered in seed codeTBD (requested Confluence OPEN API to be installed so this can be published on ONAP Wiki)
Generic Resource APIAPI used to request resources for VNFs. This API is a superset of the generic VNF API, which it replacesIncluded in Amsterdam releaseDelivered in AmsterdamTBD (requested Confluence OPEN API to be installed so this can be published on ONAP Wiki)

Third Party Products Dependencies

...

Jira
serverONAP JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
maximumIssues20
jqlQueryproject=SDNC and issuetype in (bug) and status!=CLOSED fixVersion="Beijing Release"
serverId425b2b0a-557c-3c0c-b515-579789cceedb

...