Diameter-based External Policy Servers

Diameter Connection

The Oracle Communications Session Border Controller (SBC) supports Diameter (RFC 3588) connections to a Diameter server over TCP or SCTP. The base Diameter protocol runs on port 3868 for both TCP and SCTP. Diameter-based RACF and CLF are available from the media interfaces on the SBC.

The Diameter connection is always initiated from the SBC to the Diameter server. The SBC begins the connection by sending a Capabilities-Exchange-Request (CER) to the server, which replies with Capabilities-Exchange-Answer (CEA) message.

SCTP Support for the Rx Interface

You can configure the SBC to support Rx interface connections to external policy servers using SCTP transport as an alternative to TCP. Each server provides for this configuration and generates configuration errors when the server configuration is not appropriate for SCTP. All servers also use the global SCTP configuration within the network-parameters element, with the exception of sctp-send-mode, which you can configure within the ext-policy-server element. After transport is set up, diameter works the same as over TCP.

As is true for TCP, the SBC uses the first interface configured in the external policy server's realm to setup connections. For redundancy, however, you can configure SCTP multihoming and use multihoming targets provided to the SBC by the SCTP handshake with the peer. The SBC can access these targets via any interface in the external policy server's realm.

See a description of how SCTP works on the SBC in Stream Control Transfer Protocol Overview.

Additional Diameter Connection Compliance for the Rx Interface

When handling some Register and Message flows, the SBC default behavior does not include strict compliance with Diameter session teardown rules. Typically, the environment can proceed without issue, but the SBC provides an ext-policy-server option, called diam-rx-strict-compliance, that provides better compliance with Diameter session teardown rules.

Set the diam-rx-strict-compliance option on the applicable ext-policy-server to establish the following Diameter session behavior:

For Register flows that do not establish a Diameter session with the PCRF due to a 3xxx, 4xxx or 5xxx error from the PCRF, the SBC does not send an STR to tear down the session when it receives a De-Register.
For Message flows, when the SBC receives an ASR from PCRF, it stops the hold timer if it is running, then forwards the MESSAGE to the core, and sends an ASA with success.
For unsuccessful Register flows that include an established Diameter session with the PCRF, the SBC sends an STR to tear down the session after the Register has failed due to, for example, responses from the core.
If the SBC receives an S8HR Emergency Registration, with or without Authorization header, and either the Rx interface is not available or there is an error in AAA response sent by PCRF, the SBC replies with a 5xx response.
If the SBC receives an S8HR Emergency Registration without an Authorization header and the EPC identities validation fails, the SBC sends a 403 error with the SIP reason header. If the SBC receives a REGISTER request with the authorization header, it sends a MIME XML body with a reason tag.
For S8HR registrations and calls, the SBC adds the P-Visited-Network-ID header using the format "plmnIdPrefix.mncxxx.mccxxx.3gppnetwork.org".
During an S8HR registration scenario, if the SBC receives a REGISTER request with the Authorization header and the next-hop is not configured, the SBC sends a 403 response if the EPC identities validation fails.
When the SBC experiences a diameter transaction timeout from the PCRF, it does not issue an STR.
Within emergency REGISTER call flows when S8HR is enabled and there are no EPC level identities cached, the SBC does not issue an STR simultaneously with a 403 error code if it receives a 3002 error code from the PCRF.

Syntax for this option may or may not include the plus (+) sign, but note that setting the option with the + sign retains all other options set on the element. Omitting the + sign replaces any existing options with the one you set.

ACMEPACKET(ext-policy-server)# options +diam-rx-strict-compliance

HA Support

The Oracle Communications Session Border Controller's high availability (HA) capabilities support CAC. When one Oracle Communications Session Border Controller in an HA configuration goes out of service, the MAC addresses are reassigned to a healthy Oracle Communications Session Border Controller. IP addresses follow the MAC addresses to provide a seamless switchover between HA nodes.

After an HA failover, the Diameter connection on the primary Oracle Communications Session Border Controller is either gracefully torn down, or times out depending on behavior of the PDP. The backup Oracle Communications Session Border Controller attempts to create a new Diameter connection with the PDP.

FQDN Support

