Diameter-based External Policy Servers

The Diameter base protocol (RFC 3588) is supported by the Oracle Communications Session Border Controller and is used for Resource and Admission Control Function (RACF) and Connectivity Location Function (CLF) applications.

Diameter Connection

The Oracle Communications Session Border Controller (OCSBC) 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 OCSBC.

The Diameter connection is always initiated from the OCSBC to the Diameter server. The OCSBC 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 OCSBC 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 OCSBC 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 OCSBC by the SCTP handshake with the peer. The OCSBC can access these targets via any interface in the external policy server's realm.

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

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 (OCSBC) always appends the _diameter._tcp. to request only TCP based Diameter servers to DNS queries triggered by FQDN configurations. For SCTP, the OCSBC appends _diameter._sctp.

There are differences in the way the OCSBC 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 OCSBC 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 OCSBC.

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 (OCSBC), 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 OCSBC 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 OCSBC 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 OCSBC also supports SCTP transport for Rx interface connections. The OCSBC 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 R7 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 OCSBC 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 OCSBC.

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 OCSBC. Part of the call authorization sequence of events involves the OCSBC waiting for an external policy server’s response before the OCSBC can completely set up, modify, or update the call. The long pause that the endpoints experience, while the OCSBC 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 OCSBC’s default external policy server model is the synchronous model, in which the OCSBC 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 OCSBC sends to the Policy Server flows in an asynchronous state with respect to SIP messaging; that is, the OCSBC 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 OCSBC, 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 OCSBC and a lower-tiered external policy server.

The OCSBC now prevents the external policy server from receiving out-of-order messages at the application layer by serializing them. The OCSBC 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 OCSBC 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 (OCSBC) and the Policy Server (PS) assumes that the media is always managed by the OCSBC and that the IP address and port number of one end of a service flow will always correspond to one present on the OCSBC. However, there are times when the media is released by the OCSBC, 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 OCSBC. This feature lets the user configure the OCSBC to change the payload of the Flow-Description Attribute Value Pair (AVP) in the Diameter AAR messaging from the OCSBC to the PS, depending on whether the media is managed or released by the OCSBC.

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 OCSBC 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 OCSBC. 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 OCSBC because the OCSBC 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 (OCSBC) 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 OCSBC uses fully qualified domain names (FQDNs) to cycle through the multiple DRAs that DNS resolves to a single FQDN. For SCTP transport, the OCSBC simply substitutes the first address provided by a DNS lookup as the DRA connection address, and only uses policy-groups for load balancing.

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

When configured, the OCSBC 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 OCSBC sends DWA answers to the DRA from which the DWR came.
- The OCSBC sends DWRs to each DRA at the intervals configured by its watchdog-ka-timer.

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

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.

Configuring Policy Groups and Policy Agents

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

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 OCSBC 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 OCSBC 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 OCSBC uses to try policy-agents. The default value is RoundRobin. The valid values are:
- 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 OCSBC 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 OCSBC 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 OCSBC 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 OCSBC 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 OCSBC to support this traffic over SCTP as an alternative to TCP.