Subject: Re: m2pa header

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 27 Aug 2001 15:46:40 -0500

Wayne,

What I was trying to get at was that if the LI byte is removed,
or if it is padded, that it will change the alignment of the MSU
from the existing alignment which is experienced by an
implementation for SS7 low-speed links today.

I really think that the alignment is rather moot, particularly
because the MSU itself has no inherent byte alignment far less
alignment on a multiple byte boundary.  SS7 is a bit-oriented
protocol and many of the fields of the MSU span byte boundaries
on a bit basis (e.g, 14-bit point codes).  As such, there are
few efficiencies to be had in any byte alignment of the MSU, and
the impact on any architecture of any given alignment is minimal
at worst.

What efficiency did you think would result from any given
alignment of the MSU for any processor archiecture?

--brian

wayne n taylor wrote: (Mon, 27 Aug 2001 16:28:59)
>
> Brian,
>
> are you saying an "LI byte" is included with the data that comes
> from mtp3 when used by TTC ?. if that is true, okay. what about
> the ss7 versions that dont include "LI data" with mtp3 ? is m2pa
> required to add a LI field with the all the bits set to 0 ?. if
> m2pa adds a byte between the m2pa common header and the mtp3 data,
> then the data would start on an odd byte boundary.  if m2pa does
> not need to add an LI field for ss7 versions that dont include "LI
> data" with mpt3, then that works okay too, but the wording used in
> draft 3 that makes references to the format of the m2pa LI field
> is confusing .....
> 
> wayne t
> 
> "Brian F. G. Bidulock" wrote:
> > 
> > Wayne,
> > 
> > The LI and particularly the LI-spare bits when used by TTC as MP bits,
> > *are* the data payload.  The LI byte *is* aligned on a 2-byte boundary.
> > This is no different than low-speed SS7 links which have two bytes
> > (BSN/BIB, FSN/FIB) before the LI bits.  This is completely consistent
> > with SS7 message parsers which expect LI on a 2-byte boundary just as
> > with SS7.
> > 
> > The LI bits themselves may be rather useless (the Common Message Header
> > length indicates more definitively the length of the MSU), but it is the
> > LI spare bits which are interpreted as part of the MSU for TTC.
> > 
> > Because the alignment of the MSU is the same as for low-speed links (at
> > least 2-byte boundary if not 4-byte boundary), there should be no
> > processor architecture performance impact when compared to existing SS7
> > link types.
> > 
> > --brian
> > 
> > wayne n taylor wrote: (Mon, 27 Aug 2001 14:58:30)
> > >
> > > everyone,
> > >
> > > the length indicator field that follows the m2pa common header causes
> > > the message data to start on an odd byte boundary. starting data on an
> > > odd byte boundary can be less than optimal for some machine
> > > architectures. one proposal to eliminate starting on an odd byte would
> > > be to add a pad byte.  another option would be to make the li field
> > > two bytes (expanded li field) ??
> > >
> > > wayne t
> > >
> > 
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> > 
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to [email-masked]
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

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

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]