IETF Logo Mail Archive

Re: [Sigtran] M3UA: Message Length

"David Laight" <David.Laight@ACULAB.COM> Thu, 10 October 2013 12:28 UTC

Return-Path: <David.Laight@ACULAB.COM>
X-Original-To: sigtran@ietfa.amsl.com
Delivered-To: sigtran@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA0021F9634 for <sigtran@ietfa.amsl.com>; Thu, 10 Oct 2013 05:28:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUE-epxLqBnq for <sigtran@ietfa.amsl.com>; Thu, 10 Oct 2013 05:28:51 -0700 (PDT)
Received: from mx0.aculab.com (mx0.aculab.com [213.249.233.131]) by ietfa.amsl.com (Postfix) with SMTP id 6448421E8102 for <sigtran@ietf.org>; Thu, 10 Oct 2013 05:28:49 -0700 (PDT)
Received: (qmail 12301 invoked from network); 10 Oct 2013 12:28:43 -0000
Received: from localhost (127.0.0.1) by mx0.aculab.com with SMTP; 10 Oct 2013 12:28:43 -0000
Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 04822-07 for <sigtran@ietf.org>; Thu, 10 Oct 2013 13:28:42 +0100 (BST)
Received: (qmail 12284 invoked by uid 599); 10 Oct 2013 12:28:42 -0000
Received: from unknown (HELO saturn3.Aculab.com) (10.202.163.5) by mx0.aculab.com (qpsmtpd/0.28) with ESMTP; Thu, 10 Oct 2013 13:28:42 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 10 Oct 2013 13:27:11 +0100
Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B7388@saturn3.aculab.com>
In-Reply-To: <1448C90C-907A-4DE1-8C0A-85C020E71DD2@lurchi.franken.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sigtran] M3UA: Message Length
Thread-Index: Ac7FsOBT4fBhZRs+SNWW41T+Ubb3aAAAb1jA
References: <CAOwWmo1iRu94iAakEGcFLMymaAmtMHTmE+pY5UQttoVHWaFNVQ@mail.gmail.com> <1448C90C-907A-4DE1-8C0A-85C020E71DD2@lurchi.franken.de>
From: "David Laight" <David.Laight@ACULAB.COM>
To: "Michael Tuexen" <Michael.Tuexen@lurchi.franken.de>, "santosh nayak" <santosh.nayak69@gmail.com>
X-Virus-Scanned: by iCritical at mx0.aculab.com
Cc: sigtran@ietf.org
Subject: Re: [Sigtran] M3UA: Message Length
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Oct 2013 12:28:58 -0000

> From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Michael Tuexen
> On Oct 10, 2013, at 11:40 AM, santosh nayak <santosh.nayak69@gmail.com> 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

v2.8.7 | Report a Bug | By Email