top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Number of transport connections among two Diameter peers

+3 votes
413 views

I have a question on the interpretation of following paragraph from RFC 6733 section 2.1 "Transport":

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.

My interpretation is that it refers to the possibility for two Diam. peers (each of them identified by its "valid" Diameter Identity - as set in section 5.1-) to establish more than one transport connections (i.e. several TCP connections or several SCTP associations -e.g. the "initiator/client" using different TCP/SCTP source ports for each of them-).

In line with this, also CER/CEA, DWR/DWA and DPR/DPA procedures must be managed per established TCP conn/SCTP assoc (as set in section 5.6) ... but (Diameter) Application specific request and answers can be sent from one peer to the other using whatever transport connection established among them (for the shared/common supported Application-Ids, of course).

Could you confirm this is the shared understanding?

A part from that, in that case, I got the following question: is it mandated that responses are sent through the same transport connection from where the (related) request-command was received?

posted Oct 17, 2013 by Kumar Mitrasen

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote

Whatever is written above is correct explanation. Yes it is mandated and always mandated.

Now what you are talking:
At a time with one peer we can use maximum one transport, that is the rule of client-server communication. If you have received any request with one transport it means you did handshake with say TCP so you have to reply with same transport. You don't have SCTP association with other.

If SCTP association has been developed then it means TCP connection is not there.

This is what if i think in other way: Just for knowledge
Very simple if the request is processed from TCP it means its encapsulated with TCP protocol then how SCTP can decapsulate this layer ?

Another reason is if you don't have same transports on both ends then it is not even possible to reach at application. first transport handshakes would happen then only it is possible to exchange messages in between them.

answer May 7, 2014 by Hiteshwar Thakur
Similar Questions
+1 vote
How can send diameter commands in two sessions?

I am designing a seagull scenario look like:

Client --------------- Server
--- CER -->
<-- CEA --- --- AAR --> // the first session
<-- AAA --- --- AAR -->
<-- AAA -- <-- RAR -- --- RAA -->
--- STR -->
<-- STA -- --- AAR --> // the second session
<-- AAA -- <-- RAR -- --- RAA -->
--- STR -->
<-- STA --

But in the second call, we saw an message in log "Expected AAR when receiving RAA.." . If we make the second call scenario same as the first call, (two AAR\AAA and one RAR/RAA) it was passed.

So that the question is "Is there any ways to control seagull flow as the scenario that we expected? "

+1 vote
In what scenarios, a diameter node maintains two connection with peer ?

I went through an article of diameter, it mentions " Diameter standard advises that a diameter node to maintain two connection primary and secondary connection". Diameter node uses first connection in normal conditions and go for second one if primary connection is abrupted or not available. How far it is correct and where it is used exactly ?

+4 votes
Why failover should happen if an primary and secondary peers are not relevant?

I have a discrepancy for a failover indication. In RFC 3588, it has written if a message

Since the CER/CEA messages cannot be proxied, it is still possible that an upstream agent receives a message for which it has no available peers to handle the application that corresponds to the Command-Code. In such instances, the ’E’ bit is set in the answer message (see Section 7.) with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER to inform the downstream to take action (e.g., re-routing request to an alternate peer).
In such instances, the ’E’ bit is set in the answer message with the Result-Code AVP set to
DIAMETER_UNABLE_TO_DELIVER to inform the downstream to take action (e.g., re-routing request to an alternate peer).

My query starts from here. If 1st peer is not supporting the Application ID then why it should try for alternate peer? Because it would be same peer then why failover should happen?
Eg.: If in Gx interface PCRF and PCEF. PCRF has forwarded the CCR message to HSS instead of PCEF and has got the reply 3002. Then for obvious reason HSS alternate peer would be another HSS. In this case failover should happen ? Can anybody tell me in this scenario what is right to do ?

0 votes
Diameter Charging: Redirecting data session of End of Credit

When the credit of a prepaid subscriber is exhausted, as specified in the 3GPP Diameter spec for Gy interface (32.229), the OCS can instruct the PGW to redirect the user traffic to a TopUp server.
It is done by the OCS by setting the value of the Final-Unit-Action AVP to the Redirect value (1) and providing the Redirect-Server AVP in the CCA (Credit Control Answer) Diameter message.
Are we talking about standard HTTP redirection?
Can this traffic redirection work in case of HTTPS user traffic?

...