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

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

A comment about my statement that message boundary can´t be detected in
certain cases between multiple M3UA messages:
In fact it seems it can be: Padding is done with 0 and the first octet of
the message header (version) has a value of 1(and I assume it never will go
down to 0). So, just scan till 1 is found.

But I still find it strange that including padding bytes in message length
is a MUST and expecting the opposite is a SHOULD.
    Tolga

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)

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

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

---

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

Tolga,

TOLGA ASVEREN wrote:                                                                 (Fri, 07 Feb 2003 11:30:06)
> is a MUST and expecting the opposite is a SHOULD.

It's just the be_strict_on_what_you_send_and_be_forgiving_on_what_you_receive
principle.

--brian

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