5-9). DWR/DWA; 5-10). DPR/DPA
5.9. (280) Device-Watchdog-Request / Answer (DWR and DWA):
§ 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.
(DCCA for Charging in 32.299) between IMS Nodes and OCS
§ DWR/DWA Message formats for Online Charging in DCCA same as RFC 4006
5.10. (282) Disconnect-Peer-Request / Answer (DPR and DPA):
§ 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.)
(DCCA for Charging in 32.299) between IMS Nodes and OCS
§ DPR/DPA Message formats for Online Charging in DCCA same as RFC 4006
沒有留言:
張貼留言