3 BSF Features

This section describes the key features of Oracle Communications Cloud Native Core, Binding Support Function (BSF).

3.1 Stale Binding Detection Audit, Report and Recover

Service disruption due to network storm, system overload, database latency, and other events can impact signaling between PCF and BSF. This service disruption can affect session binding between PCF and BSF.

BSF supports to revalidate the binding information of a PDU session and checks if there is any missing binding information in BSF due to service disruption between PCF and BSF.

When BSF receives a binding session revalidation request from PCF, BSF processes the request, determines if the session is available in BSF. Existence of the binding association for the PDU session in BSF confirms the binding association being valid in BSF. If the binding association is missing in BSF, it is restored by creating the association in BSF.

When the session binding revalidation is enabled in BSF

When BSF receives a PDU session binding revalidation request from PCF through Diameter Gateway:

• BSF checks if session binding revalidation is enabled in BSF and the revalidation request includes x-oc-binding-revalidation header.

  Note:

  Session binding revalidation can be enabled in BSF, either using Enable Binding Revalidation field in Management Service page on CNC Console or using enableBindingRevalidation parameter in BSF Management Service API. For more details, see Management Service.

• If BSF identifies that the revalidation request is a colliding or a duplicate request, and the if the following parameters in the request matches with the stored binding object in BSF:

  • SUPI/GPSI

  • UE IP(IPV4/IPV6),

  • IPDomain(if IPV4 was present for UE IP)

  • dnn

  • snssai

  • diamHost/fqdn

  • pcfFqdn

  A binding revalidation request is considered as a duplicate request if the request is for the same subscriber (SUPI, DNN, SNSSAI, IPV4/IPv6 prefix, or IpDomain) from same PCF instances (ID/pcfDiamHost/pcfFqdn or pcfIpEndPoints). If the parameters in the request matches with the stored binding object in BSF, BSF responds to PCF with the given binding_id and does not perform any database update.

• If the parameters do not match, or if it is not a duplicate request, BSF creates the binding record and responds to PCF with a 201 response to PCF including a location HTTP header field that contains the URI of the created binding information.

  Example:

  {apiRoot}/oc-bsf-configuration/v1/services/managementservice/{bindingId}

  where, {bindingId} is the new binding identifier for the session.

When the session binding revalidation is enabled in BSF

If the session binding revalidation is enabled in BSF, when BSF receives a PDU session revalidation request from PCF, BSF checks if the binding information exists in BSF. If the record created by the same PCF already exists, BSF deletes the existing record and creates a new record for the PDU session.

When BSF receives a PDU session revalidation request from PCF:

• BSF verifies if the parameters for late arrival handling is configured.

• If the request has not arrived late, BSF checks if Enable Collision Detection field is enabled.

  If the parameters in the request do not match with the stored binding information in BSF, BSF creates the binding record for the pcdId and responds to PCF with 201 response code with a new binding_id.

Call Flow

The following diagram depicts a sample call flow for revalidating the binding information for a PDU session in BSF when the binding revalidation is enabled in BSF and the revalidation request includes x-oc-binding-revalidation header:

Figure 3-1 Binding revalidation in BSF

1. BSF receives a binding revalidation request for a PDU session from PCF.

2. BSF checks if the session binding revalidation is enabled in BSF and the revalidation request includes x-oc-binding-revalidation header.

3. If the revalidation request is a duplicate or a colliding request and if the binding information for the PDU session already exists in BSF, BSF sends a 201 response code with the existing binding_id.

4. If the binding information stored in BSF differs from the details received in the request or if the binding information for the PDU session does not exist in BSF, BSF recreates the session biding record (re-registers) for the PDU session. BSF sends a 201 response code with the new binding_id.

Managing Stale Binding Detection Audit, Report and Recover

Enable

This feature can be eanbled using CNC Console for BSF as well as using REST API.

Enable using CNC Console

To enable this feature using CNC Console for BSF, configure Enable Binding Revalidation field on Management Service page under Service Configurations in CNC Console for BSF.

For more information, see Management Service.

Enable using REST API

To enable this feature using REST API, configure the EnableBindingrevalidate parameter under Management Service API for BSF: {apiRoot}/oc-bsf-configuration/v1/services/managementservice.

For more information, see Management Service section in Oracle Communications Cloud Native Core, Binding Support Function REST Specification Guide.

Observability

Metrics

The following BSF Management service metrics are used to monitor this feature in BSF:

• ocbsf_binding_revalidation_request_total
• ocbsf_binding_revalidation_response_total
• ocbsf_binding_revalidation_pcfBinding_missing_total

For more information, see BSF Management Service.

Alerts

The following BSF alerts are used for this feature:

• BINDING_REVALIDATION_PCF_BINDING_MISSING_MINOR
• BINDING_REVALIDATION_PCF_BINDING_MISSING_MAJOR
• BINDING_REVALIDATION_PCF_BINDING_MISSING_CRITICAL

For more information, see List of Alerts.

Logging

The following logs with a specific marker "marker":{"name":"BINDING"}, "Binding Audit:<additional log text>" are generated for this feature:

• For Revalidation request, if the binding association is not present in BSF, BSF updates its logs with the failure for the revalidation request. The updated logs include:
  • SUPI
  • DNN
  • S-NSSAI
  • UE-IP (IPv6/IPV4)
  • IPDomain if available
  • PCF FQDN
  • error code and cause at “WARN” level
• For Revalidation request, if BSF can not reestablish or restore the BSF binding after all session retries, BSF updates its logs with the failure for the restoration request.
  • SUPI
  • DNN
  • S-NSSAI
  • UE-IP (IPv6/IPV4)
  • IPDomain if available
  • PCF FQDN
  • error code and cause at “WARN” level

3.2 Traffic Segregation

This feature provides end-to-end traffic segregation to BSF based on traffic types. Within a Kubernetes cluster, traffic segregation can divide applications or workloads into distinct sections such as OAM, SBI, Kubernetes control traffic, etc. The Multus CNI container network interface (CNI) plugin for Kubernetes enables attaching multiple network interfaces to pods to help segregate traffic from each BSF microservice.

This feature addresses the challenge of logically separating IP traffic of different profiles, which are typically handled through a single network (Kubernetes overlay). The new functionality ensures that critical networks are not cross-connected or sharing the same routes, thereby preventing network congestion.

With traffic segregation, operators can segregate traffic to external feeds and applications more effectively. Previously, all external traffic was routed through the same external network, but now, egress traffic from the BSF pods can be directed through non-default networks to third-party applications. This separation is achieved by leveraging cloud-native infrastructure and the load balancing algorithms in CNE.

The feature supports the configuration of separate networks, Network Attachment Definitions (NADs), and the Cloud Native Load Balancer (CNLB). These configurations are crucial for enabling cloud native load balancing, facilitating ingress-egress traffic separation, and optimizing load distribution within BSF.

Prerequisites

The CNLB feature is only available in BSF if CNE is installed with CNLB and Multus.

Cloud Native Load Balancer (CNLB)

CNE provides Cloud Native Load Balancer (CNLB) for managing the ingress and egress network as an alternate to the existing LBVM, lb-controller, and egress-controller solutions. You can enable or disable this feature only during a fresh CNE installation. When this feature is enabled, CNE automatically uses CNLB to control ingress traffic. To manage the egress traffic, you must preconfigure the egress network details in the cnlb.ini file before installing CNE.

Note:

CNLB is supported only for IPv4 stack.

For more information about enabling and configuring CNLB, see Oracle Communications Cloud Native Core, Cloud Native Environment User Guide, and Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.

Network Attachment Definitions for CNLB

A Network Attachment Definition (NAD) is a resource used to set up a network attachment, in this case, a secondary network interface to a pod. BSF supports two types of CNLB NADs:

1. Ingress Network Attachment Definitions

   Ingress NADs are used to handle inbound traffic only. This traffic enters the CNLB application through an external interface service IP address and is routed internally using interfaces within CNLB networks.

   • Naming Convention:nf-<service_network_name>-int
2. Egress Only Network Attachment Definitions

   Egress Only NADs enable outbound traffic only. An NF pod can initiate traffic and route it through a CNLB application, translating the source IP address to an external egress IP address. An egress NAD contains network information to create interfaces for NF pods and routes to external subnets.

   • Requirements: Destination (egress) subnet addresses are known beforehand and defined under the cnlb.ini file's egress_dest variable to generate NADs.
   • Naming Convention:nf-<service_network_name>-egr
3. Ingress/Egress Network Attachment Definitions

   Ingress/Egress Network Attachment Definitions enable inbound/outbound traffic. An NF pod can initiate traffic and route it through a CNLB app, translating source IP address to an external egress IP address (defined under cnlb.ini file egress_addr variable). An Ingress/Egress Network Attachment Definition contains network information to create interfaces for NF pods and routes to external subnets. Even though an Ingress/Egress Network Attachment Definition enables outbound traffic, it also handles inbound traffic, so if inbound/outbound traffic is needed an Ingress/Egress Network Attachment Definition should be used.

   • Requirements: Source (ingress) and destination (egress) subnet addresses are known beforehand and defined under cnlb.ini file egress_dest variable to generate Network Attachment Definitions.
   • Naming Convention:nf-<service_network_name>-ie

Managing Ingress and Egress Traffic Segregation

Enable:

This feature is disabled by default. To enable this feature, you must configure the network attachment annotations in the custom values file.

Configuration

For more information about Traffic Segregation configuration, see " Configuring Traffic Segregation" section in Oracle Communications Cloud Native Core, Converged Binding Support Function Installation, Upgrade, and Fault Recovery Guide..

Observe

There are no Metrics, KPIs, or Alerts available for this feature.

Maintain

To resolve any alerts at the system or application level, see BSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Binding Support Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.3 Logging Support for Error Response

Error handling framework was introduced in earlier release of BSF as a general purpose error handling tool. This feature used the error handling framework to add more details to the error using 3GPP error response format.

BSF sends error responses to consumer NFs due to some exceptions, such as signaling, validations, and internal errors. These error responses have payloads containing the problem title, status, details, and cause of the error that are used to investigate the error. BSF has been enhanced to support logs for the error responses.

When sending any error response triggered by an HTTP Request, this error response format will be mapped into the following general log format:

{
  “errorStatus”: “Value”, (ProblemDetails status field)
  “errorTitle”: “Value”, (ProblemDetails title field)
  “errorDetails”: “Value”, (ProblemDetails detail field)
  “errorCause”: “Value”  (ProblemDetails cause field)
  “sender”: “Value”, (nfType-nfInstanceId)
  “subscriberId”: “Value” (UE ID associated with event if present)
}

Table 3-1 General Log Format

Parameter	Description	Example
errorStatus	Specifies the status code of the error.	404, 500, etc.
errorTitle	Specifies the title of the error.	Required parameter in binding data is missing
errorDetails	Specifies the error detail produced by error handling framework in case of BSF as producer. Note: For errorDetails field to be populated in the required format, error handling framework should be enabled in CNC Console for the required service.	ocbsf1-2-api-gateway.bsf1-2.svc.atlantic.morrisville.us.lab.oracle.com:BSF_MGMT:Mandatory parameter is missing in request :EC-OBSF-BSF_MGMT-REQVLD-EI-05-02-400-00010-01-02
errorCause	Specifies the cause of the error.	MANDATORY_IE_MISSING
sender	Specifies the sender which is composed by the nfType plus the instanceId. Note: In case of BSF as producer of error, the sender field will be BSF plus the instanceId of the BSF.	BSF-fe7d992b-0541-4c7d-ab84-c6d70b1b0666
subscriberId	Specifies the subscriberId which can be SUPI or GPSI associated with the event.	imsi-65008100001061

In the case of subscriberID, if UE identifier is present and shows UE identifier flag as enabled, the logging happens in the following hierarchy:

1. If SUPI and GPSI both are present, use SUPI.
2. If SUPI is not present, and GPSI is present, use GPSI.

Note:

Sender-contains the nfType-instanceIdfrom the sender of the HTTP Request. Where nfType is a value which contains the type of Network Function set as BSF by default, and nfInstanceIdis a unique identifier for a specific instance of a Network Function. This value is set in the application configuration for BSF

Managing Enhancements to Logging Support for Error Response

This section explains the procedure to enable and configure the feature.

Enable

By default, this feature is disabled. The operator can enable this feature through the CNC Console configurations.

Note:

Oracle does not recommend enabling this feature. When this feature is enabled, sensitive information in the form of UE identifier gets published. Users can secure the logs in their environment using appropriate configuration.

Configure

You can configure logging support for error response using the Enable Enhanced Logging and Enable UE Identifier Information toggle buttons. These toggle buttons are availabe in General Settings under General Configurations on CNC Console for BSF. For information about how to configure for BSF Management Service in CNC Console, see General Settings.

Observe

There are no new metrics in BSF Management Service for this feature.

3.4 Support for TLS

BSF uses Hypertext Transfer Protocol Secure (HTTPS) and Diameter Gateway to establish secured connections with consumer NFs and producer NFs, respectively. These communication protocols are encrypted using Transport Layer Security (TLS).

TLS comprises the following components:

• Handshake Protocol: Exchanges the security parameters of a connection.
• Record Protocol: Receives the messages to be transmitted, fragments the data into multiple blocks, secures the records, and then transmits the result. Received data is delivered to higher-level peers.

This feature enables the support for TLS 1.3 to all consumer NFs, producer NFs, the Data Director, SBI Interfaces, and any interfaces previously supporting TLS 1.2. Support for TLS 1.2 will remain available.

Note:

If both TLS 1.2 and TLS 1.3 are supported, TLS 1.3 is given priority.

TLS 1.2 and TLS 1.3 Handshake

This section describes the differences between TLS 1.3 and TLS 1.2, as well as the advantages of TLS 1.3 over TLS 1.2 and earlier versions.

Figure 3-2 TLS 1.2 and TLS 1.3 Handshake

TLS 1.2

Step 1: The connection or handshake starts when the client sends a "client hello" message to the server. This message consists of cryptographic information such as supported protocols and cipher suites. It also contains a random value or random byte string.

Step 2: To respond to the "client hello" message, the server sends a 'server hello' message. This message contains the CipherSuite that the server has selected from the options provided by the client. The server also sends its certificate, along with the session ID and another random value.

Step 3: The client verifies the certificate sent by the server. When the verification is complete, it sends a byte string encrypted using the public key of the server's certificate.

Step 4: When the server receives the secret, both the client and server generate a master key along with session keys (ephemeral keys). These session keys are used for symmetrically encrypting the data.

Step 5: The client sends an "HTTP Request" message to the server to enable the server to transition to symmetric encryption using the session keys.

Step 6: To respond to the client’s "HTTP Request" message, the server does the same and switches its security state to symmetric encryption. The server concludes the handshake by sending an HTTP response.

Step 7: The client-server handshake is completed in two round trips.

TLS 1.3

Step 1: The connection or handshake begins when the client sends a "client hello" message to the server, which includes the list of supported cipher suites and the client's key share for the specific key agreement protocol.

Step 2: To respond to the "client hello" message, the server sends the key agreement protocol that it has chosen. The "Server Hello" message includes the server key share, server certificate, and the "Server Finished" message.

Step 3: The client verifies the server certificate, generates keys since it has the server's key share, and then sends the "Client Finished" message along with an HTTP request.

Step 4: The server completes the handshake by sending an HTTP response.

Note:

ASM and TLS are not supported together.

The following table provides comparison of TLS 1.2 with TLS 1.3:

Table 3-2 Comparison of TLS 1.2 with TLS 1.3

Feature	TLS 1.2	TLS 1.3
TLS Handshake	This is less efficient as it requires more round-trips to complete the handshake process.	This is more efficient as it requires less round-trips to complete the handshake process.
Cipher Suites	This has less secured Cipher Suites.	This has more secured Cipher Suites. They support the following ciphers: TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_AES_128_CCM_8_SHA256: This Cipher is not supported by Java library. TLS_AES_128_CCM_SHA256: This Cipher is not supported by Java library.
Round-Trip Time (RTT)	This has higher RTT during TLS handshake.	This has low RTT.
Performance	This has higher latency during TLS handshake.	This has low latency during TLS handshake.

Note:

• BSF does not prioritize cipher suites on the basis of priorities. To select cipher on the basis of priorities, you must write the cipher suites in the decreasing order of priority.
• BSF does not prioritize supported groups on the basis of priorities. To select supported group on the basis of priorities, you must write the supported group values in the decreasing order of priority.
• If you want to provide values for the signature_algorithms extension using the clientSignatureSchemes parameter, the following comma-separated values must be provided to deploy the pods:

  • rsa_pkcs1_sha512
  • rsa_pkcs1_sha384
  • rsa_pkcs1_sha256
• The mandatory extensions as listed in RFC 8446 cannot be disabled on the client or server side. The following is the list of the extensions that cannot be disabled:
  • supported_versions
  • key_share
  • supported_groups
  • signature_algorithms
  • pre_shared_key

The following digital signature algorithms of TLS 1.2 and TLS 1.3 are supported in TLS handshake:

Table 3-3 Digital Signature Algorithms

Algorithm	Key Size (Bits)	Elliptic Curve (EC)
RS256 (RSA)	2048	NA
	4096 This is the recommended value.	NA
ES256 (ECDSA)	NA	SECP384r1 This is the recommended value.

Note:

The following functionalities from TLS 1.3 specifications are not supported:

• Zero round-trip time (0-RTT) mode.
• Pre-Shared Key (PSK) exchange.

3.4.1 Support for TLS Using HTTPs

BSF uses Hypertext Transfer Protocol Secure (HTTPS) to establish secured connections with consumer NFs and producer NFs, respectively. These communication protocols are encrypted using Transport Layer Security (TLS).

Enable

This feature is enabled by default at the time of Gateway Services deployment by completing the required Helm configurations.

Configure

You can configure this feature using Helm. For information about Helm configurations, see "Global Parameters" in Oracle Communications Cloud Native Core, Binding Support Function Installation, Upgrade, and Fault Recovery Guide.

Observe

The following metrics are available for this feature:

• oc_ingressgateway_incoming_tls_connections
• oc_egressgateway_outgoing_tls_connections
• security_cert_x509_expiration_seconds

For more information about metrics, see TLS Metrics section.

The following alerts are available for this feature:

• CERTIFICATE_EXPIRY
• BSF_CONNECTION_FAILURE

For more information about alerts, see Configuring BSF Alerts section.

Maintain

If you encounter alerts at system or application levels, see Configuring BSF Alerts section for resolution steps.

In case the alert still persists, perform the following:

1. Collect the logs and Troubleshooting Scenarios: For more information on how to collect logs and troubleshooting information, see Oracle Communications Cloud Native Core, Binding Support Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.4.2 Support for TLS in Diameter Gateway

BSF uses Diameter Gateway to establish secured connections with consumer NFs and producer NFs, respectively. These communication protocols are encrypted using Transport Layer Security (TLS).

Enable

