ONAP API Gateway Proposal

Proposed by : NetCracker Technology

Supported by : Vodafone, Swisscom (Discussion with other operators in progress)

07th May 2019

Summary

Management of Internal/External integrations between Components is a

traditional pain point of ONAP Platform (Integrations with 3rd party systems,
Internal integration over Standard APIs, OSS/BSS Integration etc.)

The study defines a problem statement for current situation of API Management
in ONAP, and corresponding proposal for starting a new ONAP Project (or work
with other Projects to fix the gaps)
Agenda

• Problem Statement
• Proposal
• Execution plan
Section 1 Problem Statement
API Management – What is Available Today
A Set of ONAP Components focused on API Mediation/Adaptation & Routing

- External API treats ONAP as a black Ext-API

box and exposes NBI, transforms
standard (TMF) NBI to ONAP internal ONAP as a black box
API ONAP Component ONAP Component
- Multi-Cloud used for
mediating/abstracting interactions
across multiple cloud environments Micro Service Bus
- Controllers (VF-C, App-C , SDNC):
Mediates the LCM of Virtualized ONAP Component
Resources and supports Configuration
Management in a vendor neutral way
- Micro Service Bus routes, Load SDNC, App-C, VFC Multi-Cloud
balances internal API calls to
registered end points
Problem Statement

Production deployments might

Evolution of Platform
Zoo of API Management Standard Alignment is a require interoperability with
functional capability vs.
Approaches: priority in ONAP legacy and 3rd Party
Use Case capability:
components

• APIs are managed at individual • Enhancing multiple components • Need for an API abstraction Platform need to evolve
project level : Each component for standard API alignment is time /façade layer rather than point to independently, not strictly
exposes very low level capability , consuming point integration with each
based on use cases:
not all will be necessary always to component
represent the business logic • Redundant API adaptation logic • Missing an appropriate facade
across different components that • Capability to compose APIs layer to isolate these two needs
• API consumer is depended on the cannot be reused – e.g. SOL003 exposed by different components
component level API intricacies, • Use cases typically expect
adaptor in SO , VFC and SDNC at different levels of abstraction
Entity model rather than what is standard/composite APIs for
and integration with 3rd party ,
necessary and sufficient • Overhead on project teams to wider acceptance and adoption,
External Components
manage standard adaptation than project specific API alignment
• No consistent approach across
core functionality roadmap not completely in sync
projects (security,
with use cases and delay the use
documentation, Version
case development.
compatibility, style etc) in
managing APIs
What is Required?

Centralized API Management / Gateway Function

• A function/framework to build API Façade that gives flexibility/features for following
• Model Driven : Import/Export high level APIs as Swagger file (Not code developed from scratch)
• API LCM, API Market Place , API Catalog, Plan, Subscription Management
• Compose/Aggregate and expose simplified façade APIs for internal service end points
• Content/Payload based API routing
• API Federation across SP/Partner/Opco ONAP instances with desired policy enforcement
• Flexible Security Management (OAuth2.0, Open ID, SSL/TLS, Ext Auth provider integration)
• Circuit Breaking, Timeout, Retries, Rate Control
• Flexible Request and Response Transformation
• API Sharding (Targeted API Deployment)
• Service Capability Discovery (i.e. in addition to URL end point)
• Standard adaptors for transformation (between SDO API and internal API )
• API Policy Enforcement
• Common look and feel and documentation
• Analytics, Metering, Closed and Open Loop Control of APIs
Section 2 Proposal
Proposal: A dedicated API Gateway Function
A new function that is dedicated for managing high level APIs across components.

FEATURES: ONAP Ext-API

• Consolidates API Management in a single
logical function ONAP ONAP ONAP
• Augments Integration Layer capabilities in Component Component Component
ONAP
• Reuse API Routing Functions available in
MSB MSB / DMaaP
• Supports Plugin model to attach request and
response transformation logic Proposed Component API Gateway
• Offload common API tasks from other ONAP
Components (ex. authentication and MSB / DMaaP
aggregation)
• Reuse open source solutions like
Kong/Tyk/WSO2/Zuul/Gravitee/Gloo ONAP ONAP ONAP
Component Component Component
API GW Placement in ONAP Architecture

