3 Connection Management
Introduction
Introduction
The DCA server will accept inbound connections initiated by Diameter Credit-Control clients as per RFC 3588. However, the DCA will only allow connections from peers that are in its configured list. CERs from unknown peers will have a CEA message sent before the client closes the connection. DCA will not initiate connections to unconnected peers. Connections can be over either TCP or SCTP.
To manage the connections, the following messages from RFC 3588 are used:
- Capabilities Exchange Request (CER)
- Capabilities Exchange Answer (CEA)
- Device Watchdog Request (DWR)
- Device Watchdog Answer (DWA)
- Disconnect Peer Request (DPR)
- Disconnect Peer Answer (DPA)
Capabilities Exchange Messages
Capabilities Exchange Messages
The DCA will receive CER messages and respond with CEA messages, as per formats specified in RFC 6733. The content of the individual fields is as follows:
| Field | AVP Code | Data Type | Comment |
|---|---|---|---|
| Origin-Host | 264 | DiameterIdentity | Set from configuration. Default is hostname. |
| Origin-Realm | 296 | DiameterIdentity | Set from configuration. Default is hostname. |
| Host-IP-Address | 257 | Address | Set from configuration. Default is INADDR_ANY. |
| Vendor-ID | 266 | Unsigned32 | Set from configuration (Oracle vendor ID is 111). |
| Product-Name | 269 | UTF8String | Set from configuration. |
| Origin-State-Id | 278 | Unsigned32 | Used to detect a re-booting peer and wipe sessions for the host if it has rebooted. |
| Supported-Vendor-Id | 265 | Unsigned32 | Set from configuration. |
| Auth-Application-Id | 258 | Unsigned32 | Must be as specified in configuration. Default is 4 (Credit-Control). Inbound CER messages will be rejected. |
| Inband-Security-Id | 299 | Unsigned32 | Set to 0 (NO_INBAND_SECURITY). |
| Acct-Application-Id | 259 | Unsigned32 | Not included. |
| Vendor-Specific-Application-Id | 260 | Grouped | Not included. |
| Firmware-Revision | 267 | Unsigned32 | Not included. |
| Result-Code | 268 | Unsigned32 | Set as per RFC 6733. |
| Error-Message | 281 | UTF8String | Human-readable string, as per RFC 6733. |
| Failed-AVP | 279 | Grouped | Set as per RFC 6733. |
Disconnect Peer Messages
Disconnect Peer Messages
A literal interpretation of RFC 6733 could assume that after either side sends a DPR message, the receiving peer should never again attempt to reconnect the connection. On shutdown, DCA will send a DPR message. The client might take this literal interpretation and never try to reconnect. In this case, the client may need to be reinitialized or restarted.
The possible fields are as follows:
| Field | AVP Code | Data Type | Comment |
|---|---|---|---|
| Origin-Host | 264 | DiameterIdentity | Set from configuration. Default is hostname. |
| Origin-Realm | 296 | DiameterIdentity | Set from configuration. Default is hostname. |
| Disconnect-Cause | 273 | Enumerated | The only cause sent by the DCA is 2, DO_NOT_WANT_TO_TALK_TO_YOU. |
| Result-Code | 268 | Unsigned32 | Set as per RFC 6733. |
| Error-Message | 281 | UTF8String | Human-readable string, as per RFC 6733. |
| Failed-AVP | 279 | Grouped | Set as per RFC 6733. |
Device Watchdog Messages
Device Watchdog Messages
Provision is to be made for determining if there has been a transport failure by supporting the Device Watchdog Request (DWR) and Device Watchdog Answer (DWA) messages. This necessitates the ability to receive DWR messages and send an appropriate DWA message as a response. The purpose of this is that if a client detects a connection failure to the server, the client should make a periodic attempt to reconnect.
The length of the silent interval that must precede a DWR message is configurable. The possible fields are as follows:
| Field | AVP Code | Data Type | Comment |
|---|---|---|---|
| Origin-Host | 264 | DiameterIdentity | Set from configuration. Default is hostname |
| Origin-Realm | 296 | DiameterIdentity | Set from configuration. Default is hostname. |
| Origin-State-Id | 278 | Unsigned32 | Used to detect a re-booting peer and wipe sessions for the host if it has rebooted. |
| Result-Code | 268 | Unsigned32 | Set as per RFC 6733. |
| Error-Message | 281 | UTF8String | Human-readable string, as per RFC 6733. |
| Failed-AVP | 279 | Grouped | Set as per RFC 6733. |
Message Retransmission and Duplicate Detection
RFC 6733 and Event Based Credit-Control Duplicate Detection
In Diameter clients (and agents) may retransmit messages, where an unexpected failure has occurred. This may occur when a client has sent a request, but has not received a reply, within a specified period. This retransmission behavior can potentially lead to duplicates being sent. In such cases clients which send messages, which may be duplicates, may indicate the possibility that a subsequent message is a duplicate by setting the T command flag / bit (refer to Chapter 3 Diameter Header of RFC 6733).
Note: The T-flag not being set is not necessarily a definitive indicator that no duplicate is present.
End to end identifier
The DCA uses the End-to-End Identifier for detecting duplicate messages (in conjunction with the Origin-Host AVP). The DCA also ensures that answers must have the same identifier as in the original request. In addition duplicate requests result in essentially the same response, but should not affect state (that is, in Credit-Control duplicate billing must not occur).
Non-volatile storage
Non-volatile storage of End-to-End identifier or recently sent responses is not supported, due to the significant processing overhead this can introduce.
Duplicate message
The case where a duplicate arrives at a different SLC is also not supported. For real-life deployments each SLC should be treated as a separate realm in order to avoid double processing of duplicates. This means that the realm name and hostname may effectively be the same for each DCA SLC.
Note: Duplicate detection is not applied to Device Watchdog messages.
General duplicate detection
The following generalized approach is utilized for the detection of duplicates.
When the server receives a message which is a candidate for duplicate detection:
- The code searches a map of recently received messages for a matching End-to-End Identifier.
- If a duplicate message was encountered:
Resend the original response (which should have been remembered).
- If NO duplicates were detected in either backwards time frame or the original message was late:
Process the message like normal (that is, assume the message was never dealt with in the first place).
Session-Based Credit-Control Duplicate Detection
For session-based CCR messages (that is, those with Requested-Action AVP of INITIAL_REQUEST, TERMINATION_REQUEST, or UPDATE_REQUEST), duplicate detection is based on the mechanism described in RFC 4006. That is, duplicate detection for session-based messages is performed using the Session-Id AVP and CC-Request-Number AVP, in conjunction with the Credit-Control servers own internal state, for non Multiple-Services-Credit-Control cases.
CC-Request-Number detects out-of-sequence messages, and is expected to be sequential (as suggested by RFC 4006).
However, this does not hold for Multiple-Services-Credit-Control, because that CC-Request-Number will not necessarily be sequential. Clients are not required to wait for a CCA before sending a new Credit-Control-Request (CCR) message. This might happen if a client sends a new CCR for a different service (than those currently pending response), when that service requires further authorization to use more units.
For Multiple-Services-Credit-Control, a lookup is performed based on the inbound CC-Request-Number. If one is found, it can be assumed to be a duplicate and the same answer returned.