Diameter Peer Connection
A diameter node can make connection to all other node in the realm, but at a minimum , a diameter node should have to connection per REALM Known as primary and Secondary. Typically all messages for a realm are sent to Primary Node, but in the event that invokes the failover procedures, all the pending requests are sent to the Secondary Peer.
Diameter Peer discovery process is used to discover any node to which sender(considered) node wants to communicate.
Diameter Peer discovery process is used to discover any node to which sender(considered) node wants to communicate.
Disconnecting Peer Connection.
When a Diameter node disconnect its transport connection with other node, the Other node does not know the reason of disconnect and assumes it as connectivity problem and keep trying to reconnect.
But in some situation a node intentionally drops its connection with other node and does not want any connection request in near future without any proper reason. So a node can trigger the Disconnect-Peer-Request message which contain the Disconnect-Cause AVP.
In most of the cases Node does not wait for the Disconnect-Peer-Answer to disconnect the connection.
Disconnect-Peer-Request
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 message MUST NOT be sent to an alternate peer.
<DPR> ::= < Diameter Header: 282, REQ >
{ Origin-Host }
{ Origin-Realm }
{ Disconnect-Cause }
{ Origin-Host }
{ Origin-Realm }
{ Disconnect-Cause }
Disconnect-Peer-Answer
<DPA> ::= < Diameter Header: 282>
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
* [ Failed-AVP ]
Disconnect-Cause AVP
Disconnect-Cause AVP is Enumerated having following values
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.
Your Comments /Suggestions and Questions are always welcome.I would try to clarify doubts with best of my knowledge. So feel free to put Questions.
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.
Your Comments /Suggestions and Questions are always welcome.I would try to clarify doubts with best of my knowledge. So feel free to put Questions.
Hi Vinay,
ReplyDeleteThat was a helpful topic to understand the Diameter stack functionality.
I have one doubt, in case the primary peer timeouts to send the CCA for a provided CCR. IN that case, how can the stack be switched over to the Secondary peer.
I will appreciate your useful comments on this. Waiting for your response.
Thanks in Advance!
Hi Piyush
DeleteIn general traffic shall go to secondary peer in case of Transport connection Failure.
Timeout does not necessarily mean that it connection is broken. Timeout means Transport is up but not client is not able to receive answer form in given time frame.
Thanks for your query.
Happy to help you again.
Team-Diameter
Hi Vinay,
ReplyDeleteThanks for your useful reply.
Yes, in case here, we have a time out for the CCA(Credit control Answer) although the TCP connection is present. In such case, how we actually switch the same CCR( credit control Request) on the secondary peer.
One Observation: The Diameter stack makes connection with both the peers but sends the CCRs to one peer only which is stored first in the stack.
Kindly comment.
Thank you.
Regards,
PIYUSH
Hi Piyush
DeleteYour Observation is correct.
To reduce the timeout. I would suggest that please run two server application instances either on same server with different ports or on different servers with same ports and let the client application to distribute load either by DRA (i.e. put DRA b/w server and client and let the DRA to distribute load)
or directly having two separate connections, by making two different entries in configuration file. Now assign one origin host to req-1 and other to req-2 invoked by CCR client for instance. In such a way you can overcome timeouts.
Or Please check timeout time configured at client it might be very very less. if so please increase it n try again.
disable logging/filtering etc at both client and server end.
Thanks for your query.
Happy to help you again.
Team-Diameter
Hi Vinay,
ReplyDeleteThat was helpful in a way.
In the configuration file i have already provided the primary and secondary peer. I have added them in the routing table of Diameter stack as well.
I executed some test with 2 peers ( executed in local system with different ports )
Time out will occur if the peer , due to some reason would not respond to CCR message, and the SAME CCR should be send to secondary on such case. The CCR message should be same in this case.
The Problem is, when the stack check the connection with the primary and secondary peer, it keep the primary peer up in the stack. Every time the request will go to the primary, even in case of a timeout.
How can i redirect the same CCR to secondary which was not being responded by primary peer? According to my understanding, i have to some how remove the primary peer for the top of stack and keep the secondary on the top of stack.
But i have very little idea how to do it, keeping the stack initialized.
Kindly suggest.
Thank You!
Best Regards,
PIYUSH
Hi Piyush
DeleteAs i have suggested you that traffic shall only go to secondary peer only when there transport connection failure. Timeout not equal to transport connection failure. It happens generally because of Load.
As suggested,use a DRA, to distribute load on two instance of Server Application. Make configuration in DRA that 50% of traffic shall go on instance one and rest on instance two(that's just an example)
Or make direct connections (Primary connection) with each server instance from your client application. By treating those two instance as two different nodes.
(For Example)
Now let your client application to assign Origin Host of first application to first request message generated by your application and assign Origin Host of second application to second request message and then assign Origin Host of first application to third request message and so on if possible.
Thanks for your query.
Happy to help you again.
Team-Diameter
How peer should behave when it recive the disconnect request from other side with different disconnect cause (0,1,2)
ReplyDeleteIn any scenario peer will close the connection via sending(DPA- disconnect peer answer) after receiving the disconnect request from another peer or continue the connection.
Regards,
pulkit Garg
Hi Pulkit
DeleteSwarup has given the ideal reply.
Thanks Swarup for best possible answer
Regrads,
Ajay
Hi Pulkit,
ReplyDeleteStandard doesn't says explicit pertaining to above; it can be inferred that peer shall return the DPA with result-code set to "DIAMETER_INVALID_AVP_VALUE" because Disconnect-Cause AVP is a mandatory AVP in DPR request. And value of one of the mandatory AVP is incorrect.
Hi All,
ReplyDeleteWhat instances triggers DPR from SDC?
Can a peer send DPR to SDC?
-Dom
Hi Dom,
DeleteProbable causes to trigger DPR are given. Can you explain more what's your point.
Kindly tell what is SDC?
Thanks for your query.
Happy to help you again.
Team-Diameter
Hi Team,
DeleteSorry about that - SDC - is just a diameter agent.
What I was trying to ask was, for what messages does the diameter agent sent dpr..
I have scenario where the diameter agent sends DPR after it receives a CEA with 5012 message. Since the CEA is not successful, should the diameter agent be still sending DPR?
Thanks in advance!
-Dom
Hi Dom,
DeleteRFC-6733 tells, If CEA does not contain DIAMETER_SUCCESS, then SHOULD disconnect the transport layer connection.
DPR is not expected, but could be implementation specific. Kindly share Disconnect-Cause AVP value in DPR for better view of issue.
Thanks for your query.
Happy to help you again.
Team-Diameter
Team,
DeleteThe Disconnect-Cause is DO_NOT_WANT_TO_TALK_TO_YOU(2)
Thanks for all the help.
-Dom
Happy to help you again.
DeleteTeam-Diameter
Hello Diameter-Team
ReplyDeleteFirst , many thanks for great website . the information is very helpful.
We have implemented the Diameter protocol and developed a DCCA server which works fine with one client on the same machine ...
I have a basic question regarding the P2P protocol , can we enable two or more clients on the same IP address to communicate with the Server ?
Regards,
Golan
Hi Golan,
DeleteYes, it is possible that two client have same IP address communicating with same Server but Port No. of both the client should be different.
For detailed information please visit following links.
http://diameter-protocol.blogspot.in/2013/08/diameter-connection-establishment.html
http://diameter-protocol.blogspot.in/2012/12/introduction-to-tcp.html
Thanks for your query.
Happy to help you again.
Team-Diameter
Thank you for your quick reply .
ReplyDeleteGolan
Hello -
ReplyDeleteThe Diameter Spec specifies the following:
“A given Diameter instance of the peer state machine MUST NOT use more than one transport connection to communicate with a given peer, unless multiple instances exist on the peer in which case a separate connection per process is allowed.”
A peer is identified by its Origin-Host AVP from CER.
Is there any good reason to have this limitation of 1 transport connection per peer ?
Multiple connections between peers could be useful to multiplex peer traffic on multiple connections so it supports the load. E.g between 2 DRA, we may have 60000 Messages per sec to handle - while each TCP/IP connection has a throughput limiting the traffic to 5000 msg/sec - how is this handled ?
Hello
ReplyDeleteIs there a way to indicate not to send more messages? In scenarios, for statefull applications, 2 frontends might server a given server. If an entity of the cluster is required to be rebooted, is there a way in the protocol for informing the peering element it will go offline in given time?
Regards
Hi Sergio
DeleteAny entity can initiate DPR to its peer with { Disconnect-Cause } set to Rebooting. So that peer can take actions as configured by vendor (Like storing state etc.)
Above article is there to help you. Hope we suffice your query.
Thanks for your query.
Happy to help you again.
Team-Diameter
How to reconnect after DPR/DPA
ReplyDeleteHi
DeleteReconnection after DPR/DPA shall be fresh(New) Connection it shall start with CER/CEA exchange.
Thanks for your query.
Happy to help you again
HI,
ReplyDeleteCan you change "to connection per REALM" to "two connections per REALM".
Br,
Shashi Kant Santosh
hey,
ReplyDeletewhen we send DPR and how do we know that now DPR will send?
Hi Diameter Team,
ReplyDeleteI am a noobie with Diameter however I read the RFC 6733. Had a query
Just wanted to know how would I recognize who all are my peer after peer-discovery procedures. Is the unique information diameterIdentity, Origin-Host, Origin-Realm or is there something else
Hi
DeleteThese information shall be populated in Peer and Realm Table.
Following links shall help you.
https://diameter-protocol.blogspot.com/2013/09/election-process.html
https://diameter-protocol.blogspot.com/2011/07/peer-table-explained.html
Thanks for your query.
Happy to help you again.
Team-Diameter