This documents the strawman proposal (presented at ONAP Session September 27, 2017) for how to handle requirements that would be of interest to the ONAP operators as they implement ONAP into production.
Inputs
Notes from the Tuesday September 26th discussion at ONAP meeting
R2 Proposed Non-Functional Requirements
General Approach
- The goal of this effort is to define requirements to enable ONAP for carrier implementations. It is not to deliver a specified carrier-grade configuration of ONAP, but to build all the software hooks necessary for an operator to deliver a 5-9’s carrier grade environment at their own expense
- Process
- For each category of carrier-grade requirements, multiple levels of requirements will be established and presented to the TSC.
- The Architecture Committee, in cooperation with the project teams, will establish guidelines for requirement levels that must be met by each project for each release. The required level may be influenced by: MVP project status, desired project maturity level, release inclusion, component criticality (run-time vs. design time).
Performance
- Level 0: no performance testing done
- Level 1: baseline performance criteria identified and measured (such as response time, transaction/message rate, latency, footprint, etc. to be defined on per component)
- Level 2: performance improvement plan created & implemented for 1 release (improvement measured for equivalent functionality & equivalent hardware)
- Level 3: performance improvement plan implemented for 2 consecutive releases (improvements in each release)
Stability
- Level 0: none beyond release requirements
- Level 1: 72 hour component-level soak test (random test transactions with 80% code coverage; steady load)
- Level 2: 72 hour platform-level soak test (random test transactions with 80% code coverage; steady load)
- Level 3: track record over 6 months of reduced defect rate
Resiliency
- Level 0: no redundancy
- Level 1: support manual failure detection & rerouting or recovery; tested to complete in 30 minutes
- Level 2: support automated failure detection & rerouting
- within a single geographic site
- stateless components: establish baseline measure of failed requests for a component failure within a site
- stateful components: establish baseline of data loss for a component failure within a site
Level 3: support automated failover detection & rerouting
across multiple sites
stateless components
improve on # of failed requests for component failure within a site
establish baseline for failed requests for site failure
stateful components
improve on data loss metrics for component failure within a site
establish baseline for data loss for site failure
- These levels may drive the need for a common platform for resiliency & approaches to consistently provide resiliency across ONAP. Such a platform might contain:
- a geo-distributed database that supports both within and cross-site state replication
- a failover mechanism that performs failure detection, request rerouting and the actual failover and
- a site/replica selection service that picks among the appropriate replicas during request rerouting.
Security
Project-level requirements
- Level 0: None
- Level 1: CII Passing badge
- Level 2: CII Silver badge, plus:
- All internal/external system communications shall be able to be encrypted.
- All internal/external service calls shall have common role-based access control and authorization.
- Level 3: CII Gold badge
ONAP Platform-level requirements (Security subcommittee to finalize percentages)
- Level 1: 70 % of the projects passing the level 1 (with the non-passing projects reaching 80% passing level).
- Level 2: 70 % of the projects passing silver (with non sliver 80% of passing level towards silver)
- Level 3: 70% of the projects passing gold (with non gold at 80% passing level towards gold)
- Level 4: 100 % passing gold.
Scalability
- Level 0: no ability to scale
- Level 1: supports single site horizontal scale out and scale in, independent of other components
- Level 2: supports geographic scaling, independent of other components
- Level 3: support scaling (interoperability) across multiple ONAP instances
Manageability
- Level 1:
- All ONAP components will use a single logging system.
- Instantiation of a simple ONAP system should be accomplished in <1 hour with a minimal footprint
- Level 2:
- A component can be independently upgraded without impacting operation interacting components
- Transaction tracing across components
Usability (applies to entire ONAP Project)
- Documentation completion/consistency [need metric]