8 Diameter race condition handling

29.2133GPPPolicy and charging control signalling flows and Quality of Service (QoS) parameter mappingRelease 17TS

8.1 Overview

Certain Diameter PCC applications (Gx, Gxx, Sd, S9) allow the server (PCRF for Gx, Gxx, Sd, H-PCRF for S9) to update a session in two ways: unsolicited and solicited. The PCRF can push policy decisions and provision event triggers in an unsolicited fashion using an RAR. It can also install policy decisions in a solicited manner by responding to a CCR sent by the client (BBERF for Gxx, PCEF for Gx, TDF for Sd, V-PCRF for S9).

The client and the server can initiate transactions that modify the state of the session independently (e.g. CCR from the client and RAR from the server) and potentially concurrently. Additionally, there may be Diameter agents in between the client and server (e.g. DRA or in general Diameter relays/proxies) that could cause messages to be delivered out of order. This can lead to race conditions that may result in the wrong information maintained by the client and/or server for a session.

Note that race conditions occur in different ways based on the application. Also, their impact is specific to the application. For example, even though Gx is based on DCCA (RFC 4006), Gx is much more vulnerable to race conditions as Gx allows sessions to be updated based on RARs and CCAs whereas DCCA only allows the server to update the session based on a CCA. The RAR is merely used to solicit the client to send a CCR.

8.2 Procedures for Gx, Gxx, Sd and S9

This clause describes the optional procedures for handling Diameter race conditions in a deterministic manner for the following interfaces: Gx, Gxx, Sd and S9. These procedures apply to the PCEF (Gx), BBERF (Gxx), TDF (Sd) and PCRF (Gx, Gxx, Sd and S9).

In this clause, the terms “client” and “server” are relative to the session context. As an example, for the Gx interface, the client is the PCEF and the server is the PCRF. The term “node” can refer to either a client or a server. The term “transaction” refers to a Diameter request and its associated answer. The term “ongoing transaction” refers to a transaction that has an outstanding answer.

A node that supports the procedures defined in this clause and is configured to comply with them, shall advertise such support by setting the corresponding PendingTransaction feature bit in the Supported-Features AVP during session establishment as defined in 3GPP TS 29.212 [9] for Gx, Gxx and Sd and 3GPP TS 29.215 [22] for S9.

On receipt of a Diameter request for an existing Diameter session, the recipient Diameter node shall check if it has an ongoing transaction on that session:

1. If there are no ongoing transactions on the session, the node shall process the incoming request normally.

2. If there is an ongoing transaction on the session and optionally, if the recipient node cannot determine that the incoming request can be safely handled without creating a state mismatch:

a. The client shall reject the incoming request with a Diameter experimental result code of DIAMETER_PENDING_TRANSACTION as defined in 3GPP TS 29.212 [9].

b. The server shall either reject the incoming request with a Diameter experimental result code of DIAMETER_PENDING_TRANSACTION or shall wait for one of the following conditions to occur:

i. The ongoing transaction completes. In this case, the session is updated at the server based on the completion of the ongoing transaction and afterwards, the incoming request (e.g. CCR) is processed normally based on the updated session state.

ii. The waiting period has exceeded its allotted time. In this case, the server shall reject the incoming request with a Diameter experimental result code of DIAMETER_PENDING_TRANSACTION.

NOTE 1: If there is an ongoing transaction on the session and optionally, if the recipient node can determine that the incoming request can be safely handled without creating a state mismatch, the client and the server could handle the incoming request normally.

3. On receipt of a DIAMETER_PENDING_TRANSACTION result code, a client shall retry the request. On the other hand, if a server had rejected a request from the client with a DIAMETER_PENDING_TRANSACTION, the server should not retry the failed request until it responds to the re-attempted request from the client. This is to avoid having both the client and server concurrently retry their requests. In all other cases, if the session on the client still needs to be updated, the server shall retry the request.

NOTE 2: The server retries the request either by resending the command (e.g. RAR) or by including the initial requested information in the command (e.g. CCA) answering the re-attempted request from the client. However, including the initial requested information in the command (e.g. CCA) answering the re-attempted request is only possible if the server does not require a response to the command.

4. Nodes should limit the number of times they re-attempt the same request due to receipt of a DIAMETER_PENDING_TRANSACTION.

5. The only exception to the rules above is a session termination request (e.g. CCR with a CC-Request-Type AVP set to TERMINATION_REQUEST) or a request for session release (e.g. RAR with Session-Release-Cause AVP). In both cases, the request should be handled as follows:

a. When receiving a request for a session release that requires new transactions to be initiated, a client shall acknowledge the request immediately (e.g. a RAR command with Session-Release-Cause AVP shall be acknowledged with a RAA command). The client shall wait for the current transaction to complete (either by the server acknowledging the request or rejecting it with DIAMETER_PENDING_TRANSACTION) before completing the session termination procedure (e.g. before sending the CCR command with the CC-Request-Type set to TERMINATION_REQUEST).

NOTE 3: The client needs to wait for the outcome of the session modification to determine if the session termination procedure will be used to report information that could not be reported as part of the session modification procedure.

NOTE 4: After having sent a request for session termination, the server acknowledges any unrelated incoming request immediately (either by the server acknowledging the request or rejecting it with DIAMETER_PENDING_TRANSACTION) without a waiting period.

b. When receiving a session termination request the server shall handle it immediately.

Annex A (informative):
Examples of deriving the Maximum Authorized parameters from the SDP parameters

Annex B (normative):
Signalling Flows for IMS

The signalling flows in clause 4 are also applicable for IMS. This Annex adds flows that show interactions with SIP/SDP signalling of the IMS.