M3UA message Length issue

Question

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. 

Answer 1

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

Answer 2

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.