Option 1
API GW • Option 1: Co-exist with Ext-API , but may
support external and internal APIs on
need basis

Option 2 • Option 2: Co-exist with MSB, but handles

gateway functionality independently.
API GW
MSB handles the Registry and Service
Discovery.
Option 3
API GW • Option 3: API GW exists as an
independent functional component
API GW and ONAP External API

FUNCTIONAL CAPABILITIES IN EXT-API FUNCTIONAL CAPABILITIES AUGMENTED BY API GW

• Management toolsets for configuring API context and endpoint

• Mediation/Adaptation between TMF APIs and ONAP • API Analytics
internal APIs • Full API Lifecycle Management – Onboard, Policy Control, retire, WL,BL
• Leverages JOLT JSON Transformation Templates for • API Subscription/Plan management
Payload transformation • API Policy management
• Order State Monitoring – Hub Resources • Enhanced API Security Management – OAuth2, JWT,
Management for callbacks Open ID Connect etc. – All inbuilt and centrally managed
• Repository for Service Specification Catalog , Service • Script insertion in API execution flow
Order Mapping details • Configurable APIs, Transformation logic than static Code
• Leverages SDC JTOSCA Parser for TOSCA Parsing • Pre-built API Processing plugins
• Static transformation logic and routing implemented • API Aggregation and Composition
in code • Swagger Import and Plugin chaining (API Orchestration)
• Management and Monitoring UI

• External API is close to 30K lines of code and all API adaptors developed from scratch (required custom transformation and enrichment)
• Difficult to manage in the long run – need to leverage a specialized API GW function which can leverage built in plugins and transformation tools
API GW and ONAP MSB

FUNCTIONAL CAPABILITIES IN MSB FUNCTIONAL CAPABILITIES AUGMENTED BY API GW

• Full API Lifecycle Management

• API End point Registration and Discovery • Manual and Bulk API Import – Swagger or Management API
• Static API Endpoint Routing based on port and Service • API Subscription/Plan management
URL (No payload based routing) • API Catalog and Marketplace
• API Load balancing • Integration with multiple external IDP, Monitoring solution
• Rate Limit, Quota Mgmt , Circuit Break
• Service Mesh Integration Prototype • Tenant, Role Management
• Integration with AAF for security policy enforcement (?) • White listing , Black Listing
• Enhanced API Security Management – OAuth2, JWT,
• Integration with OOM for dynamic Service Registration
Open ID etc. – All inbuilt and centrally managed
and Discovery
• Script insertion in API execution flow
• Management APIs for registration of Services • Configurable APIs, Transformation logic using expression language
• Basic MSB UI • API Aggregation and Composition
• Management and Monitoring UI
• Web socket support
• GraphQL support
• MSB is built on NginX and OpenResty with additional plugins. Though MSB has pre-built API Gateway functionality – External
and Internal API Gateways – These are limited in functionality and not used well in ONAP .
• Existing plugins focus on Routing and Service Discovery – Not providing full functionality offered by typical API GW
• MSB plugins built on Lua script and requires learning curve. Additional development overhead for new plugins and API LCM
• Suggestion is to leverage a full fledged API GW open source solution with OOB capabilities and build MSB capabilities in that.
API GW and DMaaP

FUNCTIONAL CAPABILITIES IN DMAAP FUNCTIONAL CAPABILITIES AUGMENTED BY API GW

• Event Publish/Subscribe Mechanism • Asynchronous Event Notifications to API Consumers

• Manage Topics – CRUD Operation • Offer Consumer Specific Adaptation for internal Events
• Manage Subscriptions
• Offer a Web Socket or Server Sent Events
• Provide a Façade API over Kafka Message Bus Interface to Consumers for internal Events
• Client SDK for Working with DMaaP
• Pre and Post API Invocation notifications to
• Distributed Deployment ONAP internal components

