Subject: Re: m2pa header

From: wayne n taylor <[email-masked]>
Date: Mon, 27 Aug 2001 18:31:24 -0400

Brian,
typically network protocol headers that are architect with an odd
number of bytes are viewed as inefficient for reads an writes. not that
this cannot be overcome with software in most cases, but having headers
end on even boundaries simplifies implementations.

my interpretation of the m2pa header from draft 3 is as follows (correct
me if i am wrong):

1. when the network is TTC, the "LI" field is included as part of the
mtp3
data from mtp3. m2pa does not add yet another LI field in this case does
it ?. if not, this gives us an 8 byte m2pa header. in this case m2pa
does
not even have to be aware that the LI field exists.

2. for networks that do not include an "LI" field with the mtp3 data,
m2pa adds a one byte LI field, making the m2pa header 9 bytes in
length. 

there seems to be some inconsistency between these two cases (assuming
my 
interpretation of the draft is correct). in case 1 the LI field is not
part of m2pa, in case 2 the LI field is part of m2pa.

i understand you point about preserving the alignment of the LI field
with current ss7 links. although m2pa attempts to seamlessly replace
mtp2
links, there are inherent differences between the two and i would trade
header alignment over field preservation.

wayne t

"Brian F. G. Bidulock" wrote:
> 
> 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]

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