Subject: [Sigtran] Packing M3UA messages into SCTP ULPDUs

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Feb 2003 01:05:40 -0700

Sigtran,

Where does it say that only one M3UA message may be
placed into an SCTP ULPDU?

As messages contain the length in the header, can I
pack two or more M3UA messages in an SCTP ULPDU?

This is so basic, I wonder why it was not mentioned
anywhere...

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "TOLGA ASVEREN" <[email-masked]>
Date: Fri, 7 Feb 2003 14:25:51 +0200

resending......

I also think that it is a good idea to clarify this in IG.

 Tolga
--- "Brian F. G. Bidulock" <[email-masked]> wrote:
> Tolga,
>
> It does not even forbid splitting an M3UA message
> across multiple
> SCTP ULPDUs.
>
> I think this should be clarified in the IGs for the
> sake of
> interoperablity.  1 M3UA (M2UA, SUA) message to 1
> SCTP ULPDU.
>
> TOLGA ASVEREN wrote:
>                                 (Fri, 07 Feb 2003
> 11:05:52)
> >
> > Brian,
> > > Sigtran,
> > >
> > If it is not forbidden, shouldn´t it be
> interpreted as allowed (although I
> > would guess that most of the implementations are
> assuming one M3UA message
> > in one SCTP ULPDU)?
> > BTW related with this topic:
> > from 3.1.4
> >   "The Message Length defines the length of the
> message in octets,
> >    including the Common Header.  The Message
> Length MUST include
> >    parameter padding bytes, if any.
> >
> >    Note: A receiver SHOULD accept the message
> whether or not the final
> >    parameter padding is included in the message
> length."
> > The above paragraphs sound strange to me,
> including padding bytes in the
> > length is a MUST but still receiver should be
> prepared for the opposite.
> > But still based on that I assume a M3UA peer can
> receive messages, whose
> > length does not contain padding bytes (otherwise
> forget what stands below)
> > >From 3.2
> >      "The total length of a parameter (including
> Tag, Parameter Length
> >       and Value fields) MUST be a multiple of 4
> bytes.  If the length of
> >       the parameter is not a multiple of 4 bytes,
> the sender pads the
> >       Parameter at the end (i.e., after the
> Parameter Value field) with
> >       all zero bytes.  The length of the padding
> is NOT included in the
> >       parameter length field.  A sender SHOULD NOT
> pad with more than 3
> >       bytes.  The receiver MUST ignore the padding
> bytes."
> > Not to add more than 3 padding bytes is a SHOULD
> NOT, not a MUST.
> >
> > For a scenario where message length does not
> contain padding bytes length
> > and more than 3 padding bytes are used, I would
> think receiver can´t detect
> > boundary between two M3UA messages (but I have to
> repeat, it sounds strange
> > to me that including padding bytes length in
> message length is a MUST and
> > still receiver SHOULD accept messages, which
> aren´t prepared in that way)
>
> One could still detect the next message by scanning
> for the next valid
> M3UA message header...
>
> Also, that wouldn't cause any problem for splitting
> an M3UA message across
> several SCTP ULPDUs.
>
> I think we need to state in the IG: 1 UA message, 1
> SCTP ULPDU.