This feature is disabled by default. It can be enabled using TLS_ENABLED parameter using Helm configurations. For information about Helm configurations, see "Global Parameters" in Oracle Communications Cloud Native Core, Binding Support Function Installation, Upgrade, and Fault Recovery Guide.

Configure

You can configure this feature using Helm. For information about Helm configurations, see "Global Parameters" in Oracle Communications Cloud Native Core, Binding Support Function Installation, Upgrade, and Fault Recovery Guide.

Peer level support for TLS versions can be configured using CNC Console. For more information, see Peer Nodes section.

Observe

The following metrics are available for this feature:

• diam_conn_network
• diam_failed_conn_network
• diam_conn_network_responder
• dgw_tls_cert_expiration_seconds

For more information about metrics, see TLS Metrics section.

The following alerts are available for this feature:

• DGW_TLS_CONNECTION_FAILURE
• DIAM_GATEWAY_CERTIFICATE_EXPIRY_MINOR
• DIAM_GATEWAY_CERTIFICATE_EXPIRY_MAJOR
• DIAM_GATEWAY_CERTIFICATE_EXPIRY_CRITICAL

For more information about alerts, see Configuring BSF Alerts section.

Following extensions are available for TLS in Diameter Gateway:

• status_request (0x0005)
• status_request_v2 (0x0011)
• supported_groups (0x000A)
• ec_point_formats (0x000B)
• extended_master_secret (0x0017)
• session_ticket (0x0023)
• signature_algorithms (0x000D)
• signature_algorithms_cert (0x0032)
• supported_versions (0x002B)
• psk_key_exchange_modes (0x002D)
• key_share (0x0033)
• renegotiation_info (0xFF01)

Maintain

If you encounter alerts at system or application levels, see Configuring BSF Alerts section for resolution steps.

In case the alert still persists, perform the following:

1. Collect the logs and Troubleshooting Scenarios: For more information on how to collect logs and troubleshooting information, see Oracle Communications Cloud Native Core, Binding Support Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.5 Enhancements to Error Response

BSF sends error responses to consumer NFs due to some exceptions, such as signaling, validations, and internal errors. These error responses have payloads containing the problem title, status, details, and cause of the error that are used to investigate the error. The details section is now enhanced with application error IDs.

The error handling module gives provision to configure the error response dynamically and the same is responded when BSF is producer of the call flow.

With the enhanced error response mechanism, BSF sends additional information such as server FQDN, micro-service ID, error category, and application error ID in the detail attribute of the ProblemDetails. This enhancement provides more information about the error and troubleshoot them.

Application error ID follows the below format.

[ EC] [NF ID] [Microservice ID] [Category] [Error ID]

An error code dictionary will be provided to identify the cause and possible solution of the error. For more details of the error code dictionaries for BSF management service, Egress Gateway, Ingress Gateway, and NRF Client, see Error Code Dictionary .

Managing Enhancements to Error Response

This section explains the procedure to enable and configure the feature.

Enable

By default, this feature is disabled. The operator can enable this feature through the CNC Console configurations.

Configure

You can configure error handling functionality under Error Handling on CNC Console for BSF. For information about how to configure for BSF Management Service in CNC Console, see Error Configurations .

Observe

The following metrics have been added in BSF Management Service for this feature:

• error_handler_exec_total
• error_handler_in_total
• error_handler_out_total

For more information, see BSF Management Service.

3.6 Validating Destination-Realm Attribute-Value Pair (AVP) Received in AAR-I Message

The destination-realm Attribute-Value Pair (AVP) received in the AAR-I message from an AF must be validated at the BSF Diameter Gateway before processing and forwarding the AAR-I message to a corresponding PCF instance.

Note:

This validation applies exclusively to the AAR-I message within the BSF. For subsequent AAR-U and STR messages, it is assumed that the AF will send the correct Destination-Host and the destination-realm Attribute-Value Pair (AVP) values based on the AAA response received.

Figure 3-3 Diameter Gateway for BSF

Figure 3-4 destination-realm Validation Process

1. When Diameter Gateway receives an AAR-I message from an AF, it checks if the validation realm flag is enabled.

2. If the validation realm flag is enabled, it validates the destination-realm AVP received in the AAR-I message against the BSF Diameter Gateway realm.

   If the validation is successful, it proceeds with the message processing and the Diameter Gateway sends a Binding Discovery message to BSF Management Service.

   If the validation fails, the Diameter Gateway rejects the AAR-I message with error code 3003 (REALM_NOT_SERVED).

   Note:

   The Diameter Gateway error code configuration for BSF is applicable and the default result code 3003 can be modified to any other error codes.

3. If the validation realm flag is disabled, the Diameter Gateway sends a Binding Discovery message to BSF Management Service without validating the destination-realm AVP.

4. After receiving a successful response to Binding Discovery request from BSF Management service, the Diameter Gateway checks if the validate binding realm flag is enabled.

   If the validate binding realm flag is enabled, the Diameter Gateway validates the destination-realm against the pcfBinding realm.

   If the validation is successful, the Diameter Gateway forwards the message for further processing.

   If the validation fails, the Diameter Gateway rejects the AAR-I message with error code 3003 (REALM_NOT_SERVED).

   If the validate binding flag is disabled, the Diameter Gateway forwards the message for further processing without validating the destination-realm against the pcfBinding info.

5. If the Binding Discovery request fails, the Diamter Gateway rejects the AAR-I message with error code 5012 (UNABLE_TO_COMPLY).
6. After the successful validation of the destination-realm against pcfBinding info, the Diameter Gateway checks if overwrite diam-realm flag is enabled. If this flag is enabled, it overwrites the destination-realm received in the AAR-I message with the pcfBinding info received in the binding discovery response.

   Note:

   If Overwrite Realm configuration is enabled, the diam_response_network metric for AAA message will show the new realm that was overwritten as the 'reqDestRealm', and not the original realm that was sent in the AAR message.

7. If overwrite diam-realm flag is disabled, there is no modification made to the destination-realm.
8. The message is forwarded to PCF.

Note:

Fake AVP validation will not be performed if routing table is configured. That is, if the above mentioned fake AVP parameters are configured and the routing tables are also configured, AVP validation will not be performed. The call will be processed as per the routing table configuration.

Managing Validation of destination-realm in AAR-I Message

The following Advanced Settings for Diameter Gateway are used to enable and validate the destination-realm in AAR-I message:

• DIAMETER.Enable.Validate.Realm
• DIAMETER.BSF.Enable.Validate.Binding.Realm
• DIAMETER.BSF.Enable.Overwrite.Realm

For more details on the above mentioned advanced settings keys, see Settings.

Observability

Metrics

ocbsf_diam_realm_validation_failed_total metric is used to count the number of failed destination-realm validation at Diameter Gateway for BSF. For more details, see Diameter Gateway Metrics.

Alerts

The following alerts are used for Validating destination-realm Received in AAR-I Message feature:

• DIAM_RESPONSE_REALM_VALIDATION_ERROR_MINOR
• DIAM_RESPONSE_REALM_VALIDATION_ERROR_MAJOR
• DIAM_RESPONSE_REALM_VALIDATION_ERROR_CRITICAL

3.7 Support for Automated Certificate Lifecycle Management

Public Key Interface (PKI) is the set of elements such as public/private keys, certificate signing request, and certificates that are required to handle secure communications and transactions. BSF uses secure protocols for its communications, such as HTTPS and Secure Socket Layer (SSL) / Transport Layer Security (TLS) technologies to handle these secure communications. This is achieved with the use of Public and Private Keys, and the presence of trusted authorities, also known as Certificate Authorities (CA), which create and issue certificates. These certificates have a determined validity period. These certificates must be renewed before expiry. They can also be revoked when the CA or its keys are compromised. These certificates must be recreated when required.

This feature enables BSF to support automation of certificate lifecycle management in integration with Oracle Communications Cloud Native Core, Certificate Manager (OCCM).

OCCM provides the option to automatically create, renew, and delete certificates for a given CA, with the possibility to track previously created certificates and renew/delete them when required.

The certificate lifecycle management includes:

• Certificate Creation,
• Certificate Deletion,
• Certificate Monitoring (including the ones that were created using a different tool from OCCM),
• Certificate Renewal.

Note:

OCCM does not support OAuth token generation and distribution (currently handled by NRF) used for SBI signalling.

Figure 3-5 BSF Integration with OCCM

There is no direct communication between OCCM and BSF. All the communications are handled using Kubernetes Secrets.

All the required certificates are configured using OCCM.

After OCCM creates these Kubernetes Secrets, or monitors the already existing ones, the Ingress and Egress Gateways monitor these Secrets and keep track of their current status:

• VALID: A Kubernetes Secret which holds a certificate that has not expired and it is properly signed
• EXPIRED: A Kubernetes Secret which holds a certificate that has met its expiration date (the value determined in its notAfter value)
• MISSING: A Kubernetes Secret which has its certificate missing, or any other essential file for the TLS/SSL bundle
• CORRUPT: A Kubernetes Secret which has its certificate corrupt, either invalid file, invalid signature, or invalid format

Managing the keys and certificates

Install Guide Considerations

• Upgrade: When BSF is deployed with OCCM, follow the specific upgrade sequence as mentioned in the Oracle Communications, Cloud Native Core Solution Upgrade Guide.
• Rollback: You can remove Kubernetes secrets if the current version of BSF does not use that secret by checking the ocbsf_custom_values.yaml file. Before deleting, please make sure that there is no plan to rollback to the BSF version which uses these secrets. Otherwise Rollback will fail. For more information on migrating the secrets from BSF to OCCM and removal of Kubernetes secrets from the yaml file, see Upgrade Strategy in Oracle Communications Cloud Native Core, Binding Support Function Installation, Upgrade, and Fault Recovery Guide.

Configure

To configure HTTPS in ingress-gateway, the following parameters must be configured in custom-value.yaml file in the ingress-gateway section:

• ingress-gateway.enableIncomingHttps
• ingress-gateway.service.ssl.privateKey.k8SecretName
• ingress-gateway.service.ssl.privateKey.k8NameSpace
• ingress-gateway.service.ssl.privateKey.rsa.fileName
• ingress-gateway.service.ssl.certificate.k8SecretName
• ingress-gateway.service.ssl.certificate.k8NameSpace
• ingress-gateway.service.ssl.certificate.rsa.fileName
• ingress-gateway.service.ssl.caBundle.k8SecretName
• ingress-gateway.service.ssl.caBundle.k8NameSpace
• ingress-gateway.service.ssl.caBundle.fileName
• ingress-gateway.service.ssl.keyStorePassword.k8SecretName
• ingress-gateway.service.ssl.keyStorePassword.k8NameSpace
• ingress-gateway.service.ssl.keyStorePassword.fileName
• ingress-gateway.service.ssl.trustStorePassword.k8SecretName
• ingress-gateway.service.ssl.trustStorePassword.k8NameSpace
• ingress-gateway.service.ssl.trustStorePassword.fileName

For more information, see Basic Configurations in Ingress Gateway section in Oracle Communications Cloud Native Core, Binding Support Function Installation, Upgrade, and Fault Recovery Guide.

To configure HTTPS in egress-gateway, configure the following parameters under egress-gateway section in custom-value.yaml file:

• egress-gateway.enableOutgoingHttps
• egress-gateway.egressGwCertReloadEnabled
• egress-gateway.egressGwCertReloadPath
• egress-gateway.service.ssl.privateKey.k8SecretName
• egress-gateway.service.ssl.privateKey.k8NameSpace
• egress-gateway.service.ssl.privateKey.rsa.fileName
• egress-gateway.service.ssl.privateKey.ecdsa.fileName
• egress-gateway.service.ssl.certificate.k8SecretName
• egress-gateway.service.ssl.certificate.k8NameSpace
• egress-gateway.service.ssl.certificate.rsa.fileName
• egress-gateway.service.ssl.certificate.ecdsa.fileName
• egress-gateway.service.ssl.caBundle.k8SecretName
• egress-gateway.service.ssl.caBundle.k8NameSpace
• egress-gateway.service.ssl.caBundle.fileName
• egress-gateway.service.ssl.keyStorePassword.k8SecretName
• egress-gateway.service.ssl.keyStorePassword.k8NameSpace
• egress-gateway.service.ssl.keyStorePassword.fileName
• egress-gateway.service.ssl.trustStorePassword.k8SecretName
• egress-gateway.service.ssl.trustStorePassword.k8NameSpace
• egress-gateway.service.ssl.trustStorePassword.fileName

For more information, see Basic Configurations in Egress Gateway section in Oracle Communications Cloud Native Core, Binding Support Function Installation, Upgrade, and Fault Recovery Guide.

Observability

Monitoring the keys and certificates

BSF supports monitoring and automatic renewal of its' TLS certificates in integration with OCCM.

It is validated that the renewed certificate and key are picked up for any new TLS connections.

Also, the existing TLS connections using the previous key and certificate are gracefully brought down.

Clean up of the certificates are also handled through OCCM.

For information about enabling HTTPS, see Configuring Secrets for Enabling HTTPS in Oracle Communications Cloud Native Core, Binding Support Function Installation, Upgrade, and Fault Recovery Guide.

.

Metrics

The oc_certificatemanagement_tls_certificate_info metric is used to support automated certificate lifecycle management.

For more information, see Metrics for Automated Certificate Lifecycle Management.

3.8 Support for cnDBTier Functionalities in CNC Console

With the implementation of this feature, cnDBTier functionalities are integrated into the CNC Console, and BSF users can view specific cnDBTier functions, such as checking the cnDBTier version, status of cnDBTier clusters, and georeplication status on the CNC Console.

Note:

This cnDBTier options can be accessed only through CNC Console.

The following cnDBTier functionalities are read only and can be viewed on the CNC Console:

• Backup List: This API displays the details of stored backups, such as the ID and size of the backup.
• Database Statistics Report: This API displays the number of available database.
• Georeplication Status:
  • Real Time Overall Replication Status: This API displays the overall replication status in multisite deployments. For example, in a four-site deployment, it provides the replication status between the following sites: site1-site2, site1-site3, site1-site4, site2-site3, site2-site4, and site2-site1. This is applicable for all other sites.
  • Site Specific Real Time Replication Status: This API displays the site-specific replication status.
• HeartBeat Status: This API displays the connectivity status between the local site and the remote site to which BSF is connected.
• Georeplication Recovery: This API provides the recovery status of georeplication for the cnDBTier cluster:
  • Update Cluster As Failed: This API is used to mark a disrupted cluster as failed.
  • Start Georeplication Recovery: This API is used to start the georeplication recovery process.
  • Georeplication Recovery Status: This API is used to monitor the recovery status of georeplication for both FAILED and ACTIVE cnDBTier sites.
• Local Cluster Status: This API displays the status of the local cluster.
• On-Demand Backup: This API provides options to initiate as well as the display the status of the on-demand backup. It also displays the status of initiated on-demand backups.
• cnDBTier version: This API displays the cnDBTier version.

Managing cnDBTier Functionalities at CNC Console

Enable

This feature is enabled automatically when cnDBTier is configured as an instance during the CNC Console deployment. For more information about integrating cnDBTier functionalities with CNC Console, see Oracle Communications Cloud Native Core, cnDBTier User Guide.

Configure

You can view cnDBTier functionalities at CNC Console in the Support for cnDBTier Functionalities in CNC Console section.

Maintain

If you encounter alerts at the system level, see the BSF Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Binding Support Function Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.9 Diameter Session Retry

BSF Diameter gateway sends the Authorization-Authentication Request (AAR) messages to PCF Diameter gateway. PCF Diameter gateway acknowledges these requests by sending a successful or failed Authorization-Authentication Answer (AAA) messages to BSF.

If BSF Diameter gateway recevies Authorization-Authentication Answer (AAA) message with errors like 5065 (IP-CAN_SESSION_NOT_AVAILABLE), 5012 (DIAMETER_UNABLE_TO_COMPLY) or any other error code or a session timeout then the CNC console has configurations that can be used to resend this failed message to a different/alternate PCF Diameter gateway.

The BSF Diameter gateway on receving the failed message from Diameter Routing Agent (DRA) captures the failed error context and the error details. The error details are sent to the error handling framework implemented in diameter gateway. The error handling framework provides specific action (such as to try resending the message to an alternate route or peer) that needs to be carried out by the gateway to handle the error that has occurred. The error actions are configured in the CNC Console as Diameter gateway configurations from the user.

Diameter message retries for Rx AAR messages are enabled through the Error Mapping Framework feature in BSF. This framework resolves application errors and takes necessary action based on the error context. The error handler framework tries to find alternate solutions based on the configurations in the CNC Console. If the error is resolved, it sends back the success result to the caller, else it either retries based on the maximum number of resolution attempts configured in CNC Console or terminates the requests by forwarding the last known error.

The operator should have configured a host and realm in the diameter routing table to retry sending the failed diameter messages. Diameter gateway finds the alternate peer from the routing table. If the diameter routing table is not configured, then there is no retry behavior from Policy.

By default, the diameter message retry behavior is disabled for Rx interface. The operator can enable this feature through the CNC Console configurations.

Note:

Default number of retry attempts is 0, that is, there is no retry. The retry attempts ranges from 0-10.

BSF retries resending Rx AAR diameter messages for the following configurable error code series:

• 3xxx (Protocol Errors)
• 4xxx (Transient Failures)
• 5xxx (Permanent Failure)

For more information about these error codes, refer to Diameter Error Codes in Oracle Communications Cloud Native Core, Binding Support Function User Guide.

Retry Attempts

The user configures the number of retries to be performed for Rx AAR diameter messages in the CNC Console. The retry attempt happens only when the alternate peers are available. If alternate peers are not available, then there is no retry attempt made. The value for number of retries ranges from 1 to 10 times.

The number of retries is set through the advance settings configurations, using the advance setting key DIAMETER.ErrorHandler.MaxRetryCount.Rx.AAR.

Peer Cycle Back Retry

In case of the configured number of retry count is more than the total available alternate peers, the user can configure to cycle back the alternate peers. User configures this in CNC Console by setting retry peer cycle back field to true. This field value is either true or false.

This peer cycle back retry configuration is set through the advance settings configurations using the advance setting keys DIAMETER.ErrorHandler.CycleBackRetry.Rx.AAR. If advance settings configuration are not supported in the CNC Console, then the default peer cycle back retry is false.

For Example: Number of configured retry = 2 and only 2 PCF (PCF1, PCF2) Diameter gateway are configured as alternate peers in BSF.

If Rx AAR message was sent BSF - PCF1 Diameter gateway and the response has failed error code such as 5065/timeout/3002/3004.

Then the first retry uses BSF - PCF2-Diam-Gateway and the response has failed error code such as timeout/3002/3004.

Then the second retry uses BSF - PCF1-Diam-Gateway and thus uses the peer cycle back retry mechanism.

Error Originator Peer

The Error Originator Peer indicates as to where the Rx AAR failed message error occured/originated when sending or retry sending the Diamter messages. The user can customize the error origination peer by using Error Response Originator filed in the CNC Console and the customizing options are based on:

• The error received from an intermediate peer (INTERMEDIATE PEER).
• The error received from the destination peer, which is not an intermediate peer (DESTINATION PEER).
• The error received from any peer (ANY).

By default the error originator peer option is any peer.

In response timeout cases the error originator option is not available since the origination of error cannot be found.

Call Flows in Diamter Session Retry

Call Flow of Rx AAR Existing Success or Failed Case - When Binding is Found

The call flow describes the scenario where BSF Diameter Gateway sends AAR request toward PCF1 Diameter Gateway on receiving the binding response from BSF Management service. On receiving the AAR request the PCF1 Diameter Gateway may send a successful or a failed AAA response toward BSF Diameter Gateway. The failed response is not handled by the BSF Diameter Gateway.

Figure 3-6 Rx AAR Existing Success/Failed Case - When Binding is Found

1. Application Function (AF) sends AAR request to BSF Diameter Gateway.
2. BSF Diameter Gateway sends binding request to BSF Management Service.
3. BSF Management service sends back binding response.
4. BSF Diameter Gateway sends AAR request to PCF1 Diameter Gateway.
5. PCF1 Diameter Gateway may send either a successful or failed AAA response and BSF Diameter Gateway do not handle the failed response.

Call Flow of Rx AAR No Retry Case - When Binding is Not Found

The call flow describes the scenario where BSF Diameter Gateway do not receive the binding response from BSF Management service.

Figure 3-7 Rx AAR No Retry Case - When Binding is Not Found

1. Application Function (AF) sends AAR request to BSF Diameter Gateway.
2. BSF Diameter Gateway sends binding request to BSF Management Service.
3. BSF Management service sends "Binding not found" response.
4. BSF Diameter Gateway responds to AF with error code 5065 (IP-CAN_SESSION_NOT_AVAILABLE).

Call Flow of Rx AAR Retry Case - When Binding is Found

The call flow describes the scenario where BSF Diameter Gateway sends AAR request toward PCF1 Diameter Gateway on receiving the binding response from BSF Management service. On receiving the AAR request, the PCF1 Diameter Gateway may send a successful or a failed AAA response toward BSF Diameter Gateway. The failed response is handled by the BSF Diameter Gateway.

Figure 3-8 Rx AAR Retry Case - When Binding is Found

1. Application Function (AF) sends AAR request to BSF Diameter Gateway.
2. BSF Diameter Gateway sends binding request to BSF Management Service.
3. BSF Management service sends back binding response.
4. BSF Diameter Gateway sends AAR request to PCF1 Diameter Gateway.
5. PCF1 Diameter Gateway sends a failed AAA response to BSF Diameter Gateway.
6. BSF Diameter Gateway resends the failed AAA message to PCF2 Diameter Gateway.
7. PCF2 Diameter Gateway sends a successful AAA response to BSF Diameter Gateway.
8. BSF Diameter Gateway sends this AAA message to AF.

Call Flow of Rx AAR Retry Case - When Binding is Not Found

The call flow describes the scenario where BSF Diameter Gateway sends AAR request toward PCF1 Diameter Gateway on not receiving the binding response from BSF Management service. On receiving the AAR request the PCF1 Diameter Gateway may send a successful or a failed AAA response toward BSF Diameter Gateway. The failed response is handled by the BSF Diameter Gateway.

Figure 3-9 Rx AAR Retry Case - When Binding is Not Found

1. Application Function (AF) sends AAR request to BSF Diameter Gateway.
2. BSF Diameter Gateway sends AAR request to PCF1 Diameter Gateway.
3. PCF1 Diameter Gateway sends a failed AAA response to BSF Diameter Gateway.
4. BSF Diameter Gateway resends the failed AAA message to PCF2 Diameter Gateway.
5. PCF2 Diameter Gateway sends a successful AAA response to BSF Diameter Gateway.
6. BSF Diameter Gateway sends this AAA message to AF.

Call Flow of Rx AAR Retry Inter-Pod Routing Case - When Binding is Found

The call flow describes the scenario where BSF Diameter Gateway pods uses inter-pod routing to send AAR request toward PCF Diameter Gateway pods on receiving the binding response from BSF Management service. BSF Diameter Gateway pods handle the failed AAA response from PCF Diameter Gateway pods.

Figure 3-10 Rx AAR Retry Inter-Pod Routing Case - When Binding Found

1. Application Function (AF) sends AAR request to BSF Diameter Gateway pod (Diam-GW-Pod1).
2. It sends binding request to BSF Management service.
3. BSF Management service sends binding response.
4. BSF Diameter Gateway pod1 on not finding any connection to PCF Diameter Gateway pods (PCF1, PCF2), it uses inter-pod routing and sends the AAR request to BSF Diameter Gateway pod2 (Diam-GW-Pod2).
5. BSF Diameter Gateway pod2 sends AAR request to PCF1 Diameter Gateway.
6. PCF1 Diameter Gateway sends a failed AAA response to BSF Diameter Gateway.
7. BSF Diameter Gateway resends the failed AAA message to PCF2 Diameter Gateway.
8. PCF2 Diameter Gateway sends a successful AAA response to BSF Diameter Gateway.
9. BSF Diameter Gateway sends this AAA message to AF.

Default Error Handling Configuration

BSF provides the default error handling configuration to retry on all error codes (except diameter result code 2xxx) and timeout for Rx AAA failed diameter messages. When the diameter message retry feature is enabled on Rx interface, these default error handling configurations get applied by default. The user has an option to enable/disable these default configurations through the CNC Console edit configurations.

For all default error handling configurations, the value for retry attempt is 1 and peer cycle back retry is false. The value of retry ranges from 1 to 10 times.

Managing Diameter Session Retry

This section explains the procedure to enable and configure the feature.

Enable

By default, Diameter Message Retry behavior is disabled for Rx interface and operator can enable this feature through the CNC Console configurations.

Configure Using CNC Console

Perform the feature configurations in CNC Console as described in Error Configurations section.

To enable over-writing of destination host on retry message, DIAMETER.ErrorHandler.Enable.UpdateDestinationHost key must be set to true in the Advanced Settings. For more information, see Settings.

Configure Using REST API

Perform the export/import error configurations as described in "Error Configurations" section in Oracle Communications Cloud Native Core, Binding Support Function REST Specification Document.

Observe

Observability

Metrics

Following metrics were updated with retry and retryReason dimensions in the Diameter Gateway Metrics section:

• ocbsf_diam_request_network_total
• ocbsf_diam_request_inter_total

Alerts

Following alerts are used by this feature:

• AAA_RX_FAIL_COUNT_EXCEEDS_CRITICAL_THRESHOLD
• AAA_RX_FAIL_COUNT_EXCEEDS_MAJOR_THRESHOLD
• AAA_RX_FAIL_COUNT_EXCEEDS_MINOR_THRESHOLD

Maintain

If you encounter alerts at system or application levels, see BSF Alerts section for resolution steps.

In case the alerts still persist, perform the following:

• Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Binding Support Function Troubleshooting Guide.
• Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.10 Support for BSF Status on NRF on CNC Console

CNC Console for BSF shows health status information of BSF and other producer NF instances related to BSF. It provides a consolidated status of the BSF instances registered with NRF.

BSF CNC Console has a new BSF NRF Status page, added under Status and Query page. This page provides the consolidated status of BSF instances registered with NRF. The user can also see the health status of primary and secondary NRF instances, or the alternate NRF.

Managing Support for BSF status on NRF on CNC Console

Enable

BSF Status on NRF feature uses NRF Client service. Hence ensure that the NRF Client service is enabled by setting the value global.nrfClientNfManagementEnable as true.

For more information on NRF Client configurations, see Configuring NRF Client section in Oracle Communications Cloud Native Core, Binding Support Function Installation, Upgrade, and Fault Recovery Guide.

Configure Using CNC Console

To view the health status using CNC Console, see BSF NRF Status.

Configure Using REST API

Perform the feature configurations as described in "NRF Status" and "NRF Client" sections in Oracle Communications Cloud Native Core, Binding Support REST Specification Guide

Observability

Metrics:

Following metrics were updated in the NRF Client Metrics section.

• nrfclient_perf_info_nf_profile_load
• nrfclient_current_nf_status
• nrfclient_nf_status_with_nrf
• nrfclient_nrf_operative_status
• nrfclient_nrf_status_total
• nrfclient_nrf_successive_healthy_count
• nrfclient_nrf_successive_unhealthy_count
• nrfclient_on_demand_conn_in_request_total
• nrfclient_on_demand_conn_out_response_total
• nrfclient_on_demand_processing_latency_ms
• ocpm_nrf_tracing_request_timeout_total
• nrfclient_nw_conn_out_request_total
• nrfclient_nw_conn_in_response_total
• nrfclient_nw_conn_in_notify_request_total
• nrfclient_nw_conn_out_notify_response_total
• nrfclient_network_message_processing_latency

Maintain

If you encounter alerts at system or application levels, see BSF Alerts section for resolution steps.

In case the alerts still persist, perform the following:

• Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Binding Support Function Troubleshooting Guide.
• Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.11 Network Policies

Network Policies are an application-centric construct that allows you to specify how a pod communicates with various network entities. It creates pod-level rules to control communication between the cluster's pods and services, and to determine which pods and services can access one another inside a cluster.

Previously, the pods under BSF deployment could be contacted by any other pods in the Kubernetes cluster without any restrictions. Now, Network Policies provide namespace-level isolation, which allows secured communications to and from BSF with rules defined in respective Network Policies. The Network Policies enforce access restrictions for all the applicable data flows except communication from Kubernetes node to pod for invoking container probe. For example, BSF internal microservices cannot be contacted directly by any other pods.

The following table lists the different access policies to be used by BSF traffic flows.

Note:

This list is not exhaustive but tries to represent all the traffic flows supported by BSF.

Microservice	Direction	Client/Server	Port	Access Policy
Configuration Svc	Egress	Database K8s API server for K8s secret	3306, K8s API Server Port	K8s Network Policies
Configuration Svc	Egress	Jaeger Agent	6831	K8s Network Policies
Configuration Svc	Ingress	Console Egress Gateway for configuration Ingress Gateway for configuration Perf-info for configuration App-info for configuration ATS ARS NrfClient	8081	K8s Network Policies
Configuration Svc	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
Ingress Gateway	Egress	Jaeger Agent	6831	K8s Network Policies
Ingress Gateway	Egress	Database K8s API Server for K8s Secret	3306, K8s API Server Port	K8s Network Policies
Ingress Gateway	Egress	Coherence	8000, 7	K8s Network Policies
Ingress Gateway	Ingress	Perf Info	8080	K8s Network Policies
Ingress Gateway	Ingress	SBI Peer	80, 443	3GPP-defined Access Policies
Ingress Gateway	Ingress	Coherence	8000, 8095, 8096	K8s Network Policies
Ingress Gateway	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
Egress Gateway	Egress	Jaeger Agent	6831	No Access Policy due to SBI Egress*
Egress Gateway	Egress	Database K8s API Server for K8s Secret	3306, K8s API Server Port	No Access Policy due to SBI Egress*
Egress Gateway	Egress	Coherence	8000, 8095, 8096	No Access Policy due to SBI Egress*
Egress Gateway	Egress	SBI Peer	Decided at run-time	3GPP-defined Access Policies
Egress Gateway	Egress	ARS	ARS Port	K8s Network Policies
Egress Gateway	Ingress	Registration	8080	K8s Network Policies
Egress Gateway	Ingress	Egress Gateway for coherence	8000	K8s Network Policies
Egress Gateway	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
Egress Gateway	Ingress	Coherence	8000, 8095, 8096	K8s Network Policies
Audit	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
Audit	Egress	Database K8s API Server for K8s Secret	3306, K8s API Server Port	K8s Network Policies
App Info	Ingress	Registration Subscription Auditor	5906	K8s Network Policies
App Info	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
diam-gateway	Egress	Jaeger Agent	6831	K8s Network Policies
diam-gateway	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
diam-gateway	Egress	Database K8s API Server for K8s Secret	3306, K8s API Server Port	K8s Network Policies
diam-gateway	Ingress	Peer	3868	K8s Network Policies
Bsf-Management	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
Bsf-Management	Egress	Jaeger Agent	6831	K8s Network Policies
Bsf-Management	Egress	Database K8s API Server for K8s Secret	3306, K8s API Server Port	K8s Network Policies
NRF-Client	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
NRF-Client	Egress	Jaeger Agent	6831	K8s Network Policies
NRF-Client	Egress	Database K8s API Server for K8s Secret	3306, K8s API Server Port	K8s Network Policies
Query-Svc	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
Query-Svc	Egress	Jaeger Agent	6831	K8s Network Policies
Query-Svc	Egress	Database K8s API Server for K8s Secret	3306, K8s API Server Port	K8s Network Policies

As an assumption when deploying BSF, the following labels are set by default:

Table 3-4 Default Labels

Pod	Label
All BSF Pods	app.kubernetes.io/part-of: ocbsf
Ingress Gateway Pod	app.kubernetes.io/name: ocbsf-ingress-gateway
Egress Gateway Pod	app.kubernetes.io/name: ocbsf-egress-gateway
Diam-gateway	app.kubernetes.io/name: diam-gateway
CM-Service	app.kubernetes.io/name: cm-service

BSF Security Policies:

• deny-ingress-all: To block all ingress traffic of pods presents in a BSF deployment.

• allow-ingress-sbi: To allow traffic on the Ingress Gateway Pods on container ports 8000 and 9443 to allow sbi traffic.

• allow-diam-gateway: To allow traffic on the Diameter-Gateway on port 3868.

• allow-ingress-prometheus: To allow the traffic flow from Prometheus service to the BSF with default ports (These ports can be changed by the customer).

• allow-ingress-from-bsf-pods: To allow ingress communication between the different microservices of the BSF.

• allow-ingress-from-console: To allow ingress communication between CNCC-Core and CM-Service on port 8081.

• deny-egress-all-except-egw: To block all egress traffic of pods present in a BSF deployment, except for Egress-Gateway and Diameter-Gateway.

• allow-egress-database: To allow the traffic flow from BSF to db sql port and db monitoring port with default ports (These ports can be changed by the customer).

• allow-egress-k8s-api: To allow the traffic flow from BSF to Kubernetes API server port (These ports can be changed by the customer).

• allow-egress-jaeger: To allow the traffic flow from BSF to Jaegar agent port and DNS service with default ports (These ports can be changed by the customer).

• allow-egress-traffic-and-dns: To allow the traffic flow from BSF to k8s DNS service with default ports (These ports can be changed by the customer).

• allow-egress-to-bsf-pods: To allow egress communication between the different microservices of BSF.

Note:

The default Network Policies to be applied for BSF are the recommended even though they are not very granular but they keep operational overhead to the minimum and still achieve access control security.

If a Network Policy is installed to restrict Prometheus escaping the metrics from the PODs, then a restart of the PODs is required. If the NP is installed before the PODs are up, then there is no need to restart the PODs.

Managing Network Policies

Enable

To use this feature, Network Policies need to be applied to the namespace wherein BSF is applied.

Configure

You can configure this feature using Helm. For information about configuring network policy for BSF deployment, see Configuring Network Policy section in Oracle Communications Cloud Native Core, Binding Support Function Installation, Upgrade, and Fault Recovery Guide.

Observe

There are no specific metrics and alerts required for the Network Policies feature.

3.12 Monitoring the Availability of SCP using HTTP2 OPTIONS

BSF determines the availability and reachability status of all SCPs irrespective of the configuration types.

This feature is an enhancement to the existing SBI routing functionality. Egress Gateway microservice interacts with SCP on their health API endpoints using HTTP2 OPTIONS method. It monitors the health of configured SCP peers to ensure that the traffic is routed directly to the healthy peers. This enhancement avoids routing or rerouting towards unhealthy peers, thus minimizing the latency time.

Egress Gateway microservice maintains the health status of all available and unavailable SCPs. It maintains the latest health of SCPs by periodically monitoring and uses this data to route egress traffic to the most preferred healthy SCP.

Figure 3-11 New SCP Selection Mechanism

Once peerconfiguration, peersetconfiguration, routesconfiguration, and peermonitoringconfiguration parameters are configured at Egress Gateway microservice, and all SCPs (after Alternate Route Service (ARS) resolution, if any vFQDN is configured) are marked initially as healthy. The peers attached to the associated peerset are scheduled to run health API checks and update the health status continuously.

During the installation, the value of the parameter peermonitoringconfiguration is set to false by default. Since, this feature is an add-on to the existing SBI Routing feature and will be activated if the sbirouteconfig feature is enabled. To enable this feature, perform the following:

• configure peerconfiguration with healthApiPath
• configure peersetconfiguration
• configure sbiroutingerroractionsets
• configure sbiroutingerroractionsets
• configure routesconfiguration
• enable peermonitoring

If SBI Routing feature is enabled before upgrading, the healthApi in peerconfiguration should be attached manually to existing configured peers. If the operator tries to enable peermonitoringconfiguration and the targeted peers do not have the healthApiPath then an appropriate error response is sent.

Managing Monitoring the Availability of SCP Using SCP Health APIs

This section explains the procedure to enable and configure the feature.

Configure

You can configure the Monitoring the Availability of SCP using the REST API.

Configure Using REST API: Perform the following feature configurations as described in Oracle Communications Cloud Native Core, Binding Support Function REST Specification Document:

• create or update peer Peer Configuration with health status endpoint details.
• create or update the peerset peersetconfiguration to assign these peers
• enable the feature using the below peermonitoring configuration peermonitoringconfiguration.

Note:

Health Monitoring of the peer will start only after the feature is enabled and the corresponding peerset is used in sbirouteconfig.

Observe

Following metrics are added in the Metrics in Egress Gateway Metrics for SCP section:

• oc_egressgateway_peer_health_status
• oc_egressgateway_peer_health_ping_request_total
• oc_egressgateway_peer_health_ping_response_total
• oc_egressgateway_peer_health_status_transitions_total
• oc_egressgateway_peer_count
• oc_egressgateway_peer_available_count

Alert

Following alerts are added in the Alert section:

• SCP_PEER_UNAVAILABLE
• SCP_PEER_UNAVAILABLE

3.13 Supports 3gpp-Sbi-Correlation-Info Header

The 3gpp-Sbi-Correlation-Info header may be used to contain correlation information such as UE identity, that may be used by an operator in various offline network management, performance analysis and troubleshooting tools/applications to identify messages (requests, responses, subscriptions, notifications) related to a particular subscriber.

By supporting this feature, BSF as a service consumer or as a service producer generates, forwards and sends the UE identity in 3gpp-Sbi-Correlation-Info header, to identify the UE related to the HTTP request or response.

BSF provides a global configurations page on CNC Console GUI to enable or disable the correlation-info header feature. On enabling,

• BSF receives the correlation-info header and forwards them to the producer NFs.
• BSF does not receive the correlation-info header, then BSF generates and forwards them to the producer NFs.

