Re: M3UA: Message Length

On Oct 10, 2013, at 11:40 AM, santosh nayak <[email protected]> wrote:

> Hi,
> 
> 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??? Please comment on this...
At least the behaviour of the sender is not expected, since the sender
violates a MUST.

Best regards
Michael
> 
> 
> 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.
> 
>  
>    Note: A receiver SHOULD accept the message whether or not the final
> 
>    parameter padding is included in the message length.
> 
> ---------------------
> 
> 
> 
> Thanks,
> Santosh
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sigtran