5-9). DWR/DWA; 5-10). DPR/DPA
§ The Device-Watchdog-Request and Device-Watchdog-Answer messages, defined in this section, are used to proactively detect transport failures.
§ Given the nature of the Diameter protocol, it is recommended that transport failures be detected as soon as possible.
§ Detecting such failures will minimize the occurrence of messages sent to unavailable agents, resulting in unnecessary delays, and will provide better failover performance.
§ The Device-Watchdog-Request (DWR) is sent to a peer when no traffic has been exchanged between two peers. Upon detection of a transport failure, this DWR message MUST NOT be sent to an alternate peer
§ The Device-Watchdog-Answer (DWA) is sent as a response to the Device-Watchdog-Request (DWR) message.
§ In the event that a transport failure is detected with a peer, it is necessary for all pending request messages to be forwarded to an alternate agent, if possible. This is commonly referred to as failover.
§ In order for a Diameter node to perform failover procedures, it is necessary for the node to maintain a pending message queue for a given peer. When an answer message is received, the corresponding request is removed from the queue. The Hop-by-Hop Identifier field is used to match the answer with the queued request.
§ It is important to note that multiple identical requests or answers MAY be received as a result of a failover. The End-to-End Identifier field in the Diameter header along with the Origin-Host AVP MUST be used to identify duplicate messages.
§ A connection request should be periodically attempted with the failed peer in order to re-establish the transport connection.
§ Once a connection has been successfully established, messages can once again be forwarded to the peer. This is commonly referred to as failback.
§ Note in particular to requires the use of watchdog messages to probe connections. For Diameter, DWR and DWA messages are to be used.
§ DWR/DWA Message formats for Online Charging in DCCA same as RFC 4006
§ In the event that the disconnect was a result of either a shortage of internal resources, or simply that the node in question has no intentions of forwarding any Diameter messages to the peer in the foreseeable future, a periodic connection request would not be welcomed.
§ The Disconnect-Peer-Request (DPR) message is used by a Diameter node to inform its peer of its intent to disconnect the transport layer, and that the peer shouldn't reconnect unless it has a valid reason to do so (e.g., message to be forwarded).
§ The receiver of the Disconnect-Peer-Answer (DPA) initiates the transport disconnect.
§ The Disconnect-Peer-Request (DPR) is sent to a peer to inform its intentions to shutdown the transport connection. Upon detection of a transport failure, this DPR message MUST NOT be sent to an alternate peer.
§ The Disconnect-Peer-Answer (DPA) is sent as a response to the Disconnect-Peer-Request message. Upon receipt of this DPA message, the transport connection is shutdown.
§ The Disconnect-Cause AVP is of type Enumerated. A Diameter node MUST include this AVP in the Disconnect-Peer-Request (DPR) message to inform the peer of the reason for its intention to shutdown the transport connection.
The following Cause values are supported:
§ REBOOTING = 0 (A scheduled reboot is imminent)
§ BUSY = 1 (The peer's internal resources are constrained, and it has determined that the transport connection needs to be closed.)
§ DO_NOT_WANT_TO_TALK_TO_YOU = 2 (The peer has determined that it does not see a need for the transport connection to exist, since it does not expect any messages to be exchanged in the near future.)
§ DPR/DPA Message formats for Online Charging in DCCA same as RFC 4006