Subject: Re: m2pa header

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 27 Aug 2001 17:49:30 -0500

Wayne,

The LI byte is not part of the M2PA Common Header: it is the first
byte of the User Data message contents.  The M2PA Common Header is
always 8 bytes.  This is the way that it is decribed in the M2PA-03
draft: the definition for the Common Header does not include any
mention of LI byte.  The payload of the User Data message does
describe the first byte of the payload as being the LI byte.  There
is no change whatsoever in the size of the M2PA Common Header for
any message type.  Alignment of the start of the M2PA message
contents occurs on an 8-byte boundary for all M2PA messages.  It
just so happens that the first byte of the contents of the User Data
message happens to be the LI-byte, which is nicely aligned on an
8-byte boundary (as though it matters or not).

There is no room for your intepretation here that the M2PA Common
Header is somehow 9 bytes at times: it is defined as 8-bytes and
8-bytes only.

There is no inconsistency here between M2PA messages and placing a
pad inside the User Data message before or after LI or whatever will
not change the alignment of User Data with respect to the M2PA
Common Header: all it will do is change the alignment of some User
Data message contents to other User Data message contents.

No processor inefficiency will result and there is certainly no need
to arbitrarily place padding here or there within the User Data
message, as indeed the User Data contents are bit-oriented in all
cases.

--brian

wayne n taylor wrote: (Mon, 27 Aug 2001 18:31:24)
> 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
[email-masked]
http://www.openss7.org/

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