You can configure FQDNs in the address parameter in the external policy server configuration element. These FQDNs must conform to RFC 1035. If the port parameter in external policy server configuration element is not zero, then it will be used to connect to the group of applicable external policy servers. If the port parameter is set to zero, then the port number returned in SRV RR from the DNS server will be used. For external policy servers using TCP transport, the Oracle Communications Session Border Controller (SBC) always appends the _diameter._tcp. to request only TCP based Diameter servers to DNS queries triggered by FQDN configurations. For SCTP, the SBC appends _diameter._sctp.

There are differences in the way the SBC uses FQDNs between TCP and SCTP. For example, TCP uses FQDNs to establish server redundancy, whereas SCTP uses multihoming configurations. It is also important to note that the SBC only sends these DNS queries out to a DNS server configured on the first interface in the realm configuration.

The Stream Control Transfer Protocol Overview provides a thorough description of how this protocol works on the SBC.

IPv6 Support

An external policy server configuration element with an application mode parameter set to Rx may be configured with an IPv6 address in the address parameter (in addition to an IPv4 address or FQDN).

Diameter Heartbeat

Device-Watchdog-Request (DWR) and Device-Watchdog-Answer (DWA)messages are used to detect transport failures at the application layer between the Oracle Communications Session Border Controller communicating with a policy server via Diameter. The request/answer message pair forms a heartbeat mechanism that can alert the requesting side if the answering side is not reachable.

The Oracle Communications Session Border Controller always responds to a DWR by replying with a DWA message. In addition, the Oracle Communications Session Border Controller can be configured to initiate DWR messages toward a policy server or other Diameter-based network device.

You configure the watchdog ka timer with a timeout value that determines the number of seconds a DWA is expected in response to the Oracle Communications Session Border Controller sending a DWR.

If the Oracle Communications Session Border Controller fails to receive a DWA response from a Policy Server within the configured interval, then the connection towards that Policy Server is considered failed and torn down. The Oracle Communications Session Border Controller attempts to recreate the transport connection, followed by the recreating the Diameter connection by issuing a CEA toward the policy server.

Diameter Failures

During periods of application inactivity on the Diameter interface, Device-Watchdog-Request (DWR) and Answer (DWA) messages are exchanged between the client and server to provide an application-level heartbeat. DWRs may be sent toward the Oracle Communications Session Border Controller (SBC), which responds with a DWA message.

Prior to establishing a connection over TCP transport, the system tries to connect to a configured Diameter server using the default TCP retry interval of 10 seconds. This is also true if either side of the connection receives a TCP FIN or RST. The SBC labels a connection as failed when it does not receive a DWR from the Diameter server within the guard timer period.

If an operational Diameter connection over TCP transport fails, the SBC tries to re-open the TCP socket and Diameter connection to the Diameter server at 30 second intervals, and increases its retry interval to 5 minutes until a successful Diameter connection is made.

The SBC also supports SCTP transport for Rx interface connections. The SBC performs similar procedures to monitor diameter connections over SCTP, using SCTP's standard transport mechanisms, described in SCTP Monitoring Failure Detection and Recovery.

Application IDs and Modes

Diameter messages include an application ID to indicate the application and standards’ body interface. The following table lists the different Application-IDs for the corresponding standards’ and applications. Application IDs must be provisioned manually.

N/A	Standards Reference Point	Standards Reference Point	Standards Reference Point	Standards Reference Point
N/A	RACF	RACF	RACF	CLF
Reference Point/ Standards Body	Gq 3GPP R6 29.209	Rx 3GPP R15 29.214	Rq ETSI 283 026	e2 ETSI 283 035
Application-ID	16777222	16777229	16777222	16777231

You also set the application mode to specify the interface more precisely. Doing so avoids the potential for collision between interface types that can occur when you only configure the application identifier. By setting both the application mode and application identifier for the interface, you tell the Oracle Communications Session Border Controller the format for Diameter messages it sends and receives.

The following table describes the application mode settings.

