Page History

...

• Different API Management approaches: In ONAP each component exposes own APIs corresponding to the functionality supported. In addition to this, each project follows different approaches for API security, API documentation, and moreover API style itself (entity based, action based etc). This creates a lot of burden for the API consumer, especially use case developer who is focused on the high-level functionality to be leveraged than component level API intricacies (version, security, style, etc.). There should be consistency across components in defining APIs or there should be a logical layer (Facade)  which hides these inconsistencies/complexities so that the API consumer need not build different set of adaptors or require different expertise to consume the component level APIs.
• Standard Alignment is a priority in ONAP: In recent releases, standard API interface and model alignment became a hot topic of discussion. Currently, standard API alignment is addressed by individual projects independently depending on specific use cases. There is also the redundant implementation of adaptors – for example, SOL005 API adaptor proposed for SO/Ext-API , SOL003 API Adaptor in SO for S-VNFM connectivity, SOL003 adaptor development in VFC, SOL005 adaptor development in VFC NFVO, SOL003 adaptor in SDNC etc. There should be a consistent adaptation layer that can be consumed by internal and external API consumers so that maintenance and compliance of the APIs can be managed well.
• Production deployments require interoperability with legacy and 3rd Party components: In typical production deployment of ONAP, it will require integration with legacy and 3^rd Party applications in the operator premise. Currently, the expectation is that System Integrator responsible for the deployment build appropriate integration layer and enable interoperability with such external applications. But this is not a healthy and consistent solution as ONAP component level interfaces evolve over releases and for applications, this becomes unmanageable as these ONAP interface APIs have some times release specific dependency and non-backward compatible. There should be a logically centralized function in ONAP which can abstract component level API evolution and expose a higher level API as well hides the dynamics at the individual component APIs. Additionally, integration with 3rd party applications in productions environment might require different types of policy enforcement, different types of adaptations. In production deployments, ONAP components may not be compatible with operators IT systems -  for example, the operator might already have an Identity Provider and Auth Provider which are not compatible with AAF. Such scenarios might require additional capability in ONAP where these incompatibilities can be accommodated rather than instrumenting each ONAP project. Another requirement is related to Modularity - Not all components in ONAP might be required in the Operator production environment, depending on the evolutionary stage of transformation. They might have already procured redundant functions as in ONAP that fulfill the use case requirements. This leads to a requirement where different  ONAP components (not in full but selectively) need to be composed at different levels of abstractions and integrated with existing solutions.  One such scenario is Legacy NFVO integration with ONAP as discussed in the Orchestration Scenarios task force-  Similar requirement would require special integration which if handled at individual ONAP project levels may soon become unmanageable.  
• Evolution of platform functional capability vs use case based functional enhancements : This is a typical problem in most of the open source projects - the area the project should focus – i.e. to focus on developing functional capability and make it more generic for any use case to adapt or to enhance functional capability based on specific use cases. In ONAP the functional capability of projects is primarily driven by use cases. The requirements for each use case might be different or might require a different level of capability enhancements at the project level. For project teams, this creates lot of pressure to balance requirements across use cases and also to focus on progressing the functional capability for long term requirements. There should be a logical boundary where both such requirements - from use case or from project functional enhancement – should balance. The boundary should be an API layer which cushions the impact and hides the project level evolutions at the same time supports current and future use cases. 

...

Currently, there is no proposal to replace any of the existing components in ONAP. Some of the redundant functionality that exists between API GW and ONAP Components such as Ext-API and MSB can be managed through collaboration and mutual agreement. API GW can also potentially be a subproject of either Ext-API or MSB to augment the missing capabilities in respective projects. Another potential option is to merge functionality in Ext-API, MSB, and API-GW to create a single API Management/Adaptation component. Please note the comparison of API GW and existing ONAP projects like Ext-API and MSB below. The comparison also covers what additional capability API GW can bring in to augment the existing functionality.  

Architecture

Image Removed

As for this proposal, the directions provided by Architecture committee and TSC will be followed once the need for such functionality is agreed with all stakeholders. 

Architecture

Image Added