In BSF, generation of new correlation-info header is managed by the Management services configuration page. This allows enable or disable of header generation along with the flexibility of selecting correlation type to use for the header. The correlation-types such as SUPI, GPSI, or both are supported for this release.

The generated or received headers can only be forwarded when the setting Send Correlation-Info Header as part of Management services is enabled.

3gpp-Sbi-Correlation-Info

The header contains correlation information such as UE identifier related to the HTTP request or response.

Note:

1. The possibility to include more than 1 correlationinfo parameter in the 3gpp-Sbi-Correlation-Info header is kept for future extensibility.

   correlationinfo = ctype "-" cvalue

   ctype = "imsi" / "impi" / "suci" / "nai" / "gci" / "gli" / "impu" / "msisdn" / "extid" / "imei" / "imeisv" / "mac" / "eui" / token

2. The token is defined for future extensibility.

   The token of ctype shall not use the dash ("-") character.

   cvalue = 1*tchar

Table 3-5 The format of cvalue shall comply with the data type description.

ctype	Description
SUPI	VarUeId format defined for IMSI and starting after the string "imsi-"
GPSI	VarUeId format defined for MSISDN and starting after the string "msisdn-"

Table 3-6 3GPP defined Custom HTTP Headers

Header	Description	Example
3gpp-sbi-correlation-info	This header may be used to contain correlation information such as UE identity, that may be used by an operator in various offline network management, performance analysis and troubleshooting tools/applications to identify messages (requests, responses, subscriptions, notifications) related to a particular subscriber.	EXAMPLE 1: When UE identifier used is SUPI and SUPI type is an IMSI: 3gpp-Sbi-Correlation-Info: imsi-345012123123123 EXAMPLE 2: When UE identifier used is GPSI and GPSI type is an MSISDN:3gpp-Sbi-Correlation-Info: msisdn-1234567890 EXAMPLE 3: When UE identifiers used are SUPI and GPSI where SUPI type is an IMSI and GPSI type is an MSISDN:3gpp-Sbi-Correlation-Info: imsi-345012123123123; msisdn-1234567890

Managing SBI messages correlation using Subscriber Identity

This section explains the procedure to enable and configure the feature.

Configure

In CNC Console, enable this feature in the general settings page.

For more details on enabling or disabling the correlation-info header on GUI, see General Settings.

Configure Using REST API

For configuring parameters for SBI messages correlation using Subscriber Identity feature using REST APIs, see Oracle Communications Cloud Native Core, Binding Support Function REST API Specification Guide.

Observe

Following metrics are added in Correlation-Info Header Metrics section:

• ocbsf_correlation_info_header_received
• ocbsf_correlation_info_header_forwarded
• ocbsf_correlation_info_header_generated

3.14 Configurations for Pre and Post Upgrade/Install Validations

This feature applies validation checks that are required on the application, databases, and its related tables before and after the upgrade/installation of BSF application.

On enabling this mandatory pre-flight and post-flight validation checks, for successful upgrade/installation following are validated:

• does the related database exists
• does all the required tables exist
• does the required table schema exist for all the required tables
• does all the required infrastructure exists

This pre-flight and post-flight checks ensures that all the dependent databases, tables, schema, applications are in right order for performing successful update/installation.

For more information on how to how to set the parameter value for pre and post flight checks, see Upgrade Hardening, Pre and Post Flight Checks section in Oracle Communications Cloud Native core, Binding Support Function (BSF) Installation, Upgrade and Fault Recovery Guide.

3.15 Detection and Handling of Late Arrival Requests

BSF receives requests from Ingress Gateway with the 3GPP headers. These requests help in detecting the response time for the BSF Management Service. The Ingress Gateway receives the following headers:

• 3gpp-Sbi-Origination-Timestamp- It contains the timestamp when the originating entity initiates the request
• 3gpp-Sbi-Max-Rsp-Time- The header indicates the duration (expressed in milliseconds) during which the HTTP client waits for a response.

If the configuration for determining the late Arriving requests is enabled and BSF does not receive the required headers, the requests are valid and processed. The call flow will continue as normal.

BSF must be able to read the 3gpp-Sbi-Origination-Timestamp and 3gpp-Sbi-Max-Rsp-Time headers to respond to the request. Consider the following scenarios:

• If the sum of 3gpp-Sbi-Origination-Timestamp and 3gpp-Sbi-Max-Rsp-Time is less than the current time, the PCF service rejects the message with a 504 HTTP code and sends the message "TIMED_OUT_REQUEST".
• If the request does not include either 3gpp-Sbi-Origination-Timestamp or 3gpp-Sbi-Sender-Timestamp, or 3gpp-Sbi-Max-Rsp-Time headers, then the request is accepted. There are no changes in the call flow with the inclusion of collision detection.
• If 3gpp-Sbi-Max-Rsp-Time receives a negative value, the header is considered invalid. In this case, the service fallbacks to the default behavior and accepts the request irrespective of the 3gpp-Sbi-Origination-Timestamp or 3gpp-Sbi-Sender-Timestamp value.

The following diagram illustrates the request timeout in BSF:

Figure 3-12 Request Timeout in BSF

For handling and detection of Late Arrival and Collision Detection functionality in BSF, it is necessary that these headers and the new Custom header are transmitted from PCF to BSF.

Custom Header Enhancement adds the Time Stamp as a default value in the request and response custom headers with specific time formats and time zones. A valid function definition for timestamp in the configuration is: func: currentTime(time-format,time-zone).

Note: Here, only the GMT, IST, PST, and UTC time zones are to be considered for all 5G timestamps.

The only date format supported for the headers is RFC 7231: EEE, dd MMM yyyy HH:mm:ss.SSS zzz (Sun, 04 Aug 2019 08:49:37.845 GMT).

Any other format will result in a parse error which leads to not using the header for the feature (taking it as null value).

Collision Detection

BSF may encounter a colliding or duplicate request for a binding registration from a different PCF. BSF shall consider a request as colliding or duplicate binding registration when two registrations are for the same subscriber (SUPI), DNN, SNSSAI, IPV4/IPv6 prefix, or IpDomain (in case IPv4Address is present) but from different PCF instances (ID/pcfDiamHost/pcfFqdn or pcfIpEndPoints).

In case support for timer headers is enabled:

• If 3gpp-Sbi-Origination-Timestamp header support is enabled and the colliding or the duplicate requests contain the header with an appropriate value, compare the values. If the values are different, it will consider the request with the more recent timestamp in the header.
• If the value of 3gpp-Sbi-Origination-Timestamp in both the requests is the same, then if Custom-Sbi-Sender-Timestamp header support is enabled and the colliding or the duplicate requests contain the header with an appropriate value, compare the values. It will consider the request with the more recent timestamp in the header.

In case support for timer headers is disabled:

• If 3gpp-Sbi-Sender-Timestamp header support is enabled and the colliding or the duplicate requests contain the header with an appropriate value, compare the values. If the values are different, it will consider the request with the more recent timestamp in the header.
• If the value of 3gpp-Sbi-Sender-Timestamp in both requests is the same, it will consider the later request.

If the incoming colliding or duplicate request has an older timestamp than the ongoing or existing request or record, it will reject the request with an HTTP "403 Forbidden" status code. The condition name for the error in the GUI is "Existing binding information found in DB" on the SBI Error Codes configuration page. The BSF function to detect and resolve collision requests is configurable.

If Late Arrival functionality is not enabled, the headers must be propagated to bsf-management-service if collision detection is required or enabled. For this, Ingress Gateway should populate three new collision headers following the required criteria:

Table 3-7 Collision Headers

At Ingress Gateway	At bsf-management-service
3gpp-Sbi-Origination-Timestamp	collision-3gpp-origination-timestamp
Custom-Sbi-Sender-Timestamp	collision-custom-sender-timestamp
3gpp-Sbi-Sender-Timestamp	collision-3gpp-sender-timestamp

Note:

These collision headers implement collision detection at BSF.

Enable

You can enable or disable the collision detection in the General Settings of the General Configuration window of the CNC Console.

Figure 3-13 Enabling Collision Detection

You can enable or disable the collision detection feature using the REST API for BSF. Use the General Settings REST API to enable or disable this feature.

REST API Path: /oc-bsf-configuration/v1/general

For more information, see the Oracle Communications Cloud Native Core Binding Support Function User Guide.

Configuration

To create the collision headers that are used for collision detection in BSF it is necessary to add the following configuration to BSF Ingress Gateway.

