...
- ONAP component functions should be designed/used for/by not only ONAP but also non-ONAP.
- ONAP component functions can be substituted and/or extended by vendors/operators
- Component dependencies and couplings to other ONAP components should be removed.
- Those dependencies and couplings could be both syntactic and semantic
- Intra-ONAP component interfaces and communications should not be ONAP-specific.
- Aligning with standards where possible (e.g., ETSI NFV MANO, ASD, 3GPP SA5…) should be global requirements
- If there must be a deviation, that can be done in an extensible way that enables the standard-based approach
- The exposed service interfaces should be for both ONAP and non-ONAP; promote ONAP component interfaces as LFN de facto standards
- If exposed service interfaces conform to industry standards (e.g., ETSI SOL005, ETSI SOL003, 3GPP SA5), the interactions between the service provider and consumer would be simplified (e.g., VFC case in this diagram)
- For now, the service consumers can use “adapters” which choose a desired service interface
- e.g., AAI interfaces
Action Points
- Promote ONAP component API models and interfaces, as open-source (at least LFN) de facto APIs
- Study the following ONAP component exposed service API models and interfaces
SDC Service Provider Interfaces
...
- DMaaP-1: DMaaP Bus Controller
- DMaaP-2: DMaaP Message Router Source
- DMaaP-3: DMaaP Message Router Consuming Interface
- DMaaP-4: DMaaP Data Routing Source
- DMaaP-5: DMaaP Data Routing Consumption Interface
Action Points
- Promote ONAP component API models and interfaces, as open-source (at least LFN) de facto APIs
- Study ONAP component exposed service API models and interfaces
ONAP Component Runtime Security Analysis
...