Red Hat 계정으로 회원 프로필, 기본 설정 및 고객 상태에 따라 다음의 서비스에 액세스할 수 있습니다.
아직 등록하지 않으셨습니까? 등록해야 하는 이유:
- 한 곳에서 기술 자료 문서를 탐색하고, 지원 사례와 서브스크립션을 관리하고, 업데이트를 다운로드 할 수 있습니다.
- 조직 내의 사용자를 보고, 계정 정보, 기본 설정 및 권한을 편집할 수 있습니다.
- Red Hat 자격증을 관리하고 시험 내역을 조회하며 자격증 관련 로고 및 문서를 다운로드할 수 있습니다.
Red Hat 계정으로 회원 프로필, 기본 설정 및 자신의 고객 상태에 따른 기타 서비스에 액세스할 수 있습니다.
보안을 위해, 공용 컴퓨터 사용 중에 Red Hat 서비스 이용이 끝난 경우 로그아웃하는 것을 잊지 마십시오.로그아웃
As part of digital transformation, and in anticipation of the 5G evolution, service providers have found it necessary to redesign portions of the network’s layers and components, using cloudification and containerization.
This approach enables the introduction of new technologies and operation modes to the network — such as microservices, automation, artificial intelligence/machine learning (AI/ML), horizontal, open architectures, and more. However, the delivery of new and expanded capability to customers needs to be integrated with legacy systems, and with a perspective of looking forward.
Apps that provide demonstrated value to existing and future technology investments rely on application programming interfaces (APIs), which enable a standard method for platform-wide integration, without having to rebuild it every time something new is introduced. Even with the use of API standards, implementing and managing API integrations can be challenging, even when used in open architecture deployments.
The role of open architectures — benefits and considerations
The objective of open architectures is to enable multiple vendors to coexist within one network, from the data center to the edge, enabling service providers to establish an ecosystem for APIs on top of their 5G network. This facilitates data aggregation from modern sources, such as IoT devices, connected cars, radio access networks (RAN), private networks, consumers, MEC, etc.
However, using an open architecture can lead to management and supervision complexity as each vendor may retain its own set of management tools, which can even differ between products and versions. Due to this potential for limitless combinations, the industry sees the need for an end-to-end API management solution at scale consisting of distinct components, including a gateway to handle the API data streams and a manager to authenticate, authorize, manage, monitor and even monetize the API calls and endpoints over the network, all with greater security functionality.
Prior to 5G implementation, there wasn’t an existing standard API gateway in the telco network which could be used by third-party applications or external functions, leaving the operator to process each API separately.
API management in 5G architecture
As part of 5G Service Based Architecture (SBA), 3GPP defines an HTTP-based API bus (SBI- Service Based Interface), for application functions (AF) API communications, the location where multifunction and multivendor APIs coexist. It also specifies a Network Exposure Function (NEF), serving the purpose of exposing some of the APIs back to the network.
5G SBA diagram (credit: Cisco)
The NEF’s role is to securely expose the AF’s network services and capabilities using HTTP API towards the network (application function northbound interface), to be utilized by third-party applications and developers. NEF exposes such functionalities as monitoring capability, provisioning capability, application influence, or Policy/Charging capability.
However, the NEF requirement is specified in terms of the APIs it exposes (3GPP TS 23.502 4.15.2), providing a predefined set of APIs exposed to external functions.
Over time, (TS 23.222), 3GPP specified a requirement for a common API framework (CAPIF).
CAPIF is divided into main three types of operations:
API exposure (exposing publishing and management functions)
A. CAPIF core function
The CAPIF core function consists of the following capabilities:
Authorization and authentication of the API invoker
Onboarding / offboarding of API invoker
Publishing, storing and supporting the discovery of service APIs information
Policy-based access control for service APIs
Monitoring the API service queries
Log store, log audit and log query service for service API log invocations
Charging based on the logs of the service API invocations
Inter-CAPIF core functions communications
B. API invoker
The API invoker is typically provided by an application provider, and it can reside within or outside of a trust domain.
It supports the following capabilities:
Maintain identity information for authentication
Mutual authentication with CAPIF
Obtaining the authorization prior to accessing the service API
Discovering service APIs information and invoking the service APIs
C. API exposing function
The communication point of the service API and the API invoker consists of the following capabilities associated with authentication and validation (based on identity data from the CAPIF core function) :
API publishing function — publishes the service API information of the API provider to the CAPIF core function
API management function — enables the API provider (an AF) to perform administration of the service APIs, and consists of the following capabilities:
Auditing of service API logs (from CAPIF core)
Monitoring CAPIF events and service API status
Providing API provider policies to the CAPIF core function
Onboarding / offboarding of API invoker
API provider domain information registration on CAPIF core
API Provider Domain — consists of the API management function, API exposing function, and API publishing function, and serves AF’s API within the same domain
The standard differentiates the API communications between the invokers and CAPIF components (core and API management), and internal communication between the CAPIF components, which is beyond the scope of this document.
A high-level basic architecture of CAPIF
There can be multiple co-located CAPIF core functions and API provider domains within one network trust domain.
Red Hat’s proposed solution for API management at scale while preserving the flexibility of an open architecture
Red Hat API management is based on the 3scale enterprise API management product.
It is a modular API infrastructure solution that provides authentication, governance, security, analytics, automated documentation, developer portals and monetization for API services.
Red Hat integration stack (including Red Hat 3scale)
3scale can be installed on Red Hat OpenShift as an operator, or by using a YAML template.
It can run on podman, docker, on-prem, or on public clouds (managed / non-managed service).
Red Hat provides a managed OpenShift API management service for developers (based on 3scale) for Red Hat OpenShift Service on AWS (ROSA) and OpenShift Dedicated (OSD).
As a modular solution, 3scale provides a high level of freedom to customers to decide which underlying components to use (databases, ActiveDocs, branded developer portals and more).
3scale high-level architecture (by component)
API manager — In charge of security and authentication, access control, API lifecycle management, version control, documentation, monitoring, provisioning, alerting, metering and billing, policy and developer/admin portal policies.
The API manager uses several databases in order to store and manage API requests and data:
System-mysql / system-postgres / Oracle — storage of all data managed via Admin/Dev Portal, CMS
system-redis / redis cluster — temporary storage for background jobs for API Manager
backend-redis / redis cluster — statistics storage, temporary job storage
zync-database — securely syncs (one way) 3scale with IDPs (Identity Provider system)
API gateway — basically an NGINX web server, responsible for enforcing the API policies that are defined in the API manager. It consults the API Manager on incoming calls and enforces the policies, either returning an error or proxying the API call to the customer’s API backend.
API gateways are configured using the API Manager admin portal.
Closing remarks and more information
In order to achieve a 5G ecosystem for APIs using CAPIF, adding new functionalities and revenue streams using 5G networks, API management solutions should be embedded into the 5G architecture, or at least have well-defined interfaces with the current architecture.
Currently, we don’t yet see movement in the market from using only NEF to an API-rich ecosystem using CAPIF, and this transition will require API management product vendors to partner with 5G solution vendors, including feature and performance integrations and adjustments.
As described, Red Hat provides API Management by 3scale, on top of Red Hat OpenShift or on a stand-alone basis.
Additionally, we invite 5G vendors to collaborate with Red Hat via the Red Hat Telco ecosystem.
About the author
Aviv Guetta, based in Israel, is a Chief Technologist in Red Hat’s Global Telco sector. He has extensive experience in the IT and telco industries, including strategy work, business planning, cross-functional team building and architecture efforts supporting open source development and management.