routesConfig:
    - id: bsf_management_register
      uri: http://{{ template "service-name-bsf-management" . }}:{{ .Values.global.servicePorts.bsfManagementServiceHttp }}
      path: /nbsf-management/**
      order: 1
      method: POST
      filters:
        customReqHeaderEntryFilter:
          headers:
            - methods:
              - POST
              headersList:
                - headerName: 3gpp-Sbi-Message-Priority
                  defaultVal: 24
                  source: incomingReq
                  sourceHeader: 3gpp-Sbi-Message-Priority
                  override: false
                - headerName: collision-3gpp-origination-timestamp
                  source: incomingReq
                  sourceHeader: 3gpp-Sbi-Origination-Timestamp
                  override: false
                - headerName: collision-custom-sender-timestamp
                  source: incomingReq
                  sourceHeader: Custom-Sbi-Sender-Timestamp
                  override: false

               - headerName: collision-3gpp-sender-timestamp
                  source: incomingReq
                  sourceHeader: 3gpp-Sbi-Sender-Timestamp
                  override: false

Observe

To observe the collision detection functionality, you can use metrics that are specific to BSF management service. For information, see Binding Support Function Metrics.

3.16 Support for Timer Configuration

BSF supports the configuration of Diameter interfaces or Rx interfaces timers for all the applicable Diameter messages. The timer configuration needs to be configured for AAR, RAR, STR, and ASR messages. The timer configuration is an option to configure the diameter response timeout value for diameter messages. If the timer value is not configured, then the BSF Diameter gateway works with the default value of 4000 milliseconds for AAR, RAR, STR, and ASR messages.

The Diameter response timeout or the timer value is configured per Diameter interface level. This value can also be configured per message level of the Diameter interface. The timer configuration needs to be configured for Authentication Request (AAR), Re-Auth-Request (RAR), Session-Termination-Request (STR), and Abort-Session-Request (ASR) messages.

For BSF, currently Diameter Rx interface is applicable. The response timeout value is configured using the Rx application level and its messages (AAR, RAR, STR, and ASR) level.

Enable

The timer configuration is a functionality supported by Binding Support Function configurations. You do not need to enable or disable this feature.

Configure

The Binding discovery request timeout configuration parameter is used for request timeout value for the discovery request sent by the BSF Diameter Gateway towards the BSF Management Service.

Figure 3-14 General Settings

The Enhanced Timer Configuration is available on the settings of the Diameter Configuration page.

Figure 3-15 Enhanced Timer Configuration

This configuration accepts interface level Diameter response timeout value. If the Diameter interface level timeout is configured, then the user is able to configure message level response timeout value for the corresponding Diameter interface.The response timeout value range for interface and message level is 3000 milliseconds to 2147483647 milliseconds.

In the CNC Console, you can specify the Command Code Response TimeOut value for the AAR, RAR, STR, and ASR message types.

Figure 3-16 Edit Enhanced Timer Configuration

You can customize the configurations related to this feature using the CNC Console or REST APIs for BSF.

• Configure using CNC Console: Perform the feature configurations on the General Configurations and Diameter Configurations page. For more information about the configurations, see General Settings and Diameter Configurations.
• Configure using REST API: Perform the configurations using GET and PUT operations. For more information about REST API configuration, see Oracle Communications Cloud Native Core, Binding Support Function REST Specification Document.

Observe

To observe the timer configuration functionality, you can use metrics that are specific to BSF management service. For information, see Binding Support Function Metrics.

3.17 Support for Server Header

BSF handles various requests from consumer Network Functions (NFs) and other network entities over HTTP protocol. On receiving these requests, BSF validates and processes them before responding to these requests. In case, BSF sends an error response, then the consumer NFs need to know the source of the error to trouble shoot the error and take corrective measures. The integration of this feature at BSF helps to determine the originator of the error response.

This feature offers the support for Server Header in BSF responses, which contains information about the origin of an error response and the type of the error encountered. The Server Header includes the type of NF as "NF Type", followed by a “-” and the identity of the NF or the network entity. It is expected to be present in all BSF responses in the following format:

<NF_Type>-<NF_Instance_Id>

Where,

• <NF Type> is the type of the NF generating the error.
• <NF Instance-Id> is the unique identifier of the NF instance generating the error response.

For example: BSF-54804518-4191-46b3-955c-ac631f953ed8

The inclusion of the Server header in the BSF response is configurable, and can be enabled or disabled using a flag. Also the error codes that are included as part of the Server header in the error response are also configurable. The configuration of these parameters are done through either with REST APIs that are exposed through configuration server or Helm Configurations.

The operation mode that is either REST or HELM for Server Header configuration is done using the below flag:

ingress-gateway: 
  serverHeaderConfigMode: REST # Possible values: HELM, REST. Based on this value, the feature flag for "server"  header will need to be enabled either in Helm configuration or Rest  configuration.

Note:

Nf Type and Nf Instance Id are mandatory fields for Server Header to get included in the error response. If either of the fields Nf Type or Nf Instance Id are configured as empty, then the Server Header will not get included in the error response.

Managing Server Header

Enable

By default, this feature is disabled.

You can enable the Server Header feature using Helm or REST API configurations:

• Helm: To enable the server header feature using Helm configuration, set the value for parameter serverHeaderConfigMode to HELM in the custom-values.yaml file. Then, set the value for parameter serverHeaderDetails.enabled to true under global and routesConfig for ingress-gateway.
• REST API:To enable the server header feature using REST configuration, set the value for parameter serverHeaderConfigMode to REST in the custom-values.yaml file. Using REST API, set the enabled parameter to true in the following resource URI:

  {apiRoot}/BSF/nf-common-component/v1/igw/serverheaderdetails

Configure

You can configure the server header feature using the REST API or CNC Console:

• Configure using REST API:
  Perform the REST API configurations in the following sequence to configure this feature:

  1. Configure serverheaderdetails to enable the feature.

     {apiRoot}/BSF/nf-common-component/v1/igw/serverheaderdetails

  2. Configure routesconfiguration to map route ID and its corresponding route-level configuration.

     {apiRoot}/BSF/nf-common-component/v1/igw/routesconfiguration

  3. Configure errorcodeserieslist to update the errorcodeserieslist that are used to list the configurable exception or error for an error scenario in Ingress Gateway.

     {apiRoot}/BSF/nf-common-component/v1/{serviceName}/errorcodeserieslist

  Note:

  If you define server header configuration at both global and route levels, the route level configuration takes precedence over the global level configuration.

  For more information, see the "Server Header at Ingress Gateway" section in Oracle Communications Cloud Native Core, Binding Support Function REST Specification Guide.

• Configure using Helm: When parameter serverHeaderConfigMode is set to HELM and to configure the Server Header at Ingress Gateway, you need to perform the helm configurations either at Global or at Route level.

  Following Helm Configuration performed at Globel Level:

  
  # All attributes under "serverHeaderDetails" will need to be configured only if "serverHeaderConfigMode" is set as "HELM"
  serverHeaderDetails:
    enabled: true
    errorCodeSeriesId: E1
    configuration:
      nfType: BSF    
      nfInstanceId: INS-1
   
  # Use below configuration to define errorCodeSeries list
  errorCodeSeriesList:
    # Value of "id" attribute will need to used for assigning "errorCodeSeriesId" either at Global or Route level conf for Server header.
  - id: E1
    errorCodeSeries:
    - errorSet: 4xx
      errorCodes:
      - 400
      - 408
    - errorSet: 5xx
      errorCodes:
      - 500
      - 503
  - id: E2
    errorCodeSeries:
    - errorSet: 4xx
      errorCodes:
      - -1

  Following Helm Configuration performed at Route Level:

  
  routesConfig:
  - id: backend_ms1_route
    uri: https://backend-ms1:8440/
    path: /ms1/**
    order: 1
    metadata:
      # All attributes under "serverHeaderDetails" will need to be configured only if "serverHeaderConfigMode" is set as "HELM" and Route level configuration is required. If not defined, Global configurations will be used
      serverHeaderDetails:
        enabled: true     # Since this flag is set to true at Route level, "server" header configuration will be enabled for this Route with respective "errorCodeSeriesId" as E2
        errorCodeSeriesId: E2 # This attribute will need to be defined if "server" header configuration is enabled at Route level.
  - id: backend_ms2_route
    uri: https://backend-ms2:8550/
    path: /ms2/**
    order: 2
    metadata:
      # All attributes under "serverHeaderDetails" will need to be configured only if "serverHeaderConfigMode" is set as "HELM" and Route level configuration is required. If not defined, Global configurations will be used
      serverHeaderDetails:
        enabled: false    # Since this flag is set to false at Route level, "server" header configuration will be disabled for this Route altogether.

  Note:

  If you define server header configuration at both global and route levels, the route level configuration takes precedence over the global level configuration.

  For more information, see the "Server Header Configurations" section in the Oracle Communications Cloud Native Core, Binding Support Function Installation and Upgrade Guide.

• Configure using CNC Console: A new group, NF Server Settings is added to the Management Service page. For more information, see see Service Configurations.

3.18 Support for Session Retry and Alternate Route Service

In previous releases, Binding Support Function was configured with primary and secondary Network Repository Function (NRF) statically and limiting to a specific number. Starting with Release 1.8.0 of BSF, session retry enables the alternate recovery mechanisms to mitigate the impact of any unavailable resource.

This feature allows you to configure virtual FQDNs and perform DNS SRV Lookup to retrieve alternate failover NRF which can be maintained dynamically at the DNS Server.

Managing Session Retry and Alternate Route Service

Enable

To enable the Session Retry and Alternate Routing functionality, set the value of enableVirtualNrfResolution to true in the custom-values.yaml file for BSF. For more information on setting the parameter value, see section "Configuring NRF Client" in Oracle Communications Cloud Native Binding Support Function Installation Guide.

Configure

You can configure the parameter for Session Retry and Alternate Routing functionality by updating the custom-values.yaml file for BSF.

• To configure the retry functionality, see "Configuring NRF Client" in Oracle Communications Cloud Native Binding Support Function Installation Guide.
• To configure alternate routing, see section "Alternate Route Service Configuration" in Oracle Communications Cloud Native Binding Support Function Installation Guide.

3.19 Turning off AccessToken signature Validation

OAuth access tokens grant an NF service consumer access to the services of an NF producer of a particular NFType, for a specific period. With this feature, BSF can turn off AccessToken signature validation at the application layer. For example when Aspen service mesh is integrated with BSF, the service mesh can perform the AccessToken validation. In such cases, operator may want BSF to skip validating the AccessToken signature. BSF checks audience and scope fields only, and sends 403 - Forbidden response code when any of the values do not match. In addition, when BSF receives a request without the AccessToken, it sends a 401 - Unauthorized response code. To turn off the AccessToken signature validation at BSF application, the user must perform configurations as described in the Oracle Communications Cloud Native Core Binding Support Function Installation Guide.

3.20 XFCC Header Validation

Overview

With XFCC Header Validation feature, Binding Support Function (BSF) as a producer, checks if the SCP that is sending the HTTP request is the same SCP that is configured in the BSF. BSF performs this check by comparing the FQDN of the SCP present in the “x-forwarded-client-cert” (XFCC) of http2 header with the list of FQDN of the SCPs configured in the PCF. This configured list contains all the host FQDNs resolved successfully via DNS-SRV as well as static SCPs. The header validation can be enabled at global as well as at the route level.

Note:

This feature is applicable only when SCP is deployed in the network topology.

Configuring SCPs at BSF

To configure SCP, you need to customize custom.yaml at the time of deploying BSF.

In the earlier releases, users could only configure SCPs statitcally as shown in the following snippet:

xfccHeaderValidation:
    validation:
                 
      enabled: false
      nfList:
        - scp.com
        - smf.com
        - amf.com

However, in BSF release 22.1.0 or later, users can configure single or multiple virtual FQDNs for the SCP along with the static configuration as shown in the following snippet:

global:
    xfccHeaderValidation:
      validation:
        enabled: false
        peerList:
          - name: scp.com
          - name: smf.com
          - name: amf.com
          - name: scp1.com
            enabled: true
          - name: scp2.com
          - name: scp3.com
            enabled: false
          - name: xyz.test.com
            enabled: true
            scheme: http
            type: virtual
          - name: abc.test.com
            enabled: true
            scheme: https
            type: virtual
          - name: xfcc.test.com
            enabled: false
            scheme: http
            type: virtual

Static SCP: To define an SCP instance statically, add the name and set enabled parameter to true in the peerList. If the enabled parameter is set to false for an instance, then it is not included in the list of configured FQDNs. If you do not specify enabled parameter then by default it is considered as true.

Virtual SCP: To define an SCP with virtual FQDN, add the name, scheme as http or https, type as virtual, and set enabled parameter to true. If the enabled parameter is set to false for an instance, then it is not included in the list of configured FQDNs.

Resolving FQDNs to find Authorized SCPs

During the bootup of Ingress Gateway, it tries to resolve the configured virtual FQDN via Alternate Route service using the following helm configuration:

dnsSrv:
    port: *svcAlternateRouteServiceHttp #Alternate-route port for scheme 'http'. Change is required if the scheme below changes.
    scheme: http

If Alternate Route service is unable to resolve the configured virtual host, Ingress Gateway stores it in the list of failed FQDNs and reattempts the request at 300 s (default value configured for dnsResolutionInterval).

The following metric is used when the request to resolve configured virtual FQDNs is unsuccessful:

• oc_ingressgateway_dns_resolution: This metric is pegged when DNS resolution for a given FQDN fails.
• oc_ingressgateway_dns_resolution_failure: This is a gauge metric that is triggered when DNS resolution for a given FQDN fails.

Handling Traffic Flow

The XFCC header is validated when:

• a single XFCC header present in the incoming request to IGW
• multiple XFCC headers are present in the incoming request to IGW

Validating single XFCC Header

The following figure describes the call flow for validation of a single XFCC header:

Figure 3-17 Call Flow Validation of Single XFCC Header

Table 3-8 Single XFCC Header Configuration

Scenario	Condition	Action
Ensure that the XFCC Header validation parameter is enabled for the corresponding route match and the matchCerts count is configured correctly.Given XFCC Header validation parameter is enabled for the corresponding route match and matchCerts count correctly configured.	When the matchField parameter of the client certificate field in XFCC header matches with one of the configured NF FQDNs .	Forwards the request to a back-end microservice and receives a corresponding response.
Given XFCC header validation parameter is enabled for the corresponding route match and matchCerts count correctly configured.	When matchField parameter of client certificate field in XFCC header does not match with the configured NF FQDNs.	Return a 400 Bad Request response from Ingress Gateway. For more infirmation about error codes, see SBI Error Codes Configurations
Given XFCC header validation parameter disabled for the corresponding route match.	NA	Forwards the request to the back-end microservice and receives a corresponding response.

Example of a single XFCC header request:

x-forwarded-client-cert: By=http://router1.blr.com;Hash=468ed33be74eee6556d90c0149c1309e9ba61d6425303443c0748a02dd8de68; Subject="/C=US/ST=CA/L=San Francisco/OU=Lyft/CN=Test Client"; URI=http://testenv1.blr.com;DNS=blr.com; DNS=www.blr.com

Validating multiple XFCC Headers

The following figure describes the call flow for validation of multiple XFCC headers for the following scenarios:

Figure 3-18 Call Flow Validation of Multiple XFCC Headers

Table 3-9 Multiple XFCC Headers Configuration

Scenrio	Condition	Action
Given XFCC header validation parameter is enabled and matchCerts count correctly configured to validate across XFCC header certificates from the right most entry.	When matchField parameter of the corresponding client certificate field being validated against currently in the corresponding XFCC header matches with the NF FQDN's configured at Ingress Gateway.	Consider the request as a valid request and forward the request to the back-end micro-service and receive a corresponding response.
Given XFCC header validation parameter is enabled and matchCerts count correctly configured to validate across XFCC header certificates from the right most entry.	When matchField parameter of client certificate field in corresponding XFCC headers do not match with the NF FQDN's configured at Ingress Gateway for the corresponding matchCerts count.	Consider the request as an invalid request and return a 400 Bad Request response from IGW. For more infirmation about error codes, see SBI Error Codes Configurations
Given XFCC header validation parameter is enabled and matchCerts count -1.	NA	Consider the request as valid request and match against the corresponding match field in all XFCC headers, if validation successful then forward the request else return 400 BAD Request.
Given XFCC header validation parameter is disabled.	NA	Forward the request to back-end microservice and receive a corresponding response.

Example of multiple XFCC header request:

x-forwarded-client-cert:By=http://router1.blr.com;Hash=468ed33be74eee6556d90c0149c1309e9ba61d6425303443c0748a02dd8de68; Subject="/C=US/ST=CA/L=San Francisco/OU=Lyft/CN=nf1.com"; URI=http://testenv1.blr.com; DNS=nf8.com; DNS=nf1.com; DNS=nf6.com, By=http://router1.blr.com;Hash=468ed33be74eee6556d90c0149c1309e9ba61d6425303443c0748a02dd8de68; Subject="/C=US/ST=CA/L=San Francisco/OU=Lyft/CN=nf10.com"; URI=http://testenv1.blr.com; DNS=nf10.com; DNS=nf8.com; DNS=nf9.com, By=http://routexr1.blr.com;Hash=468ed33be74eee6556d90c0149c1309e9ba61d6425303443c0748a02dd8de68; Subject="/C=US/ST=CA/L=San Francisco/OU=Lyft/CN=nf4.com"; URI=http://testenv1.blr.com; DNS=nf9.com; DNS=nf4.com;DNS=nf1.com

Managing XFCC Header Validation

• Global Level: To enable or disable the XFCC header validation feature, set the value of the ingress-gateway.global.xfccHeaderValidation.validation.enabled to true or false respectively.
• Route Level: To enable or disable the XFCC header validation feature at route level, set the value of the xfccHeaderValidation.validationEnabled under routesConfig to true or false respectively.

  Note:

  If the xfccHeaderValidation.validationEnabled parameter is defined at route level, then the configuration takes precedence over global configuration.
  For instance, if you want to enable XFCC header validation for selected routes, then set the global parameter as false and make route specific configuration to true.

  global:
      xfccHeaderValidation:
        validation:
          enabled: false

  routesConfig:
      - id: reverse_bsf_service
        uri: http://{{ template "service-prefix" . }}-bsf-management:{{ .Values.global.servicePorts.bsfManagementServiceHttp }}
        path: /nbsf-management/**
        order: 1       
        metadata:
          xfccHeaderValidation:
            validationEnabled: true

For more information about setting the parameter values, see section "XFCC Header Validation Configuration" in Oracle Communications Cloud Native Binding Support Function Installation Guide.

Configure

You can configure the parameter for XFCC Header Validation by updating the custom-values.yaml file for BSF. For more information about configuring the parameter value, see the "XFCC Header Validation Configuration" section in Oracle Communications Cloud Native Binding Support Function Installation Guide.

Observe

To observe the XFCC header validation functionality, you can use metrics that are specific to Ingress Gateway. For information, see Ingress Gateway Metrics.

Configuring Error Codes

When the XFCC header validation feature is enabled and SCP FQDN in the incoming header does not match the configured FQDN in PCF, XFCC header is not present, or XFCC header is invalid, then PCF may return error in the response. Users have the ability to customize the error code returned in the response using the following helm configuration:

errorTrigger:
          - exceptionType: XFCC_HEADER_INVALID
            errorCode: '401'
            errorCause: xfcc header is invalid
            errorTitle: 'Invalid XFCC Header'
            errorDescription: 'Invalid XFCC Header'
          - exceptionType: XFCC_MATCHCERTCOUNT_GREATER_THAN_CERTS_IN_HEADER
            errorCode: '402'
            errorCause: matchCerts count is greater than the certs in the request
            errorTitle: ''
            errorDescription: ''
          - exceptionType: XFCC_HEADER_NOT_PRESENT_OR_EMPTY
            errorCode: '403'
            errorCause: xfcc header is not present or empty in the request
            errorTitle: ''
            errorDescription: ''

If the configured error code in the errorCodeOnValidationFailure field lies in 3xx error series only then the values for retryAfter and redirectUrl if configured under XFCC Header Validation Configuration at Ingress Gateway are used to populate Retry-After and LOCATION headers correspondingly while sending error response from Ingress Gateway.

3.21 Georedundancy Support

The Cloud Native Core (CNC) architecture supports Geographically Redundant (Georedundant) BSF deployments to ensure high availability and redundancy. It offers a two or three sites georedundancy to ensure service availability when one of the BSF sites is down.

The specifications for georedundancy feature are as follows:

• All the georedundant sites must have Helm and REST based configurations except for NF InstanceId, BSF Endpoint, and port.
• The georedundant BSF sites must be reachable from NFs or Peers on all the sites.
• The same NFs or Peers must not communicate to other georedundant BSF sites simultaneously for the same session.
• All the sites must register with NRF independently and work in an active state.
• All BSF instances share the Session State data by using the DB Tier replication service. This enables service continuity during the failure of any of the sites.
• The NFs in a given site can discover BSF instances through NRF. However, local configurations such as DNS SRV or static configuration are required to determine the primary and secondary or alternate BSF configuration. When the primary instance is available, the NFs send service requests to the primary instance.
• NRF always reflects current functional status of a given BSF instance. Thus, during the failure of a given BSF instance, the value of NfStatus is updated to SUSPENDED by either NRF or BSF instance. Therefore, when NF detects failure of primary instance due to error response or status notification from NRF, the NF redirects its traffic to the secondary instance, until the primary instance becomes available again.

BSF supports the following types of georedundant deployment:

Two-Site Georedundancy Deployment

The following diagram depicts the topology for two-site georedundant BSF deployment:

Figure 3-19 Two-Site Georedundancy

After the second site instance of the cnDBTier is created, you can establish the two site georedundant connections that provide bi-directional data replication between both sites. Therefore, when the records are updated at one site, these changes are replicated to the other remote site in real-time. These updates can be creating, changing, or deleting a record.

Three-Site Georedundancy Deployment

The following diagram depicts the topology for three site georedundant BSF deployment:

Figure 3-20 Three-Site Georedundancy

In case of three site georedundancy, bi-directional replication is established from each site to the other two sites. The database updates from each site are replicated to the other two sites over the replication channel.

The advantages of three-site georedundancy are:

• In case of a single site failure, the remaining two sites keep establishing the bi-directional replication.
• No action is required in case of a site failure.
• Requires 4 SQL pods and 2 rep-svc pods at each site

When the records are updated at one site, these changes are replicated to the other two remote sites in real-time. These updates can be creating, changing, or deleting a record.

Managing Georedundancy

Deploy

To deploy BSF in a georedundant environment:

1. Set up the replicated cnDBTier version 1.8.0.0.3 or above on two or three sites as required. For more information about installing cnDBTier, see "Installing cnDBTier" in Oracle Communications cnDBTier Installation Guide.
2. Deploy BSF over the replicated (two or three) cnDBTier sites. For more information about installing and deploying BSF, see Oracle Communications Cloud Native Binding Support Function Installation Guide.

Configure

To configure georedundancy:

You need to configure the georedundancy functionality while deploying the BSF instances on the replicated sites. The following parameters must be updated in the custom-values.yaml file for BSF:

Table 3-10 Georedundancy Parameters

Parameter	Description
global.envMysqlHost	The database instance for each site. BSF communicates to the database at the same site only.
global.nfInstanceId	The ID for the site
config-server.envMysqlDatabase	The database for the config server. The two sites must use different database names for config server
cm-service.envCommonConfigMysqlDatabase	The common configuration database. It must be different on the sites
nrf-client.configmapApplicationConfig.profile	Configuration data for nrf client. The appProfile and the nfInstanceId parameters must be aligned with global.nfInstanceId
nrf-client-nfdiscovery.dbConfig.dbName	The common configuration database. It must be different on the sites
nrf-client-nfmanagement.dbConfig.dbName	The common configuration database. It must be different on the sites
appinfo.dbConfig.dbName	The common configuration database. It must be different on the sites
perf-info.dbConfig.dbName	The common configuration database. It must be different on the sites
BSFds.envMysqlDatabaseConfigServer	The database for the config server. The two sites must use different database names for config server
ingress-gateway.dbConfig.dbName	The common configuration database for ingress gateway. It must be different on the sites
egress-gateway.dbConfig.dbName	The common configuration database for egress gateway. It must be different on the sites
alternate-route.dbConfig.dbName	The common configuration database for alternate route. It must be different on the sites

For more information about configuring the parameter value, see the "Alternate Route Service Configuration" section in Oracle Communications Cloud Native Binding Support Function Installation Guide.

Observe

cnDBTier generates critical alerts in case of application or database failure. For more information, see Oracle Communications Cloud Native Core DBTier User Guide.

Maintain

BSF allows you to monitor the georedundancy deployment through cnDBTier alerts. Access the Prometheus GUI to check for new App alerts.

3.22 Diameter Gateway Pod Congestion Control

The Diameter Gateway is a diameter proxy agent for Binding Support Function (BSF). It is a front-end microservice for diameter traffic for both Ingress and Egress traffic and can get congested due to higher traffic, higher CPU usage, and higher memory utilization. Thus, it is imperative to have suitable congestion control features in place for Diameter Gateway pods to avoid adverse impacts on latency and performance.

Another reason for the need for a congestion control mechanism for Diameter Gateway is the nature of diameter connections. An external LoadBalancer distributes these long-lived connections. As shown in the following image, when the LoadBalancer routes an incoming request from network to Diameter Gateway pod (indicated by green line), the balancer does not take health or load of the pod into consideration. As a result, uneven distribution of traffic can happen, and gateway pods experience congestion.

In Binding Support Function, a congestion control mechanism is implemented at pod level that allows the system to perform the following tasks:

• Determine the pod congestion state
• Trigger Congestion Control

Determining Pod Congestion State

At any given point in time, a pod can be in any one of the following states:

1. Normal
2. DOC (Danger of Congestion)
3. Congested

Figure 3-21 Congestion states

To decide the state of a pod, the following points are taken into consideration:

1. Calculate the congestion state for the following resources:
   1. Queue: Compare the count of pending messages against the configured pending messages threshold for each congestion state (DOC, CONGESTED).
   2. CPU - The congestion state for CPU usage is calculated by comparing the CPU usage of the container (monitored using cgroup parameter - cpuacct.usage that provides current cpu usage in nano seconds) with the configured threshold. The following formula is used to calculate CPU usage:
   3. Memory - The congestion state for memory usage is calculated by comparing the memory usage of the container with the configured threshold. The following formula is used to calculate memory usage:
      

      where memory limit is monitored using memory.limit_in_bytes cgroup parameter and current memory usage is monitored using memory.usage_in_bytes cgroup parameter.

2. Based on the congestion state of resources, the congestion state for the pod is set to the maximum of congested states. The following table describes how the state of the pod is evaluated for various scenarios:

   Table 3-11 Published Pod Congestion State

   Queue	CPU	Memory	Pod
   CONGESTED	NORMAL	DOC	CONGESTED
   NORMAL	DOC	NORMAL	DOC
   DOC	DOC	Normal	DOC

3. The current published congestion state of the pod is changed to calculated congestion state only when the calculated state remains same for the configured number of continuous sample counts (100 ms by default). By doing so, events like short bursts of traffic triggering a change in the congestion state and load shedding can be avoided. The exceptions to this rule are when:
   1. Current state is NORMAL, and the calculated state is CONGESTED.
   2. Current state is CONGESTED, and the calculated state is NORMAL.

Triggering Congestion Control

Every time a message is fetched from the queue for processing, the system checks the current congestion state of the pod. If the current state is either DOC or Congested, the congestion control mechanism is triggered. After verifying that the message type is a request, a priority is assigned to it. The priority value for a request can be between 0 to 15, where 0 is the highest priority, and 15 is the lowest priority. If the assigned priority is lower than or equal to discard priority, the message is rejected.

Note:

Congestion control does not apply to response messages as they are always accepted.

Figure 3-22 Process flow for triggering congestion control

For priority based load shedding to happen, the load rule configured for current congestion state is taken into consideration. If there is no rule configured for a congestion state, the request is accepted by default. While defining load rules, the user can customize the result to reject the request. However, to reject requests from backend peers, the result code is always DIAMETER_TOO_BUSY.

Call Flow

To understand how the diameter congestion control feature works, consider a scenario where the priority rules are configured as described in the following table:

Table 3-12 Priority Rules

Message	Priority
Default	6
RAR	10

For this call flow, discard priority is set as 10 for DOC and Congested state. The resulting code for rejecting request messages is set as DIAMETER_UNABLE_TO_COMPLY, that is applicable only for external peers.

Figure 3-23 Call flow diagram for Diameter Congestion Control

• When the Diameter Gateway is in DOC or Congested state, receives a RAR request, the priority is compared against discard priority. Since both message priority and discard the priority values are the same, the message is rejected with the DIAMETER_UNABLE_TO_COMPLY result code.
• When the Diameter Gateway is in DOC or Congested state, receives AAR request, the priority is compared against discard priority. Since no priority rule is configured for this message request, the message is accepted with the DIAMETER_SUCCESS result code.

Enable

The congestion control for diameter gateway pods is a functionality supported by Binding Support Function configurations. You do not need to enable or disable this feature.

Configure

You can customize the configurations related to this feature using the CNC Console or REST APIs for BSF.

• Configure using CNC Console: Perform the feature configurations on the Load Shedding Profiles and Message Priority Profiles page. For more information about the configurations, see Diameter Configurations.
• Configure using REST API: BSF provides the following REST API for configuring diameter gateway pod congestion control feature:

  Load Shedding Profiles: {apiRoot}/oc-bsf-configuration/v1/diameter/loadsheddingprofiles

  Message Priority Profiles: {apiRoot}/oc-bsf-configuration/v1/diameter/messagepriorityprofiles

  Congestion Threshold: {apiRoot}/oc-bsf-configuration/v1/threshold/{serviceType}

  You can perform the POST, PUT, or GET operations to configure the feature. For more information about REST API configuration, see Oracle Communications Cloud Native Core Binding Support Function REST API Specification Guide.

Observe

Binding Support Function uses the pod congestion metrics for this feature. For more information, see the Binding Support Function Metrics section. Alerts are raised when the following metrics are pegged:

• pod_congestion_state
• pod_resource_congestion_state

Note:

Prometheus automatically injects name of the pod name with the label "kubernetes_pod_name" to the metric. This information is further used for alerting purposes.

Alerts

BSF uses the following congestion control alerts for this feature:

• PodDoC
• PodCongested
• PodPendingRequestDoC
• PodPendingRequestCongested
• PodCPUDoC
• PodCPUCongested
• PodMemoryDoC
• PodMemoryCongested

For more information, see the List of Alerts section.

Maintain

Warning logs are generated to indicate the congestion level. Error logs are generated when the system is congested and the actions are needed to be taken to bring the system back to normal. However, no error logs are generated when messages are rejected to avoid additional resource usage to write error logs.

3.23 Overload Control

Overload means when 100% of the planned capacity is exhausted. It can be due to uneven distribution of traffic towards a given policy service instance, network fluctuations leading to traffic bursts or unexpected high traffic volume at any given point of time.

During overload conditions, the service response times may grow to unacceptable levels, and exhaustion of resources can result in downtime or services exhibiting unexpected behavior. Overload management is a critical requirement for any telecom node, server, and service to protect against downtime and ensure serviceability during extreme overload conditions. Thus, overload management aims to prevent service performance from degrading in an uncontrolled manner under heavy loads. When BSF service starts approaching its saturation or planned limit, response times typically grow high and throughput may degrade substantially. Under such conditions, it is desirable to shed load based on the user's configuration, instead of causing all messages and signaling flows to experience unacceptable response times, failures, or downtime.

BSF allows to configure a percentage of messages to be rejected. That is, messages are discarded based on configured percentage. This enables system's overload and congestion control to manage gauge system's load with better accuracy. Also, it allows the user to provide less rejections instead of providing 100% rejections.

Percentage of message rejections for each load level is configurable. Also, the rejection percentage for each message priority can be configured.

For example, if the discard value for CCR-I messages is 50% , when system is under load, only alternate CCR-I requests are processed rejected the rest. That is, 1st CCR-I is rejected and 2nd is accepted.

Note:

All CCR-Ts are accepted.

Enable

To enable the overload control functionality, set value for the following parameter to true in the custom-values.yaml file for BSF:

• perf-info.overloadManager.enabled

Then, configure the values for the following parameters in the custom-values.yaml file:

perf-info:
  envMysqlDatabase: ''
  overloadManager:
    enabled: false
    ingressGatewaySvcName: occnp-ingress-gateway
    ingressGatewayPort: *svcIngressGatewayHttp
    # nfType is used to query configuration from common cfg server
    nfType: BSF
    # diam Gateway overload management feature configurations
    diamGWPort: *svcDiamGatewayHttp

For more information about setting the parameter values, see Overload Manager Configurations in Oracle Communications Cloud Native Core, Binding Support Function Installation, Upgrade, and Fault Recovery Guide.

Configure

You configure the overload control feature either using CNC Console, or through REST API.

• Configure using REST API: BSF provides overloadLevelThreshold and overloadLevelThresholdProfiles API end points to configure overload control feature.

  You can perform the POST, PUT, or GET operations to configure the feature. For more information about REST API configuration, see Overload Level Threshold Overload Level Threshold sections in Oracle Communications Cloud Native Core, Binding Support Function REST API Specification Guide.

• Configure using CNC Console: Using CNC Console, you can configure the threshold values based on profiles. For more information, see Overload Control Threshold.

Recommended Overload Threshold Values - BSF Management Services

This section describes the recommended default overload threshold values for BSF Management Services. To calculate threshold values, you must consider the resource values for microservices. The following table lists the default resource values for BSF Management Services:

Table 3-13 Default Resource Values

Resources	Values
CPU (Limits)	4
CPU (Requests)	3
Maximum CPU Usage	1.6
Maximum CPU Usage (%)	61
Maximum Replicas	8
Maximum TPS	1500
Maximum TPS (all replicas)	12000
Worst RTT (assumed)	250 ms
Maximum Pending Transactions	2100

Based on the values in the aforementioned table, you can calculate the onset and abatement values for load levels - L1, L2, and L3, as shown in the following table:

Table 3-14 Formulas to Calculate Default Overload Threshold Levels

Load Level	CPU (%)	Pending Message Count(Absolute Value)	Failure Couunt(Absolute Value)
L1 - Onset	80% * C	60% * P	05% * T
L1 - Abatement	75% * C	50% * P	03% * T
L2 - Onset	90% * C	75% * P	10% * T
L2 - Abatement	85% * C	70% * P	08% * T
L3 - Onset	95% * C	90% * P	15% * T
L3 - Abatement	91% * C	85% * P	12% * T

Abatement value is the lower range where as the onset value is higher range for that particular level.

Note:

C denotes the maximum CPU utilization per pod of core-service

P denotes the maximum pending transaction size value based on worst RTT and max TPS, that is, 25K/s * 2000ms = 50000.

T denotes the maximum TPS of a given service.

Note:

You can configure the memory for each of these services.

The following table lists the default overload threshold values for BSF Management Services:

Note:

These are the recommended values. It can be modified as per the customer requirements.

Table 3-15 Default Overload Threshold Values - BSF Management Services

Load Level	CPU (%)	Pending Message Count	Failure Count
L1 - Onset	44	1260	420
L1 - Abatement	41	1050	252
L2 - Onset	49	1575	840
L2 - Abatement	47	1470	672
L3 - Onset	52	1890	1260
L3 - Abatement	50	1785	1008

Observe

BSF provides the following metrics specific to Overload Control feature:

• service_resource_stress
• service_resource_overload_level
• load_level
• system_overload_threshold_config_mode
• active_overload_threshold_fetch_failed

For more information, see Binding Support Function Metrics section.

Alerts

• BSF provides the following alerts for overload control feature on SBI interface:

  • ServiceOverloaded - This alert is raised whenever a given service is in overload state - L1, L2, and L3.
  • ServiceResourceOverLoaded - This alert is raised when a given service is in overload state - L1, L2, or L3 due to resource types such as memory, CPU, pending count, and failure count.

• BSF provides PERF_INFO_ACTIVE_OVERLOAD_THRESHOLD_FETCH_FAILED alert for overload control threshold configuration. This alert is raised when the service is unable to fetch the current active overload threshold data.

Maintain

Error logs are generated when the system is overloaded and the actions taken to bring the system back to normal. Warning logs are generated to indicate the change in load level.

3.23.1 Overload Control - Diameter

For Diameter Gateway, BSF provides the following means for overload management:

• Pre-defined threshold load levels.
• Tracks number of pending and failure messages from Diameter Gateway.
• Tracks CPU and memory usage of Diameter Gateway.
• Enforce load shredding during various overload levels based on priority and percentage discard value for each priority. The priority and pecentage discard value are configurable.

Configure

To configure the threshold values, discard priority, and error codes for the defined overload control levels, you may use CNC Console as well as REST API.

Note:

Currently, threshold values can be configured using REST API only.

• Configure using CNC Console: Perform the feature configurations on the Load Shedding Profiles and Message Priority Profiles page. For more information about the configurations, see Load Shedding Profiles.
• Configure using REST API: BSF provides the following REST API for configuring Overload Control feature on Diameter Gateway:

  Load Shedding Profiles: {apiRoot}/oc-bsf-configuration/v1/diameter/loadsheddingprofiles

  Message Priority Profiles: {apiRoot}/oc-bsf-configuration/v1/diameter/messagepriorityprofiles

  You can perform the POST, PUT, or GET operations to configure the feature. For more information about REST API configuration, see Oracle Communications Cloud Native Core, Binding Support Function REST API Specification Guide.

The following are the recommended configurations for load shedding profile and message priority profile respectively for overload control:

{
  "name": "default_overload_control_load_shedding_profile",
  "type": "Overload Control",
  "overloadLoadSheddingRules": [{
    "level": "L1",
    "discardPriority": 13,
    "ansWithResultCode": "DIAMETER_TOO_BUSY"
  }, {
    "level": "L2",
    "discardPriority": 11,
    "ansWithResultCode": "DIAMETER_TOO_BUSY"
  }, {
    "level": "L3",
    "discardPriority": 6,
    "ansWithResultCode": "DIAMETER_TOO_BUSY"
  }]
}

{
  "name": "default_msg_priority_profile",
  "priorityRules": [{
    "ruleName": "Rx_AAR_I",
    "messagePriority": 13,
    "rulePriority": 1,
    "enableDRMPPriority": true,
    "conditions": {
      "application": "Rx",
      "message": "AAR",
      "preDefinedAVPConditions": [{
        "conditionName": "Rx-Request-Type",
        "conditionRxRTValue": ["INITIAL_REQUEST"]
      }]
    }
  }, {
    "ruleName": "Rx_STR",
    "messagePriority": 7,
    "rulePriority": 1,
    "enableDRMPPriority": true,
    "conditions": {
      "application": "Rx",
      "message": "STR",
      "preDefinedAVPConditions": []
    }
  }, {
    "ruleName": "Rx_AAR_U",
    "messagePriority": 11,
    "rulePriority": 1,
    "enableDRMPPriority": true,
    "conditions": {
      "application": "Rx",
      "message": "AAR",
      "preDefinedAVPConditions": [{
        "conditionName": "Rx-Request-Type",
        "conditionRxRTValue": ["UPDATE_REQUEST"]
      }]
    }
  }]
}

Observe

BSF provides the following metric specific to Overload Control feature:

• diam_overload_message_reject_total

For more information, see Binding Support Function Metrics section.

3.23.2 Overload Control - SBI

For HTTP signaling, BSF provides the following means for overload management:

• Pre-defined threshold levels
• Tracks number of pending messages for BSF service
• Tracks number of failed responses (configurable as error code) generated BSF service
• Tracks CPU and memory usage of BSF services
• Determines the overload level of the system using data collected from all the above mentioned points against planned threshold levels.
• Enforce load shedding at various overload levels

Configure

To configure the discard policies, Discard Policy mapping, and Error Code Profiles for overload control, you may use CNC Console as well as REST API.

Note:

Currently, threshold values can be configured using REST API only.

• Configure using CNC Console: Perform the feature configurations on the Discard Policy Mapping, Discard Policy, and Error Code Profiles pages. For more information about the configurations, see Overload and Congestion Control Configurations.
• Configure using REST API: BSF provides the following REST APIs for configuring overload control feature on SBI interface:

  • OC Policy Mapping: {apiRoot}/BSF/nf-common-component/v1/igw/ocpolicymapping

  • OC Discard Policies: {apiRoot}/BSF/nf-common-component/v1/igw/ocdiscardpolicies

  • Error Code Profiles: {apiRoot}/BSF/nf-common-component/v1/igw/errorcodeprofiles

  You can perform the GET, PUT, or PATCH operations to configure the feature. For more information about REST API configuration, see Oracle Communications Cloud Native Core, Binding Support Function REST API Guide.

The following are the recommended configurations for default message priority values for overload control:

Table 3-16 Default Message Priority Values

Message Type	Priority
bsf_management_register	24
bsf_management_deregister	18
bsf_management_discovery	24

3.24 Rate Limiting - SBI

With the support for rate limiting, Ingress Gateway screens all configured routes and their respective rate limit configurations. Within the configured sampling period (configurable using CNC Console and REST APIs), Ingress Gateway calculates the rate for the required route along with the HTTP method. For BSF, the following routes and HTTP methods are supported:

• BSF Management Register - POST method
• BSF Management Deregister - DELETE method
• BSF Management Discovery - GET method

Then, it notifies the route level rate limiter with the calculated rate at the end of the sampling period. If the feature is enabled, any request with the sbi-priority header value greater than the configured value is discarded, and Ingress Gateway returns the error response with configured errorCode.

Note:

Ingress Gateway determines the number of messages being dropped or rejected in the current sampling period based on extra unrejected messages received in the previous sampling period.

Managing Rate Limiting

Enable

Perform the following configurations to enable the rate limiting feature at Ingress Gateway:

• CNC Console: By default, this feature is disabled. To enable the rate limiting feature using CNC Console, set the Enable Rate Limiting parameter to true on the Rate Limiting Policy page.

• REST API: By default, this feature is disabled. To enable the rate limiting feature using REST API, set the enabled parameter to true in the following resource URI:

  Define rate limit: {apiRoot}/BSF/nf-common-component/v1/igw/routelevelratelimiting

  Define rate limit at route level: {apiRoot}/BSF/nf-common-component/v1/igw/routesconfiguration

  For more information, see Rate Limiting at Ingress Gateway section in Oracle Communications Cloud Native Core, Binding Support Function REST API Guide.

Configure

To configure the rate limiting policy, route level mapping, and error code profiles for rate limiting, you may use CNC Console as well as REST API.

• Configure using CNC Console: Perform the feature configurations on the Rate Limiting Policy, Route Level Mapping, and Error Code Profiles pages. For more information about the configurations, see Overload and Congestion Control Configurations.
• Configure using REST API: BSF provides the following REST API for configuring Overload Control feature on SBI interface:

  Define error code profiles: {apiRoot}/BSF/nf-common-component/v1/igw/errorcodeprofiles

  Define rate limit: {apiRoot}/BSF/nf-common-component/v1/igw/routelevelratelimiting

  Define rate limit at route level: {apiRoot}/BSF/nf-common-component/v1/igw/routesconfiguration

  You can perform the GET, PUT, or PATCH operations to configure the feature. For more information about REST API configuration, see Oracle Communications Cloud Native Core, Binding Support Function REST API Specification Guide.

3.25 Pod Protection at Ingress Gateway

This section describes how to protect the Ingress Gateway pods when they are overloaded with numerous incoming requests.

The Ingress Gateway pods are not protected against any incoming traffic congestion. As a result, the pods are overloaded and congested. This impacts system latency and performance. It also leads to stability issues due to uneven distribution of connections and traffic on Ingress Gateway pods. As a front end microservice for HTTP traffic, it is important for Ingress Gateway to have pod protection implemented.

To configure pod protection on Ingress Gateway, you can define threshold limit for DoC and Congested state through REST:

Table 3-17 Configuring Threshold Limit

Level	Resource
DoC	CPU Memory Pending Message
Congested	CPU Memory Pending Message

Configure

You need to perform the following configurations for pod protection feature:

• Configure using REST API: BSF provides the following REST API:

  {apiRoot}/BSF/nf-common-component/v1/igw/podprotection

  You can perform the GET, PATCH, or PUT operation to configure the feature. For more information about REST API configuration, see Oracle Communications Binding Support Function REST API Specification Guide.

3.26 Service Mesh for Intra-NF Communication

BSF leverages the Istio or Envoy service mesh (Aspen Service Mesh) for all internal and external communications. The service mesh integration provides inter-NF communication and allows API gateway co-working with service mesh. The service mesh integration supports the services by deploying a sidecar proxy in the environment to intercept all network communications between microservices.

The Aspen Service Mesh (ASM) configurations are classified into:

• Control Plane: It involves adding labels or annotations to inject sidecar.
• Data Plane: It helps in traffic management such as handling NF call flows by adding Service Entries (SE), Destination Rules (DR), Envoy Filters (EF), and other resource changes such as apiVersion change between versions. This is done manually depending on each NF requirement and ASM deployment.

Managing Service mesh for intra-NF Communication

Enable

To enable Aspen Service Mesh, configure the following parameters under nrf-client-nfdiscovery, ingress-gateway, egress-gateway, and alternate-route sections in the custom values file for BSF:

• serviceMeshCheck
• istioSidecarQuitUrl
• istioSidecarReadyUrl

For more information on enabling the parameter value, see "Aspen Service Mesh Configurations" in Cloud Native Binding Support Function Installation and Upgrade Guide.

Configure

The Aspen Service Mesh (ASM) configurations are classified into:

• Control Plane: For information on configuring the parameter value, see "Aspen Service Mesh Configurations" section in Oracle Communications Cloud Native Binding Service Function Installation Guide.
• Data Plane: For information about Data plane configurations, see "Aspen Service Mesh Data Plane Configurations" in Cloud Native Binding Support Function Installation and Upgrade Guide.

3.27 Automated Test Suite Support

BSF provides Automated Test Suite (ATS) for validating the functionalities. ATS allows you to run BSF test cases using an automated testing tool and compares the actual results with the expected or predicted results. The ATS requires no user intervention. For more information, see Oracle Communications Cloud Native Core Automated Testing Suite Guide.

3.28 SBI Error Codes

Oracle Communications Cloud Native Core Binding Support Function (BSF) can handle Protocol or Application errors and a few other additional defined errors for various scenarios. When BSF encounters an error in processing a request, it sends error codes in the response message to the request. With this enhanced functionality, BSF allows users to configure error codes by adding customized values, for a defined condition, for the following fields:

• Error Description
• HTTP Status Code
• Application Error Code

Configure

To configure error codes for BSF, users can use any of the following ways:

• CNC Console: Perform the configurations on the SBI Error Codes page. For more information, see SBI Error Codes Configurations.
• REST API: Perform the configurations using POST, PUT, or GET operations. For more information about REST API configuration, see Oracle Communications Cloud Native Core, Binding Support Function REST Specification Document.

Observe

When BSF generates error codes, it also increments the associated metric, ocbsf_ingress_response_total. To support the SBI error codes feature, a new dimension, application_error_code is added to the metrics to enable the user to easily identify the failed message or procedure and the associated error code. Metrics also include the consumer (IP or FQDN) to whom the error would be sent. For more details, see Binding Support Function Metrics.

On generating error codes, logs are updated as well.

The following is a sample error log when optional parameter in binding data is invalid:

{
  "instant": {
    "epochSecond": 1628086282,
    "nanoOfSecond": 772064777
  },
  "thread": "XNIO-1 task-1",
  "level": "DEBUG",
  "loggerName": "ocpm.bsf.api.management.metrics.BsfMetrics",
  "message": "Pegging the Ingress Response Metric for Operation Type : register, Response Code ProblemDetails [type=about:blank, title=Optional parameter in binding data is invalid, status=411, cause=OptionalInformationElementIsIncorrect, instance=http://b-ocbsf-ingress-gateway.b/nbsf-management/v1/pcfBindings, details=Parameters in the request is not correct , invalidParams=[InvalidParam {\n    param: pcfDiamRealm\n    reason: must match \"^([A-Za-z0-9]+([-A-Za-z0-9]+)\\.)+[a-z]{2,}$\"\n}]]",
  "endOfBatch": false,
  "loggerFqcn": "org.apache.logging.slf4j.Log4jLogger",
  "threadId": 31,
  "threadPriority": 5,
  "messageTimestamp": "2021-08-04T14:11:22.772+0000"
}

Result: As mentioned in the message field of the sample log, the metric ocbsf_ingress_response_total is pegged.

3.29 Handling Stale Session in BSF

Overview

A session binding on BSF is considered as stale when the PCF binding is successfully registered on BSF but has no corresponding session on PCF. When you enable stale session handling feature, the Audit service detects stale sessions automatically at regular intervals.

During the audit, if the audit service finds records with a binding age greater than the configured value (default value is 3600 minutes), it marks such records as suspected stale and initiates a request to notify the BSF management service. Depending on the feature configurations, BSF may query PCF to confirm if the pcfBinding records are stale. If PCF confirms the record as stale, then BSF removes it from its local database. However, if PCF sends 2xx in the response, then BSF updates the last access time for the associated pcfBinding record.

If the audit service finds a pcfBinding record with binding age greater than the maximum binding age (default value is 7200 minutes), it notifies the BSF Management service. On receiving the notification, BSF deletes the specified record from its database.

For georedundant BSF deployments, binding records are replicated to other redundant sites after the audit cycle is complete. Logs are published when audit service detects and removes stale sessions.

Query PCF to confirm a record as stale

To query PCF for confirming stale pcfBinding records, BSF supports receiving vendor-specific-attribute in the binding register request. So, when PCF sends a register request to BSF for binding creation, it includes the notification URL in the vendor-specific-attribute, as shown below:

"vendorSpecific-000111": {
    "version": 1,
    "notificationUrl": "<PCF Notification Url>",
    "createBindingTime": "<Timestamp>",
  }

BSF, in turn, uses this notification URI to send audit notification towards Binding service on PCF. When PCF receives the notification, it checks whether any binding record exists by sending a query to the Query service using contextId (SmPolicyAssociationId). Based on the findings, PCF sends 2xx response if session exists and 404 if the session does not exist.

Enable

After performing the required Helm configurations, you can enable the handling stale sessions in BSF using the CNC Console or REST API.

• Enable using Helm: To enable this feature during BSF deployment, set the value of auditServiceEnable parameter as true in the ocbsf-22.2.0-custom-values.yaml file. Once the Audit service is enabled, set appropriate values for the following parameters:
  • global.servicePorts.auditServiceHttp
  • global.containerPorts.auditServiceHttp
  • audit-service.envMysqlDatabase

  For more information on how to customize these parameters, see Oracle Communications Cloud Native Core Binding Support Function Installation and Upgrade Guide.

• Enable using CNC Console: To enable this feature, on the Management Service page, under the Audit group, set the value of Enabled field as true. For more information about enabling the feature through CNC Console, see Service Configurations.

• Enable using REST API: Set the audit.enable parameter value to true in the Management Service configuration API. For more information about enabling the feature through REST API, see the "Management Service" section in Oracle Communications Core Binding Support Function REST Specification Guide.

Configure

You can configure the Stale Session Handling functionality for BSF using the CNC Console or REST API.

• Configure using CNC Console: Perform the feature configurations on the Management Service page. For more information, see Service Configurations.
• Configure using REST API: BSF provides the following REST API for Stale Session Handling configuration:

  API: {apiRoot}/oc-bsf-configuration/v1/services/managementservice

  You can perform the GET and PUT operations to configure this feature. For more information about REST API configuration, see the "Management Service" section in Oracle Communications Core Binding Support Function REST Specification Guide.

Observe

BSF provides the following metrics for stale session handling feature:

• ocbsf_audit_notif_request_count_total
• ocbsf_audit_notif_response_count_total
• ocbsf_audit_delete_records_count_total
• ocbsf_diamgw_notification_request_count_total
• ocbsf_diamgw_notification_response_count_total
• ocbsf_query_request_count_total
• ocbsf_query_response_count_total
• ocbsf_bindingQuery_request_total
• ocbsf_bindingQuery_response_total
• ocbsf_bindingDelete_request_total
• ocbsf_bindingDelete_response_total

For more information, see the BSF Management service and Audit service metrics in the Binding Support Function Metrics section.

Maintain

BSF generates logs when audit service detects and removes stale sessions automatically. In addition, logs are printed for query requests towards PCF and the associated responses.

3.30 Support Multiple Cluster Deployment at CNC Console

The CNC Console supports both single and multiple cluster deployments.

In a single cluster deployment, the CNC Console can manage NFs and Oracle Communications Cloud Native Core, Cloud Native Environment (CNE) common services deployed in the local Kubernetes clusters.

In a multiple instances deployment, the CNC Console can manage multiple BSF instances and CNE common services deployed within a Kubernetes cluster. For more information about single and multiple cluster deployments, see Oracle Communications Cloud Native Core, Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide.

The following image represents a Kubernetes cluster with one instance of CNC Console and two instances of BSF. The single instance of the CNC Console is configuring two instances of BSF with different namespaces.

Figure 3-24 Support for Multiple Instance Deployment

With the support of multicluster deployment, BSF deployed in multiple Kubernetes clusters can be accessed using CNC Console. In a multicluster deployment, the CNC Console can manage BSF and OCCNE common services deployed in the remote Kubernetes clusters.

The following image represents multiple Kubernetes clusters with one CNC Console and two BSF deployments. The single instance of CNC Console is configuring two instances of BSF with different namespaces deployed in different clusters.

Figure 3-25 Support for Multicluster Deployment

3.31 Support for 3GPP NF Sets and Binding Headers

Oracle Communications Cloud Native Core Binding Support Function supports the 3GPP NF Sets and Binding Headers in Model-B (Direct communication) and Model-C (Indirect communication). Using this feature, BSF can construct and send a binding header in the response messages to PCF for successful call processing.

Note:

Since BSF is a producer NF, it does not send any notifications to consumer NFs. BSF sends an HTTP request message only to NRF for management purpose.

NF Set: NF set is a group of interchangeable NF instances supporting similar services and network slices. In an NF set, the NF instances can be geographically distributed, but have access to the same context data. The NF instances can be deployed in such a pattern so that several instances are present within an NF set to provide distribution, redundancy, and scalability as a set. The NF instances of an NF set are equivalent and share the same MCC, MNC, NID (for SNPN), NF type, and NF Set ID.

Binding Headers: The Binding headers indicate the suitable target NF producer instance for NF service instance selection, reselection, and routing of subsequent requests associated with a specific NF producer resource or context. It allows the NF producer to indicate that the NF consumer, for a particular context, should be bound to an NF service instance, or NF set depending on local policies. Binding can also be used by the NF consumer to indicate the suitable NF consumer instances for notification target instance reselection and routing of subsequent notification requests, associated with a specific notification subscription.

BSF supports the following binding header as defined in 3GPP:

Table 3-18 Supported Headers

Header Name

Description

3gpp-Sbi-Binding

This header is used to communicate the binding information from an HTTP server for storage and subsequent use by an HTTP client. This header contains a comma-delimited list of Binding Indications from an HTTP server for storage and use of HTTP clients. The absence of this parameter in a Binding Indication in a service request is interpreted as "callback". Note: In the current release, the following are not supported: Binding levels – nfservice-instance and nfservice-set Attributes – recoverytime and notif-receiver

Binding Support Function supports the NF Set and Binding Header functionality in all SBI interfaces.

Example

The following diagram depicts an example where communication between PCF and BSF Management service takes place:

Figure 3-26 Example of NF Set and Binding Header in BSF

The above call flow diagram describes a scenario where PCF sends a request to register PcfBindings towards the BSF Management service through Ingress Gateway. The register request does not contain a 3gpp-sbi-binding header.

Once the request is received at BSF, the BSF Management service adds 3gpp-sbi-binding to the response and sends it back to the PCF with HTTP status code 201.

If the user does not want to add a binding header to response messages, then it can be configured through CNC Console or REST APIs for BSF.

Managing NF Sets and Binding Header Support

Enable and Configure

The NF Sets and Binding header support can be enabled and configured for the BSF Management service interface using any of the following two ways:

• Using CNC Console: Perform the feature configurations on the Management Service page. For more information about the configurations, see Service Configurations.
• Using REST API: BSF provides the following REST API for NF Sets and Binding Headers configuration:

  API: {apiRoot}/oc-bsf-configuration/v1/services/managementservice

  You can perform the GET and PUT operations to configure this feature. For more information about REST API configuration, see the "Management Service" section in Oracle Communications Cloud Native Core Binding Support Function REST Specification Guide.

Observe

BSF uses the Ingress metrics to contain information about the NF bindings used by PCF. The following metrics contains the information about NF bindings used by PCF:

• ocpm_ingress_request_total with the new dimensions – pcf_id and pcf_set_id

  Note:

  The dimensions are populated only for Nbsf_Management_Register requests.
• ocpm_ingress_response_total with the new dimensions – binding_level and binding_id

For more information, see the Binding Support Function Metrics section.

Maintain

The BSF logs include the NF binding information sent by BSF. The logs include information about the following headers:

• location
• 3gpp-sbi-binding

The following is a sample log for PCF binding register request:

{
  "instant": {
    "epochSecond": 1636550691,
    "nanoOfSecond": 280882458
  },
  "thread": "XNIO-1 task-1",
  "level": "DEBUG",
  "loggerName": "ocpm.bsf.api.management.controller.BindingSupportManagementServiceAPIController",
  "message": "PCF binding: PcfBinding [supi=imsi-411411000000011, gpsi=5084948001, ipv4Addr=10.10.10.16, ipv6Prefix=null, ipDomain=null, macAddr48=null, dnn=internet, pcfFqdn=pcf-smservice.oracle.com, pcfIpEndPoints=null, pcfDiamHost=pcf-smservice.oracle.com, pcfDiamRealm=oracle.com, snssai=Snssai [sst=11, sd=abc123], pcfId=fe7d992b-0541-4c7d-ab84-c6d70b1b0123, pcfSetId=setxyz.pcfset.5gc.mnc015.mcc345, bindLevel=NF_SET]",
  "endOfBatch": false,
  "loggerFqcn": "org.apache.logging.slf4j.Log4jLogger",
  "threadId": 45,
  "threadPriority": 5,
  "messageTimestamp": "2021-11-10T13:24:51.280+0000"
}

3.32 Support for User-Agent Header

User-Agent header helps the producer Network Function (NF) to identify the consumer NF that has sent the request. To implement this, 3GPP introduced the use of User-Agent header for consumers to include the same in service requests. Additionally, producers may require to support the validation of the User-Agent headers to complete the request identification process in the network.

With the integration of this feature, User-Agent header helps the producer Network Function (NF) to identify the consumer NF that has sent the request.

The following format is used to generate User-Agent header:

<NF Type>-<Instance-Id> <FQDN>

where, <NF Type> is the type of the Network Function.

<Instance-Id is the instance ID of the NF.

<FQDN> is the FQDN of the NF.

Example: BSF-54804518-4191-46b3-955c-ac631f953ed8 bsf1.east.5gc.mnc012.mcc234.3gppnetwork.org 

Following validations are made once the feature is enabled:

• If the user-agent header is present, then it is matched with the configured NF types. If a match is found, then validation is successful and request is allowed to pass. If a match is not found, then request is rejected with a configurable error code.
• If the user-agent header is present and has multiple values, then the request is rejected with a configurable error code. Hence, the user-agent header, if present should have a single value.
• If the user-agent header is not present and validationType is relaxed, then validation is not made and request is allowed to pass. If validationType is strict, then request will be rejected with a configurable error code.

Managing Support for User-Agent Header in Ingress Gateway

Enable

You can enable the User-Agent Header feature using REST or Helm configuration.

• Helm: Set the value of the parameter userAgentHeaderValidationConfigMode to Helm in the custom-values.yaml file. For more information, see the Oracle Communications Cloud Native Core Binding Support Function Installation and Upgrade Guide.
• REST API: Set the value of the parameter userAgentHeaderValidationConfigMode to REST in the custom-values.yaml file. REST configuration from the JSON bodies sent to path: "/bsf/nf-common-component/v1/igw/useragentheadervalidation" is stored in a database under the common_config table. For more information, see the Oracle Communications Cloud Native Core Binding Support Function REST Specification Guide.

Configure

You can configure the User-Agent Header using REST or Helm.

To configure User-Agent header at Ingress Gateway using Helm, you need to perform the configurations:

#User-Agent header validator configuration
#Mode of configuration. Can be either HELM or REST
userAgentHeaderValidationConfigMode: HELM
userAgentHeaderValidation:
  enabled: true
# If User-Agent header is not present or it's value is null in the incoming request then 
validation type can be used to skip or perform validation. If set to strict then validation will be performed.
# If set to relaxed then validation will be skipped.
 validationType: relaxed
# List of consumer NF Types to be matched against the value of User-Agent header in the request
 consumerNfTypes:
   - "SMF"
   - "AMF"
   - "UDR"
      ...

To configure the User-Agent header at Ingress Gateway using REST API, see user-Agent Header in Oracle Communications Cloud Native Core Binding Support Function REST Specification Guide.

Managing Support for User-Agent Header in Egress Gateway

Enable

You can enable the User-Agent Header feature using REST or Helm configuration.

• Helm: Set the value of the parameter userAgentHeaderConfigMode to Helm in the custom-values.yaml file. For more information, see the Oracle Communications Cloud Native Core Binding Support Function Installation and Upgrade Guide.
• REST API: Set the value of the parameter userAgentHeaderConfigMode to REST in the custom-values.yaml file. REST configuration from the JSON bodies sent to path: "/bsf/nf-common-component/v1/egw/useragentheader" is stored in a database under the common_config table. For more information, see the Oracle Communications Cloud Native Core Binding Support Function REST Specification Guide.

Configure

You can configure the User-Agent Header using REST or Helm.

To configure User-Agent header at Egress Gateway using Helm, you need to perform the configurations:

userAgentHeaderConfigMode: HELM
userAgentHeader:
  enabled: false # flag to enable or disable the feature
  nfType: "PCF" # NF type of consumer NF
  nfInstanceId: "2d8e8e68-24ad-11ed-861d-0242ac120002" # NF type of consumer NF
  addFqdnToHeader: true # Flag to add fqdn. If enabled then user-agent header will be 
generated along with the fqdn configured otherwise fqdn will not be added
  nfFqdn: "oracle1.pcf.pacific.org" #fqdn of NF. This is not the fqdn of gateway
  overwriteHeader: true

oauthClient:
  enabled: false
  nfInstanceId: fe7d992b-0541-4c7d-ab84-c6d70b1b01b1
  nfType: PCF

To configure the User-Agent header at Egress Gateway using REST API, see user-Agent Header in Oracle Communications Cloud Native Core Binding Support Function REST Specification Guide.

Observe

BSF provides the following metric specific to User-Agent Header feature:

• oc.ingressgateway.http.requests

For more information, see User-Agent Header Metrics section.

3.33 Support for Active Sessions Counter

Active sessions are the unique PCF binding sessions in every BSF instance.

Note:

The active sessions count also includes stale sessions until BSF removes it from its local database.

For more details on how stale sessions are handled, see Handling Stale Session in BSF.

Figure 3-27 Retrieving Active Sessions Count

The Audit-Service periodically counts the simultaneous unique active sessions, over a configurable period of time. The default value of the time period is set to 15 mins. The time period can be configured to any value between 1 to 60 minutes.

The bsf-mgt-svc requests the Audit-Service to count active sessions for configurable time period. The Audit-Service periodically finds active sessions count and publishes the count as a metric.

To get the instantaneous value of active sessions count, you can query the CM service, which internally calls Audit-Service to fetch the value.

Figure 3-28 Active Sessions Count

Note:

The audit registration process is used to register for audit registration as well as to enable active sessions counting.

The bsf-mgt-svc sends an audit registration request to the Audit-Service.

If the registration is successful, the Audit-Service responds with a 200 OK message.

If the registration fails due to any issue with the request, the Audit-Service responds with a Bad Request - 400 message.

If the registration fails due to any other internal reason while processing the request, the Audit-Service responds with an Internal Server Error - 500 message.

Note:

Audit registration is not required for CM Service to query the instantaneous active sessions count.

Once the registration is successful, the Audit-Service periodically finds active sessions count and publishes the count as a metric.

Figure 3-29 Get Instantaneous Active Sessions Count - Successful

The CM Service sends a Get maximum active sessions count request to Audit-Service.

If the CM Service call to Audit-Service is successful, it responds with a 200 OK message.

Figure 3-30 Get Instantaneous Active Sessions Count - Failure

If the CM Service call to Audit-Service fails, it responds with a 404 message.

ENABLE

You can enable the Active Sessions Counter feature using CNC Console or REST API.

• Using CNC Console: Set the value of Count Active Sessions parameter to true on Active Sessions Counting page. For more details, see Active Sessions Count under Service Configurations section.

• Using REST API: BSF provides the following REST API for Active Sessions Counter configuration:

  API: {apiRoot}/oc-bsf-configuration/v1/services/managementservice

  You can perform the GET and PUT operations to configure this feature.

  To enable the feature, set the value of activeSessionCounting.countRecords parameter to true.

  For more details, see BSF REST Specifications section in Oracle Communications Cloud Native Core Binding Support Function REST Specification Guide.

For more information, see Active Session Query.

Configure

You can configure the Active Sessions Counter feature using CNC Console or REST API.

• Using CNC Console: Set the value of Session Count Interval (in minutes) parameter on Active Sessions Counting page. You can set the time interval to any value between 1 to 60 minutes. For more details, see Active Sessions Count under Service Configurations section.

  For instantaneous query, use the Active Session Query tab under Status and Query in CNC Console.

  For more information, see Active Session Query.

• Using REST API: BSF provides the following REST API for Active Sessions Counter configuration:

  API: {apiRoot}/oc-bsf-configuration/v1/services/managementservice

  You can perform the GET and PUT operations to configure this feature.

  To configure the feature, set the value of activeSessionCounting.countRecordsInterval parameter.

  For instantaneous query, BSF provides the following REST API:

  API: {apiRoot}/oc-bsf-configuration/v1/activeSessionCount/pcfBindings

  You can perform the GET operation to retrieve the instantaneous active sessions count.

  For more details, see BSF REST Specifications section in Oracle Communications Cloud Native Core Binding Support Function REST Specification Guide.

Observe

BSF provides the following metric specific to Active Sessions Counter feature:

• oc_db_active_session_count
• inbound_requests_total

For more information, see Active Sessions Count Metrics.

3.34 Controlled Shutdown of an Instance

CNC BSF supports controlled shutdown feature to provide the partial or complete isolation of the site from the network so that the operator can perform necessary recovery procedures when required. It helps the operator to perform the recovery procedures as per the requirement.

The site isolation is achieved by shutting down the load at gateways (Ingress Gateway, Egress Gateway, and Diameter Gateway) and updating the NF status as SUSPENDED at NRF.

Operational State

The site can be in one of the three possible operational states NORMAL, PARTIAL SHUTDOWN, or COMPLETE SHUTDOWN. The operational state can move to any of the states from the current state, there is no definitive order of state change. Currently, the operational state is stored in the common config server of the Ingress Gateway. It is read by Ingress Gateway, Egress Gateway, Diameter Gateway, and App-info periodically and action is triggered based on the current state.

Note:

Since the operational state is stored in config server, the service instances will detect the state change after the config refresh is done. If the config refresh interval is set as 5 seconds, then the pods may recognize the operational state change after 5 seconds.

The operational state can be modified through CNC Console or REST API. Operation state configuration stored in the common config server will be read by the following services:

• Ingress Gateway
• Egress Gateway
• Diameter Gateway
• App-info

Note:

If the Disaster Recovery procedure is performed when the config backup was taken when the system was in PARTIAL or COMPLETE SHUTDOWN state, then manual intervention may be required to change the operational state back to NORMAL state.

Load Control

Gateways enforce load control when the system is in a PARTIAL or COMPLETE shutdown state. The level of load control varies based on the shutdown state. When in a PARTIAL shutdown state, no new session establishments are allowed so session creation messages will be rejected (with configured error code) in this state. When in complete shutdown, no messages are allowed.

Note:

When the system is in COMPLETE SHUTDOWN state, audit service triggered notification or diameter messages will be rejected at respective gateways.

Call Flow for Daimeter Gateway

NORMAL State: If the Controlled shutdown operational state is NORMAL, then the Diameter Gateway processes the message as normal.

PARTIAL SHUTDOWN: If the controlled shutdown operational state is PARTIAL SHUTDOWN, then the Diameter Gateway accepts only in-session messages and rejects all CCR-I and AAR-I messages.

COMPLETE SHUTDOWN: If the controlled shutdown operational state is COMPLETE SHUTDOWN, then the Diameter Gateway accepts only in-session messages and rejects all messages.

Call Flow for Egress Gateway

NORMAL State: If the Controlled shutdown operational state is NORMAL, then the Egress Gateway processes the message as normal.

PARTIAL SHUTDOWN: If the controlled shutdown operational state is PARTIAL SHUTDOWN, then the Egress Gateway processes the message as normal.

COMPLETE SHUTDOWN: If the controlled shutdown operational state is COMPLETE SHUTDOWN, then the Egress Gateway processes the request as follows:

• Forward all requests received from NRF Client.
• Reject all requests received from any other services like UDR Connector, SM Service, AM Service, UE Service, and CHF Connector.

Call Flow for Ingress Gateway

NORMAL State: If the Controlled shutdown operational state is NORMAL, then the Ingress Gateway processes the message as normal.

PARTIAL SHUTDOWN: If the controlled shutdown operational state is PARTIAL SHUTDOWN, then the Ingress Gateway accepts only in-session messages and rejects all SM-Create requests.

COMPLETE SHUTDOWN: If the controlled shutdown operational state is COMPLETE SHUTDOWN, then the Ingress Gateway rejects all incoming requests.

Managing Controlled Shutdown of an instance

Enable

You can enable or disable the Controlled Shutdown feature by using the enableControlledShutdown parameter in the custom.yaml file. This parameter is set as false by default. You can enable it by setting its value as true. For more information, see Controlled Shutdown Configurations section in the Oracle Communications Cloud Native Binding Support Function Installation and Upgrade Guide.

Configure

Diameter Gateway and Ingress Gateway can be configured through CNC Console. For more information, see Controlled Shutdown Configurations.

Egress Gateway routes configuration for controlled shutdown is done through Helm. For more information, see the Controlled Shutdown Configurations section in the Oracle Communications Cloud Native Core Binding Support Function Installation and Upgrade Guide.

Observe

Metrics

CNC BSF provides the following metrics specific to controlled shutdown feature:

• system_operational_state

  For more information, see CM Service Metrics.

• diam_controlled_shutdown_message_reject_total

  For more information, see Diameter Gateway Metrics.

Alerts

CNC BSF provides the following alerts for controlled shutdown feature:

• SYSTEM_IMPAIRMENT_MAJOR
• SYSTEM_IMPAIRMENT_CRITICAL
• SYSTEM_OPERATIONAL_STATE_NORMAL
• SYSTEM_OPERATIONAL_STATE_PARTIAL_SHUTDOWN
• SYSTEM_OPERATIONAL_STATE_COMPLETE_SHUTDOWN

For more information, see BSF Alerts.

3.35 Graceful Termination of Kubernetes Pods

This feature is to support BSF NF's Kubernetes pods to terminate gracefully to reduce traffic loss.

In Kubernetes cluster, pods can get deleted due to various events. Few problems that can arise with abnormal termination:

1. A pod that is currently in the middle of processing a request is removed, leads to incomplete processing.
2. Kubernetes routes traffic to pods that have already been deleted, resulting in stale session at local or peer user.
3. The corruption of data in cache or database.

BSF services handles graceful termination of HTTP2 connections by

• accepting new request, but sends an immediate 503 service unavailable response to the clients.
• wait for ongoing response messages to complete the session.
• terminate the TCP connections and any DB transactions gracefully.

The applications performs all the above tasks before termination of the pod or before the grace period expires. If the grace period expires, and the process hasn't gracefully shutdown, the container runtime will force kill, stopping the pod immediately.

Note:

Diameter gateway service handles graceful termination of "Disconnect-Peer-Request" and "Disconnect-Peer-Answer" along with HTTP2 connections.

The grace period is configurable in the custom-values.yaml file, the default value is set at 30 seconds. Here is a sample configuration for graceful shutdown parameters in custom-values.yaml file:

bsf-management-service:
    gracefulShutdown:
        gracePeriod: 30s		
config-server:
    gracefulShutdown:
        gracePeriod: 30s

BSF Services that support Kubernetes graceful shutdown:

• BSF Management Services
• Config Server
• CM service
• Audit service
• Query service
• Diameter Gateway
• AppInfo service
• PerfInfo service
• Ingress Gateway
• Egress Gateway
• NRF client service

For more information on setting the gracePeriod value for different BSF services, see section "Customizing Binding Support Function" in Oracle Communications Cloud Native Core Binding Support Function Installation and Upgrade Guide.

3.36 NF Scoring for a Site

The NF Scoring feature calculates the score for a site based on Network Function (NF) specific factors such as metrics, alerts, etc. The NF Scoring feature helps the operator to determine the health of a site as compared to other sites. Comparing the NF scores within or across the sites helps the customers to choose the site.

One of the use cases is the Controlled Shutdown feature that allows the operator to partially or completely isolate the site. The NF Scoring feature helps the operators to choose which site to partially or completely isolate based on NF scoring.

App-Info service queries and calculates NF-Score as it has the site information.

App Info Scoring Mechanism:

App Info reads the configurations from the common config server to check if NF Scoring functionality is enabled or not. It works in the following ways:

• Continuous NF Score Calculation: When the NF Scoring feature is enabled, app info periodically reads the configurations to calculate the score.
• On-Demand NF Score Calculation: When the NF Scoring feature is enabled, app info fetches all the factors or criteria to calculate the NF Score. It is real-time fetching of factors and then the NF score is calculated on demand.

Table 3-19 NF Scoring Criteria

Factors	Default Score	Formula to calculate Factor Score	Details
TPS	20	min(Current-TPS / Max-TPS * Max- TPS-Score, Max- TPS-Score)	Current-TPS = IGW + EGW + Diameter Ingress + Diameter Egress Max-TPS specifies the maximum TPS. Max- TPS-Score Specifies the maximum score of the TPS.
Service	30	A / N * Max-SVC-Score	A = Number of available services N = Number of configured services Max-SVC-Score Specifies the maximum score of the Service Health.
Connection	20	min(Conn-Current / Conn-Total * Conn-Score, Conn-Score)	Conn-current specifies the number of connections from network to Policy. Conn-Total specifies the total number of connections expected from network to Policy. Conn-Score specifies the score for the connection.
Replication-health	30	min(Site-Current / Site-Total * Site-Score, Site-Score)	Site-Total specifies the total number of possible replication links. Site-Current specifies the available active healthy links. Replication-health Score specifies the score for the replication-health.
Locality-Preference	5	NA	The value of Locality-Preference is added for NF score calculation.
Critical-Alerts	2	CrN * Configured-Score	CrN is the Number of active critical alarms. Configured-Score-Critical-Alerts specifies the score configured by the user.
Major-Alerts	1	MaN * Configured-Score	MaN is the Number of active Major alarms. Configured-Score-Major-Alerts specifies the score configured by the user.
Minor-Alerts	0	MiN * Configured-Score	MiN is the Number of active Minor alarms. Configured-Score-Minor-Alerts specifies the score configured by the user.

Formula for NF scoring of a site: Sum of TPS-Score, SVC-Score, Conn-Score, Replication-health, and Locality-Preference score subtracted by Alerts scores.

Call Flows

This section describes examples of the call flows for the NF Scoring feature:

Figure 3-31 Call flow to Save Configuration Data

The operator sends a request to save the configuration is sent to the CM service. It saves the configuration data to the common config database. App-Info reads the configuration data and returns the acknowledgment.

Figure 3-32 Call flow to Get the NF Score

The operator sends a request to CM service to get the score. CM service requests it to App-Info. App-Info queries and calculates NF-Score.

Managing Controlled Shutdown of an instance

Enable

You can enable this feature by selecting the Enable NF Scoring field in the Settings page of NF Scoring.

For more information about enabling the feature through CNC Console, see NF Scoring Configurations.

Configure

The NF Scoring feature can be configured through CNC Console. For more information, see NF Scoring Configurations.

Note:

You can configure the env variable, NF_SCORING_INTERVAL, in deployment of app-info. Default value is 30 seconds (changing the env variable would result into restart of app-info pod).

Observe

Metrics

BSF provides the following metrics specific to NF Scoring feature:

• nfscore
• nfScoringFactorActualValue

For more information, see AppInfo Metrics .

3.37 NRF Client Retry and Health Check

With the alternate route retry feature, Policy can attempt service requests to an alternate secondary Network Repository Function (NRF) when the primary NRF throws errors. In addition, the health status check feature actively monitors the health of the NRFs and provides the list of the healthy NRFs for session requests only. The NRF client also provides the health information of NRFs to other services if requested, and notifies any change in the health status.

For a given service request, the NRF client initiates a request towards a healthy and the highest priority NRF. If the NRF client receives a failure response for the request or the request timed-out, it attempts to send the request to the same NRF for NrfRetryConfig.primaryNrfRetryCount number of times. If a success response is received before the retry count gets exhausted, NRF client accepts the response and does not send any further service requests. However, if NRF client fails to receive a success response, it attempts to send the service request to an alternate NRF. The alternate NRF is selected based on the assigned priority and health status.

If the NRF Client receives a retryAfterTime value in the response header from the NRF, the NRF Client halts any further attempts to the NRF and flags the NRF as unhealthy for the specified time period. The NRF client retries the service request to alternate NRFs until any one of the following conditions are met:

• NRF-client receives a success response.
• NrfRetryConfig.alternateNRFRetryCount is exhausted.
• All attempts to available healthy NRFs are exhausted.

Once any of the listed conditions are met, NRF-client accepts the response and proceed.

NRF Client marks NRF as unhealthy under the following conditions:

• If the NRF Client receives a retryAfterTime value in the response header from the NRF, then NRF will be unhealthy for a time period as defined in retryAfterTime.
• If the status code received is available in the default values for errorCodeReasonsForFailure, then NRF will be unhealthy for a period of time as defined in ConfigMap.data: profile.retryAfterTime.
• If the status code received is available in the default values for errorCodeReasonsForFailure and all the retry attempts are exhausted.
• If NRF Client receives an error from Gateway service and the error is configured in the gatewayErrorCodes with all the exhausted retry attempts.

Note:

• If NRF Client receives an error from Gateway service and the error is not configured in the gatewayErrorCodes, then NRF remains marked as healthy.
• HealthCheckConfig and NRFRetryConfig must be configured for the NRF Client functionality to work as expected.
• NRF Client considers a response as failure only when it is configured in the errorReasonsForFailure parameter in the custom-values.yaml file. The primary and non-primary NRFs must be geo-redundant for the NRF Retry mechanism to work.
• For autonomous procedures such as NfRegistration and NfHeartbeat, NRF-client continues to retry sending service requests till a success response is received.

  For details on NRF Client configuration parameters, see NRF Client Configuration section in Oracle Communications Cloud Native Core, Converged Binding Support Function Installation, Upgrade and Fault Recovery Guide.

3.38 BSF Message Feed for Monitoring

In order to enable correlation of the internal and external (request/response) messages for all the transactions initiated by the producer and consumer NFs, BSF supports copying the messages at Ingress and Egress Gateways.

This feature allows NFs using Ingress and Egress Gateways to report every incoming and outgoing message to Oracle Communications Network Analytics Data Director (OCNADD) monitoring system.

That is, OCNADD is a message store to keep a copy of each request and response processed through IGW & EGW.

The insights on these messages enable NFs to integrate with external 5G SBI monitoring system for:

• Call Tracing / Tracking
• Live debugging

Architecture

Figure 3-33 BSF Message Feed Architeture

OCNADD is a Network Data Broker part of the Network Analytics suite of products. OCNADD receives network data traffic information from various sources such as 5G NFs and Non-5G Nodes and sends the data securely to subscribed consumer (3rd Party tools) after applying its powerful and configurable filtering, replication, and aggregation rule corresponding to subscribed consumers. For more information on OCNADD, see Oracle Communications Network Analytics Data Director User Guide.

5G NF Kafka Producer is used as the source to send the data stream towards OCNADD. The 5G NFs use integrated Kafka producer services to stream the 5G South Bound Interface (SBI) messages along with metadata added by NFs to OCNADD.

Managing BSF Message Feed

Enable

BSF Message Feed feature can be enabled using Helm parameters either at the time of BSF installation or during the software upgrade.

ingress-gateway.message-copy.enabled parameter is used to enable copying messages passing through Ingress Gateway.

egress-gateway.message-copy.enabled parameter is used to enable copying messages passing through Egress Gateway.

For more information, see Configuring Ingress Gateway, Configuring Egress Gateway, and Configuring Kafka for NF Message Feed sections in Oracle Communications Cloud Native Core, Binding Support Function Installation, Upgrade, and Fault Recovery Guide.

Configure

BSF Message Feed feature can be configured using Helm parameters either at the time of BSF installation or during the software upgrade.

For more information, see Configuring Ingress Gateway, Configuring Egress Gateway, and Configuring Kafka for NF Message Feed sections in Oracle Communications Cloud Native Core, Binding Support Function Installation, Upgrade, and Fault Recovery Guide.

SASL_SSL Configuration for BSF Message Copy

As there is no certificate-based client authentication required, a trustStore is created at BSF.

BSF contains placeholders to accept caroot certificates, which are then translated into trustStore using Gateway init-containers.

BSF uses native SSL functionality provided by Gateway services. SSL service block gets activated or used, when enableIncomingHttps is set to true. The same configuration is used for message copy SSL configuration too.

To configure only BSF-DD SSL communication without native SSL functionality, configure caBundle and trustStorePassword sections with appropriate secret configurations.

To use both native SSL functionality and BSF-DD SSL communication, add the caRoot certificate of Kafka broker to the existing caRoot certificate by appending Kafka broker ca certificate after the existing certificate.

1. Generate SSL certificates.

   Note:

   Creation process for private keys, certificates and passwords is based on discretion of user or operator.
2. Before copying the certificates to the secret, add the DD Root certificates contents into the CA certificate(caroot.cer) generated for NRF.

   Note:

   Make sure to add 8 hyphens "-" between 2 certificates.

   -----BEGIN CERTIFICATE-----
   <existing caroot-certificate content>
   -----END CERTIFICATE-----
   --------
   -----BEGIN CERTIFICATE-----
   <DD caroot-certificate content>
   -----END CERTIFICATE-----

3. Create a secret for authentication with DD.

   To create a secret store the password in a text file and use the same file to create a new secret.

   kubectl create secret generic ocingress-secret --from-file=ssl_ecdsa_private_key.pem --from-file=rsa_private_key_pkcs1.pem --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer --from-file=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt --from-file=sasl.txt -n <namespace>
   
   kubectl create secret generic ocegress-secret --from-file=ssl_ecdsa_private_key.pem --from-file=ssl_rsa_private_key.pem --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=ssl_cabundle.crt --from-file=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt --from-file=sasl.txt -n <namespace>

4. Provide appropriate values for the SSL section.

   SSL configuration:

   service:
     ssl:
        
       privateKey:
         k8SecretName: ocegress-secret
         k8NameSpace: bsf
         rsa:
           fileName: rsa_private_key_pkcs1.pem
         ecdsa:
           fileName: ssl_ecdsa_private_key.pem
    
       certificate:
         k8SecretName: ocegress-secret
         k8NameSpace: bsf
         rsa:
           fileName: tmp.cer
         ecdsa:
           fileName: ssl_ecdsa_certificate.crt
    
       caBundle:
         k8SecretName: ocegress-secret
         k8NameSpace: bsf
         fileName: caroot.cer
    
       keyStorePassword:
         k8SecretName: ocegress-secret
         k8NameSpace: bsf
         fileName: key.txt
    
       trustStorePassword:
         k8SecretName: ocegress-secret
         k8NameSpace: bsf
         fileName: trust.txt
    
       initialAlgorithm: RS256

5. Configure the message copy feature.

   messageCopy:
     enabled: true
     copyPayload: true
     topicName: BSF
     ackRequired: false
     retryOnFailure: 0
     security:
       enabled: true
       protocol: SASL_SSL
       tlsVersion: TLSv1.2
       saslConfiguration:
        userName: ocnadd
        password:
          k8SecretName: ocegress-secret
          k8NameSpace: bsf
          fileName: sasl.txt

6. Make sure to configure the correct SASL_SSL port in kafka.bootstrapAddress attribute. To get the correct value of this, refer to DD Kafka's Values.yaml file.

Observability

Metrics

The following metrics are used to count the ingress and egress messages at the gateways:

• oc_ingressgateway_msgcopy_requests_total
• oc_ingressgateway_msgcopy_responses_total
• oc_egressgateway_msgcopy_requests_total
• oc_egressgateway_msgcopy_responses_total

For more information, see:

• Ingress Gateway Metrics
• Egress Gateway Metrics

Alerts

The following alerts are raised when OCNADD is not reachable:

• INGRESS_GATEWAY_DD_UNREACHABLE_MAJOR
• EGRESS_GATEWAY_DD_UNREACHABLE_MAJOR

For more information, see

• INGRESS_GATEWAY_DD_UNREACHABLE_MAJOR
• EGRESS_GATEWAY_DD_UNREACHABLE_MAJOR