• HTTP/S Proxy support is added to A1 Policy Management Service (specifically for A1 connection only) - Configurable via configuration files. See documentation for details.
  • HTTP/S Proxy support is not yet added to A1 Adapter, since it uses the CCSDK SLI node function to perform REST calls southbound. This function needs to be extended in CCSDK (or a new one added). This changes, and associated regression testing will be quite tricky.
  • Example: Bastion in a real world deployment) but may have serious knock on effects for other functions & regression testing using SLI graphs etc ....


Option 1: from Hieu Nguyen  using Kong as HTTPS proxy for A1 Adapter

  • Ref
  • Use URL re-writing for RIC-configuration-url → Kong gateway url, then configure Kong to redirect traffic to the appropriate RICs.
    • Need to examine if end-to-end HTTPS authentication/security is maintained.
    • Main issue is not how to insert a proxy between A1-Adapter & RAN, but the case where a proxy already exists. 
      • Might be easier to configure in Kong than in A1 adapter?
  • A1 Proxy: Hieu Nguyen - Has left Samsung, and unlikely to continue this work
    • Pawel Slowikowski Any update for using Kong?
      • John Keeney Unclear the need - instead want to handle a 3rd party proxy below the A1 adapter
    • John Keeney Kong as an approach for isolating functions in ONAP sounds useful in general though.
    • John Keeney Should come up with a picture/page describing this topics. (Action)

Option 2: Extend existing REST SLI node

  • Add optional support for proxy
    • Needs backwards compatibility so will not break existing users / tests

This option was implemented as part of Istanbul release.

Function sendHttpRequest in class RestapiCallNode was modified to include use of proxy. A new ClientConfig that has information about proxy Url was added. This url needs to be configure in variable a1Mediator.proxy.url in a1-adapter-api-dg.properties file that is part of the CCSDK/distribution project.

Option 3: Add a new type of SLI node

  • Extend existing REST node type
    • Backwards compatible so will not break existing users / tests


  • No labels