Application Mode Type	Description
Rq	As the default mode for the interface, Rq is the Oracle Communications Session Border Controller’s base RACF interface. Even when you leave the application mode set to none (default), the Oracle Communications Session Border Controller runs in Rq mode. The only exception to this rule is if you set the application identifier to 16777236 and leave the application mode set to none; in this instance, the interface runs in Rx mode.
Rx	The interface runs in Rx mode when you either: Set the application mode to Rx and the application identifier to 16777236 Leave the application mode set to none, and set the application identifier to 16777236
Gq	The interface runs in Gq mode when you set the application mode to Gq. Note: The application identifier 1677722 is no longer unique, but applies both to Rq and Gq interface modes.
e2	The interface runs in e2 mode, the base CLF interface, when you set the application mode to e2. Even if you leave the application mode set to none, the interface will run in e2 mode when the external policy server is configured as a CLF interface.
none	The interface runs in Rq mode when you do not configure an application identifier, or in Rx mode if you set the application identifier to 16777236.

Asynchronous SIP-Diameter Communication

The Oracle Communications Session Border Controller's Diameter-based external policy server support now offers an asynchronous mode in which the SBC does not wait for a Diameter Authorization-Authentication Answer (AAA) response to an Authorization-Authentication Request (AAR) before allowing the SIP 200 OK to proceed through the SBC.

One of the fundamental behaviors in the Oracle Communications Session Border Controller's Diameter model relies on the external policy server making an authorization decision which is then communicated to the SBC. Part of the call authorization sequence of events involves the SBC waiting for an external policy server’s response before the SBC can completely set up, modify, or update the call. The long pause that the endpoints experience, while the SBC holds up SIP flows waiting for the external policy server’s response, can lead to unnecessary call failure situations.

In some Diameter-based external policy server deployments, the media traverses a Cable Modem Termination System (CMTS) at the edge of the network; the CMTS gates may be established by a Policy Server to dynamically enable QoS from a UE toward another UE. If no gate is established then the media traverses the CMTS and is admitted to the network with a “best-effort” network path.

As QoS sessions might not be the most important priority to a network, Oracle now allows network operators the ability to decouple the call set up (signaling) from the request for bandwidth. The SBC’s default external policy server model is the synchronous model, in which the SBC sends a policy server request based on a SIP or SDP trigger point, and the SIP signaling is held until a response is returned from the Policy Sever. In the asynchronous model the request that the SBC sends to the Policy Server flows in an asynchronous state with respect to SIP messaging; that is, the SBC allows the SIP session to proceed naturally, and does not pause for outstanding Policy Server answers to be received. The establishment of a SIP session is not affected by Policy Server answers, or answer timeouts, related to the SIP session. To enable the asynchronous model, the new parameter asynchronous-mode has been added to the ext-policy-server configuration element, with a default of disabled so as not to affect current default behavior.

Note:

Oracle Communications recommends that, for each SBC, the same model be used for all external policy server configuration instances. Failure to follow this guideline could result in complex interactions from a timing perspective which might lead to dropped or degraded calls.

SIP-Diameter Communication Configuration

Access the ext-policy-server configuration element.

ORACLE# configure terminal
ORACLE(configure)# media-manager
ORACLE(media-manager)# ext-policy-server
ORACLE(ext-policy-server)#

Select the ext-policy-server object to edit.

ORACLE(ext-policy-server)# select
<name>:1:  name=extpol1

selection: 1
ORACLE(ext-policy-server)#

asynchronous-mode — identifies whether to use the asynchronous mode of signaling on the external policy server interface rather than the default synchronous mode. Allowable values are enabled and disabled. The default is disabled.
Type done to save your configuration.

Serialized Diameter Messaging

After the Oracle Communications Session Border Controller sends a Diameter request, it will not send another Diameter request, such as a Session Termination Request (STR), with the same Session-ID Attribute Value Pair (AVP) until the original request receives a response or times out.

Access networks with complex policy server structures can allow non-sequential delivery of Diameter requests into a Cable Modem Termination System (CMTS), even if Diameter message delivery was correctly ordered on the TCP connection between the SBC and a lower-tiered external policy server.

