Brief Project Overview (brief as it should be known)
In order to deal with E2E service orchestration across different network domains, there are ONAP components that need to be logically centralized, such as the Inventory or entry-point of service orchestration or use of common models for services and resources.
Examples of such scenarios :
- Services deployed into the data centres, and 'infrastructure' type services within the datacenter
- E2E services such as 5G network slicing
- Services spanning across different domains (wireline, wireless, data centre, underlay and overlay services)
- Any business needs requiring E2E view and interactions between those different services and resources
New component capabilities for Guilin, i.e. the functional enhancements, if applicable
New or modified interfaces
If they are modified, are they backwards compatible?
Interface naming (point to an example)
Consumed API from other projects
Project | API Dependency | Notes |
|---|---|---|
Published API
Project | API | Notes |
|---|---|---|
Reference to the interfaces.
(Reference to the the swagger.json file(s) whenever possible)
What are the system limits?
.
Involved use cases, architectural capabilities or functional requirements.
Listing of new or impacted models used by the project (for information only).
- Identify any High Level Information Model Requirements. See: ONAP R7 Modeling High Level Requirements
- Models based on information exchanges from Use Cases
- Models documenting existing implementations
- Forward looking models that may be implemented in future releases
- Describe how exposed APIs are mapped to information models
(list all the relevant Jira tickets)