2.6 Ingress Transaction Management

Ingress transaction management involves creation and management (including management of lifetime) of ingress transaction records maintained for each new ingress Request received from a client.

Ingress transaction management supports three main functions:

• Avoid creation of duplicate egress transactions resulting from retransmitted ingress requests from clients
• Address potential loss of response sent to the client by caching previously forwarded responses. When the client retransmits a request, the cached response (if available) is forwarded to the client
• Storing the information associated with an ingress transaction which is needed for updating the RADIUS response associated with the transaction

RADIUS clients send Requests to RADIUS servers. Typically, if a RADIUS client does not receive a response in a timely manner, RADIUS clients retransmit the request to the RADIUS server a few times, using the same source IP address, source port, RADIUS Header Identifier and Authenticator, before failing over to an alternate server. If the server receives a request multiple times, and if it cannot detect the request as a duplicate, it could result in the transaction being processed more than once, which is not desirable.

RCL ingress transaction processing supports detecting duplicate requests and preventing duplicate transactions from being processed. When DSR successfully processes a RADIUS request, a response is forwarded to the RADIUS client. Owing to the unreliable nature of the transport protocol, this request might be lost in transit. If the RADIUS client then retransmits the request as a result, RCL has the capability to cache previously sent responses for some time, detect duplicate requests received during that time and forward the previously sent response, thus preventing a duplicate transaction from being processed. This behavior is configured through the RADIUS Options tab of the Connection Configuration Sets page (refer to the Diameter User's Guide for further information on Connection Configuration Sets).

If duplicate ingress transaction detection and prevention for a RADIUS server connection is enabled, RCL supports certain functionalities:

• For each RADIUS Request received on the connection which is not a duplicate transaction, RCL creates an Ingress Transaction Record (ITR) for the transaction. The ITR serves as the mechanism for detecting duplicate ingress transactions.

  Note:

  The ITRs are searched to determine whether the ingress transaction is a duplicate.
• For each duplicate RADIUS Request received on the connection, RCL discards the message to prevent duplicate processing of the same transaction. If a Response message is cached in the ITR, then RCL resends the Response message back to the RADIUS client. The Response remains cached for a user-configurable lifetime. When the lifetime duration is reached, both the cached Response and ITR are deallocated.
• When a RADIUS response is sent to the RADIUS client for the first time for the transaction, RCL caches a copy of the response in the ITR.

A RADIUS transaction is considered a duplicate if the previously processed Request message and the newly received Request message both contain the same Source IP Address, Source Port Number, Destination IP Address, Destination Port Number, Identifier and Authenticator header fields. RCL can detect a duplicate transaction until the corresponding ITR is present.