API GW consists of four main building blocks – Gateway, API GW Management Component, API GW Configuration store, API GW UI. Gateway function is a stateless reverse proxy which can be instantiated on demand, scaled and distributed. It hosts a set of plugins that enhance the API control logic. The plugins are developed using the gateway SDK and attached as a library during the initialization. Gateway and Plugins refers the API configuration (i.e information about the on boarded API) from Configuration and Analytics data store. The Configuration & Analytics DS persists the API configuration and API transactional metrics. API GW can work with an inbuilt Auth provider capable of centrally managing the Authentication, Authorization of the exposed APIs. The API GW UI hosts the Management, Design and Monitoring UIs. The GW function maintains statistics and log information of APIs and stores the information in the Configuration and Analytics store. It is also possible to integrate the Configuration and Analytics Store with external monitoring solutions like Prometheus or alert engines to notify external consumers about API statistics.

...

• Existing Capabilities in MSB
  • API Endpoint Registration and Discovery
  • Static API Endpoint Routing based on port and Service URL (No payload-based routing)
  • API Load balancing
  • Service Mesh Integration Prototype
  • Integration with AAF for security policy enforcement (?)
  • Integration with OOM for dynamic Service Registration
  • Management APIs for registration of Services
• Capabilities Augmented by API GW Solution
  • Full API Lifecycle Management
  • Manual and Bulk API Import – Swagger or Management API
  • API Subscription/Plan management, API Discovery
  • API Catalog and Marketplace
  • Integration with multiple external IDP, Monitoring solution
  • Rate Limit, Quota Mgmt , Circuit Break
  • Tenant, Role Management
  • Whitelisting , Black Listing
  • Enhanced API Security Management – OAuth2, JWT,
    Open ID etc. – All inbuilt and centrally managed
  • Script insertion in the API execution flow
  • Configurable APIs, Transformation logic
  • API Aggregation and Composition
  • Management and Monitoring UI
• How does this project fit into the rest of the ONAP Architecture?
  API Gateway provides an API and UI interface. API can be used by components in ONAP or by administrative users to manage the lifecycle of high-level APIs. UI is primarily intended for an administrator to provision and manage APIs. The UI is also suitable for the end user as the API GW provides a consumer view – API Marketplace which can be used to subscribe to specific APIs.
• What other ONAP projects does this project depend on?
  OOM for deployment, MSB or Specific ONAP components whose APIs need to be abstracted behind a façade API (standard API), AAF for Security – Authorization, Authentication and Certificate Management
• In Relation to Other ONAP Components

...

• Meets Board policy (including IPR)

NA

• Note on Open Source Solution: We plan

Plan to develop Project PoC using the Gravitee API Gateway Solution which is cloud-native, developer-friendly and features rich. However, we are also open for adapting other API GW solutions such as Kong or Gloo. Kong is based on nginx and OpenResty and similar capabilities like Gravitee but requires the extension to be written in unpopular Lua script. Gloo is a project endorsed by CNCF and has a dependency on

...

Envoy proxy, so can be considered when ONAP migrates to a service mesh based microservice communication model.

 Use the above information to create a key project facts section on your project page

Note on S3P : 

• Scalability: Depends on the particular open source solution being selected - Majority of the open source API GW solutions support distributed scaling. 
• Security: To be discussed with the Security Subcommittee - API GW inherently supports rich security management features - OAUTH2.0, Open ID Connect, Certificate management etc. 
• Stability: All the proposed features are from mature API GW open source solutions which are in the production environment. Guidance from Architecture team on specific areas awaited.
• Performance: For API GW two aspects of performance is critical - Latency and Num of Requests per Second. Latency depends on the complexity of API and associated nested operations that need to be carried out for a particular API.  The number of requests handled by API GW depends on the scalability features provided by the API GW. Performance benchmark can be carried out based on the requirements set by the S3P team or specific use cases. 

Key Project Facts

Release Components Name

Note: refer to existing project for details on how to fill out this table

Resources committed to the Release

...

Note 2: It is critical to complete all the information requested, that will help to fast forward the onboarding process.