The SBC now prevents the external policy server from receiving out-of-order messages at the application layer by serializing them. The SBC serializes Diameter messages to ensure that a Diameter request for one session-ID is not sent until an answer is received from the previous request for the same session-ID. The SBC applies this constraint while waiting for a Diameter response or when considering a Diameter request timeout (15 seconds). Serialized Diameter messaging is always enforced for Diameter-based external policy server communication.

Flow-Description AVP for Media Release

The Rx interface between the Oracle Communications Session Border Controller (SBC) and the Policy Server (PS) assumes that the media is always managed by the SBC and that the IP address and port number of one end of a service flow will always correspond to one present on the SBC. However, there are times when the media is released by the SBC, but a policy server request is still required. In these cases the flow descriptions should accurately represent the IP addresses of the two endpoints instead of that of the SBC. This feature lets the user configure the SBC to change the payload of the Flow-Description Attribute Value Pair (AVP) in the Diameter AAR messaging from the SBC to the PS, depending on whether the media is managed or released by the SBC.

In the case where the media is released, only incomplete flow information may be provided to the Policy Server because not all IP addresses and port numbers are known from the SDP offer. Media release is enabled on a per realm basis with the following settings in the realm-config configuration element:

        mm-in-realm                     disabled
        mm-in-network                   disabled
        mm-in-system                    disabled
        mm-same-ip                      disabled
        msm-release                     enabled

When the realm is configured for external bandwidth management, the media layer checks if any of the configuration parameters for media release have been invoked. If none of the media release parameters are invoked (meaning that the SBC is managing the media), then the signaling application constructs the bandwidth request to the PS as it currently does. If the media layer detects that the realm is configured to possibly release media, then a few more operations are performed to correctly populate the bandwidth request to the PS. If the media has been released for the session, the signaling application inserts the IP port of the called endpoint into the bandwidth request instead of the IP port for the SBC. If the media has not yet been released, the media layer determines if the initial signal is an OFFER or an ANSWER. If it is an ANSWER the IP port in the bandwidth request will be that of the SBC because the SBC is managing the media for the session. If it is an OFFER, the signaling application inserts an empty IP port into the bandwidth request and sets a flag in the bandwidth request indicating unqualified flow information at this time. This occurs regardless of the value of the parameter reserve-incomplete in the ext-policy-server configuration element.

To enable this behavior on the Rx interface, the new parameter media-release has been added to the ext-policy-server configuration element.

Load Balancing Rx Servers

The Oracle Communications Session Border Controller (SBC) allows you to configure load balancing for DIAMETER Rx traffic across multiple Diameter Routing Agents (DRAs) using the external-policy-server configuration. When configured for TCP transport, this load balancing is available in addition to standard, DNS-based redundancy, where the SBC uses fully qualified domain names (FQDNs) to cycle through the multiple DRAs that DNS resolves to a single FQDN. For SCTP transport, the SBC simply substitutes the first address provided by a DNS lookup as the DRA connection address, and only uses policy-groups for load balancing.

The SBC performs load balancing via configured policy-groups, within which you configure the group's policy-agents. You apply the name of a group to an external-policy-server element configured for Rx operations to complete the configuration.

You configure the load balancing strategy and recursion preferences within the policy-group, in addition to the agent list.

You configure each policy-agent for either TCP or SCTP transport, as well as the agent's address, port and realm. To utilize DNS, configure address parameter with FQDNs.

The SBC load balances between DRAs that are IN-SERVICE. The SBC marks a diameter agent as IN-SERVICE state if the transport socket is connected and the CER/CEA exchange is successful. The SBC does not send DIAMETER messages (other than CER) to a server that is not in the IN-SERVICE state. The SBC excludes a DRA from load balancing if it goes OUT-OF-SERVICE and includes it when it becomes IN-SERVICE again.

When configured, the SBC load balances all Rx traffic requests, with the exception of the following message types, which must be sent to each DRA individually:

CER
DWA and DWR
- The SBC sends DWA answers to the DRA from which the DWR came.
- The SBC sends DWRs to each DRA at the intervals configured by its watchdog-ka-timer.

The SBC must also send responses to the following requests directly to the DRA that issues them, and therefore does not load balance this traffic:

DWR
RAR
ASR

This feature is RTC supported.

Rx Load Balancing Statistic Reporting