• API GW does not have any conflicting capabilities with DMaaP. The two components are complimentary
• API GW can act like an external notification point by registering call back subscriptions to specific topics in DMaaP
• API GW will reuse DMaaP through a custom plugin (which use DMaaP Client SDK)
API Gateway and Service Mesh

API Gateway expose services as

managed APIs

Service Mesh decouple and

offload most of the service-to-
service communication from
business logic.

Service mesh is an inter-service communication infrastructure which doesn’t have any business notion. So it
will be ideal to be used at levels of Microservices.
Typical API GW Functional Architecture
Consumer

API Gateway
Load Balancer (Optional)
API Catalog/ API Management
Marketplace Portal

Distributed Gateway Functions (Reverse Proxies)

Gateway Function Gateway Function API Management Function

GatewayProxy)
(Reverse Function GatewayProxy)
(Reverse Function
(Reverse Proxy) (Reverse Proxy)

Plugins
Plugins Plugins
Plugins Configuration and
Analytics

Auth Provider Load Balancer External Analytcs and Monetizing Functions

Back End Services

Benefits for ONAP

Support single source of truth for Standard APIs, rather than each project maintaining own versions

Augment MSB and Ext-API capabilities:

with Request/Response Composition, Filtering, Policy Enforcement, Security, Orchestration

Facade layer: which abstracts the complexities of internal API

Request/Response Transformation:
Enables ONAP components to align with SDO APIs more easily without changing the existing capabilities

Low impact on existing projects: Enable Operators to plugin standard and legacy integration API adaptors without
impacting the ONAP components

Allows Projects/Components to focus on core functionality rather than worrying about API Transformation

Enables Tenancy Management : Centralized API management can help in implementation of tenancy management through
policies.
Section 3 Execution Plan
Proposed Plan

• April-May : Presentation to Operators in ONAP community and see if there is any need for
such functionality – Already presented to more than 6 operators in ONAP Community.
Discussion/Feedback collection in progress . So far we have got positive response from all the
operators.

• May first week : Presentation to Architecture committee – Seek feedback on problem

statement and overall approach

• May first week : Presentation to MSB, Ext-API and identify areas where we can work together –
Discussion with MSB completed , Discussion with Ext-API scheduled for Wednesday, 8th May
• MSB team thinks the proposed capability has some overlap with the features in roadmap
that can be developed with additional plugins

• May last week, June : Consolidate feedback and present to Architecture/TSC Committees for
potential development in E or F Release
Proposed Use Cases (Any one to start with)
Scenario 1: Scenario 2 :
Dynamic Routing and Request/Response Transformation Dynamic Routing and Request/Response Transformation
for SOL005 API for SOL003 API

• API GW Exposing two types of interfaces • API GW Exposing two types of interfaces
• Simplified internal API which hides SOL005 API or API exposed by • Simplified internal API which hides SOL003/Vendor complexity
external NFVO • Pure SOL003 (without VNFM specific extensions)
• Pure SOL005 which can be used for integration with OSS/BSS
• Use Case
• Use Case • Case 1) ONAP Component wants to use Simplified API for VNF
• Case 1) ONAP Component wants to access an External NFVO for instantiation
LCM operation (sub domain) • Case 2) ONAP Component supports pure SOL003 API but not aware
• Case 2) ONAP Component wants to work with a component of vendor extensions
internal/external via SOL005 API
• Operation
• Operation • Case 1: API GW takes care of transforming simplified internal API to
• Case 1: API GW takes care of transforming the simplified internal corresponding multiple API calls - SOL003 specific or Vendor
API to corresponding API calls to external NFVO APIs specific APIs
• Case 2 : API GW receives SOL005 API calls and enriches/transforms • Case 2: API GW receives pure SOL003 request and enriches the
the API with internal/external API call request with vendor specific SOL003 extended parameters
Thank You