top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

M3UA message Length issue

+1 vote

We have a situation where message is being rejected at M3UA layer due to buffer length is not equal to message length.

What is the significance of Message Length and its importance with padding... in the current issue M3UA peer is sending the data buffer of size 122 bytes to KSCTP. But message length parameter of M3UA common header contains a value of 124 and KSCTP is doing the padding at its level of 2 bytes which is observed from the wireshark traces.

Now at DUT message droped with reason (message length parameter is greater than actual M3UA data buffer size). Is this expected?

As per RFC 4666 ------------------------
    3.1.4.  Message Length: 32-Bits (Unsigned Integer) 
       The Message Length defines the length of the message in octets, including the Common Header. 
       The Message Length MUST include  parameter padding octets, if there are any. 
posted Oct 10, 2013 by Sumit Pokharna

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

2 Answers

+1 vote

At least the behavior of the sender is not expected, since the sender violates a MUST.

answer Oct 10, 2013 by Mandeep Sehgal
+1 vote

1) Are you sure that pad isn't just from SCTP aligning it's chunks?

2) I'm not sure what the note in section 3.1.4 is trying to allow, but I think the message you are describing is definitely illegal.

I believe that the overall length in the 'common' header should always match that of the SCTP data chunk.
This allows M3UA data to be separated into messages when sent using (say) TCP rather than SCTP.

I suspect the note allows an implementation to add the pad (following a parameter) when it adds a new one, rather than when it adds a parameter that isn't a multiple of 4 bytes.

In any case I'd change your sending end.

answer Oct 10, 2013 by Deepak Dasgupta
Similar Questions
0 votes

I was referring the rfc4666 for M3UA and have few concerns regarding the DUPU SSNM message. The specification says that a DUPU indicates the unavailability of a certain user part.
If I may quote "The DUPU message is used by an SGP to inform concerned ASPs that a remote peer MTP3-User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable"
I have two questions.
1. How these concerned ASPs are identified. Is it upon receiving a MTP-Transfer for a particular user part (say SCCP) or can it be sent periodically for a given ASP ?
2. I could not find any SSNM message that indicates a User Parts Availability. Am I wrong here to expect such a message and if so how come a concerned ASP know if a certain User Part is available at a given point code.

It would be an immense help if anyone could clarify the aforementioned concerns.

+4 votes

Assume you have the conditions (one AS, etc.) to allow RC to be optional, does the RFC permit one side (IPSP SE mode for example) to still send an RC and the other to not include an RC? I think the answer is yes, but I can't find an explicit reference permitting it.

+1 vote

Going thought the RFC 3332 and have a doubt about RC, in M3UA we have a concept of routing context to identify an AS but same can be achieve by the routing Key (it seems) then what the purpose RC is serving.

+1 vote

Can one implementation support single exchange and double exchange models of IPSP at the same time ? Or does it have to be configured and only one of the models can be active at a time ? Is there any M3UA procedure which can help in dynamic negotiation of SE/DE models.