Re: M3UA: Message Length

> From: [email protected] [mailto:[email protected]] On Behalf Of Michael Tuexen
> 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.

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

> > 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.

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.

	David