top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Is sequencing a concern in Diameter

+2 votes
433 views

It seems to me that out of order delivery is possible in Diameter even in simple networks (SCTP unordered delivery, for starters), that in more complicated networks there are even more opportunities for out of order delivery, and that overload situations might make usually small time gaps bigger.

Can anyone clarify this (is sequencing a concern, and if not then why)?

posted Aug 2, 2013 by Sanketi Garg

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

1 Answer

+3 votes
 
Best answer

Yes, it is possible that requests/answers may be delivered out of order, especially when they take different paths due to network problems.
In some session based applications (Ro, DCCA), PDUs carry request number. Application level logic can use this field if sequence is important.
In cases where request/answer complete a transaction, generally order wouldn't matter. But applications can always build in additional logic.

answer Aug 6, 2013 by Rathnakumar Kayyar
Similar Questions
+3 votes

When SCTP layer itself takes care of heartbeat ack-nack then why does diameter watchdog mechanism is required at the application layer ?

+3 votes

I have a query on SCTP guidelines for Diameter base protocol specified in section 2.1.1 of RFC 6733 as :

"A Diameter agent SHOULD use dedicated payload protocol identifiers (PPIDs) for clear text and encrypted SCTP DATA chunks instead of only using the unspecified payload protocol identifier (value 0). For this purpose, two PPID values are allocated: the PPID value 46 is for Diameter messages in clear text SCTP DATA chunks, and the PPID value 47 is for Diameter messages in protected DTLS/SCTP DATA chunks."

RFC doesn't specify the behavior if the connected diameter peer doesn't use PPID as 46/47 for diameter message transport over SCTP or DTLS/SCTP. What if diameter messages are received with PPID set to value other than 46/47 or default 0 value? Should the messages be ignored or respond with error diameter message back to peer with same PPID set ? Please comment on this behavior.

+2 votes

I want to run the diameter over public network with SCTP protocol.

I am facing issue as :-
PCRF public IP is 115.x.x.x
PCRF private IP is 172.x.x.x

  1. SCTP INIT message from the PCEF is coming to my public IP & getting successfully NATTED & I am getting request on private IP.

  2. PCRF sends SCTP INIT_ACK , but in the IPv4 field (inside INIT_ACK), it sends my private IP.

  3. So, after receiving this message, PCEF sends COOKIE_ECHO message to my private IP ( because it is there in INIT_ACK message)

Because of this I don't receive the COOKIE_ECHO message & so the SCTP connection doesn't work. Anybody has faced this issue before & has any resolution? Also, is the diameter with SCTP is possible over public network?

+3 votes

I have a query/doubt on below section of RFC 6733: 1.1.3

Changes from RFC 3588:

" Deprecated the exchange of CER/CEA messages in the open state.

This feature was implied in the peer state machine table of RFC 3588, but it was not clearly defined anywhere else in that document."

Scenario: In case a diameter node using SCTP association and does a restart procedure according to RFC 4960, section 5.2.4.1. Can the node (the one restarted the association) send CER on the association?

From the above RFC-6733 description it looks to me that the node which restart the association should not send CER, is my understanding correct? Please comment on this!

0 votes

Is it possible that MCC MNC gets changed in the same Diameter session without changing session ID while in Roaming???
As I have come to across an unsupported scenario when some users are roaming in Iceland operator MCC MNC and suddenly switch to different operator MCC MNC which belongs to the USA within the same DCCA session i.e without closing the PDP context and opening a new one (that should not be possible, unsupported scenario). Is it possible??? I'm confused here.

...