You can find statistics on load balanced RX traffic using:

The show policy-server command displays cumulative counters for a group.
The show policy-server NAME/AGENT" command displays specific group member counters.

Recursion

Recursion is de-coupled from load balancing. The SBC does not load balance recursive messages, sending them to the policy agents sequentially. Furthermore, the SBC performs recursion only on AAR and STR messages, not on CER and DWR messages.

Note:

Recursion, when enabled, takes precedence over the str-retry option.

Configuring Policy Groups and Policy Agents

To configure policy groups and policy agents on the Oracle Communications Session Border Controller (SBC):

Access the policy-group configuration

ORACLE# configure terminal 
ORACLE(configure)# media-manager 
ORACLE(media-manager)# policy-group 
ORACLE(policy-group)#

group-name—Enter a unique name for the policy group in Name format.
description—Optional. Enter descriptive information about the policy group.
state—Enable or disable the policy group. The default value is enabled. Valid values are:
- enabled | disabled
policy-agent—Enter the policy-agent sub-element to configure 1 or more policy-agents.
policy-agent > name—Enter a unique name for the policy-agent in Name format.
policy-agent > description—Optional. Enter descriptive information about the policy-agent.
policy-agent > state—Enable or disable the policy-agent. The default value is enabled. Valid values are:
- enabled | disabled
policy-agent > address—Enter the address for the policy-agent. This address can be IPv4, IPv6 or an FQDN.
policy-agent > port—Enter the port for the policy-agent. The system ignores this parameter if the address parameter is set to an FQDN.
policy-agent > realm—Enter the realm for the policy-agent.
policy-agent > watch-dog-ka-timer—Enter the number of seconds to specify the expiry of this agent's watch dog timer.
policy-agent > transport-protocol—Enter the transport protocol for the policy-agent. The default value is TCP. Valid values are:
- TCP (Default)
- SCTP—SCTP is only valid over the Rx interface. This is confirmed by the external-policy-server configuration to which this policy-group is assigned.
policy-agent > local-multi-home-addrs—Applies to SCTP. Enter an IP address that is local to the SBC and can be used by this policy-agent as an alternate connection point. This address must by the same type, either IPv4 of IPv6 as that of the address parameter.
policy-agent > remote-multi-home-addrs—Applies to SCTP. Enter an IP addresses that can be used by this SBC as an alternate connection point. This address must by the same type, either IPv4 of IPv6 as that of the address parameter.
policy-agent > sctp-send-mode—Applies to SCTP. Specifies the SCTP delivery mode. The default value is ordered. Valid values are:
- ordered | unordered
strategy—Enter the policy allocation strategy you want to use. The strategy you choose defines the order the SBC uses to try policy-agents. The default and only value is RoundRobin:
- RoundRobin—Selects each policy-agent in the order in which they are listed in the destination list, selecting each policy-agent in turn, one per session.
max-recursions—Enter an integer to specify the number of times the SBC can recurse through the agent list.
stop-recurse—Enter the list of SIP response codes that terminate recursion within the group. Upon receiving one of the specified response codes, such as 401 unauthorized, or upon generating one of the specified response codes internally, such as 408 timeout, the SBC returns a final diameter response code to the policy-agents in the group and stops trying to route the message.
Enter the response codes as a comma-separated list or as response code ranges.
recursion-timeout—Time in seconds that the SBC waits for max-recursions to finish before timing out. The default is 15 seconds.
Type done to save your configuration.

Assigning a Policy Group to a Policy Server

You can configure the SBC to load balance Rx interface traffic using policy-group configurations. The ext-policy-server element allows you to set its address parameter to a policy-group's name parameter to use a group's load balancing configuration. You also configure the policy-group's policy-agent sub-elements to define the external servers with which you load balance this traffic.

Example syntax for targeting a policy-group with the ext-policy-server address parameter:

ext-policy-server
        name                                    policyGroup1
        state                                   enabled
        operation-type                          bandwidth-mgmt
        protocol                                DIAMETER
        address                                 PAG:myGroupName
...

As with all Rx traffic, you can configure the SBC to support this traffic over SCTP as an alternative to TCP.