Subject: Re: [Sigtran] Packing M3UA messages into SCTP ULPDUs

From: "TOLGA ASVEREN" <[email-masked]>
Date: Fri, 7 Feb 2003 11:48:47 +0200

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

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 7 Feb 2003 22:56:44 +0100

Dear all,

as far as I know all adaptation layers MAY run over TCP. That is
why all messages have a length field. But when run over SCTP
it does not make any sense to me not to put exactly one adaptation
layer packet in one DATA chunk.

I think it is not 'unclear' but never stated explicitly. No one
send multiple upper layer packets in one DATA chunk, or half of
it, or 1 and a half. I also have never received a bug report for
ethereal stating that such behaviour is not supported. Ethereal
expects exactly one upper layer packet in one DATA chunk.

This SHOULD be clarified for ALL SIGTRAN adaptation layers, but does
not change the current understanding.

Best regards
Michael

---

From: Ken Morneault <[email-masked]>
Date: Fri, 07 Feb 2003 17:10:25 -0500

Another piece of information to add to Michael's points...

No implementation at any of the Interops (M3UA/SUA/M2UA/
IUA/M2PA) has (to my knowledge) ever sent more than on
UA message in one SCTP DATA chunk.

Regards,

Ken

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Feb 2003 15:23:16 -0700

Michael,

It is not one message in one DATA chunk.  As you know,
a DATA chunk without both the B and E flags set does
not represent an entire SCTP ULPDU.

If it is stated, it should be state clearly as 1 msg
to 1 SCTP ULPDU (and define SCTP ULPDU if there is no
better term).

--brian

Michael Tuexen wrote:                                                              (Fri, 07 Feb 2003 22:56:44)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Feb 2003 16:28:09 -0700

Michael,

You do not think its unclear, but should be clarified?

--brian

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 8 Feb 2003 10:51:00 +0100

Brian,

I was thinking of short SS7 messages, thus no fragmentation is needed.

But you are correct, I mean one adaptation layer PDU as one SCTP
user data.

Best regards
Michael

On Friday, Feb 7, 2003, at 23:23 Europe/Berlin, Brian F. G. Bidulock

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 8 Feb 2003 10:54:46 +0100

Brian,

I think it is clear to all people today, because of the reasons I gave 
and
the one Ken gave.

But I agree that it is not written somewhere and at least you thought 
about
it. A clarification does not hurt... This might be helpful for people 
staring to
work on SIGTRAN in the future without knowing the history of it.

We have such stuff also in the SCTP IG.

Best regards
Michael

On Saturday, Feb 8, 2003, at 00:28 Europe/Berlin, Brian F. G. Bidulock

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 8 Feb 2003 03:30:47 -0700

Michael,

So you think it is clear, but a clarification wouldn't hurt? ;)

--brian

Michael Tuexen wrote:                                                              (Sat, 08 Feb 2003 10:54:46)