Subject: RE: M3UA Issue 4: Payload Format - poll

From: Lyndon Ong <[email-masked]>
Date: Mon, 24 Sep 2001 18:08:09 -0700 (PDT)

Folks,

Sending again, first time disappeared...

We seem to be pretty evenly divided into 
two solutions:

1) payload 1/2, where the contents of the
MTP message are send as the payload in M3UA,
starting at either the SIO (1) or the LI (2).
(I would like to cut this down to a single
format if possible, either (1) or (2)).

2) payload 3, where the DPC, OPC and SIO/SLS/Priority
are broken out into separate 4-byte subfields and
then the remaining User Data forms the rest of
the payload.

Ideally we would agree on one format and agree
to always support this, but we can't seem to agree, 
so we need to consider two formats and how to 
support this.

Possible actions:
-- leave this up to configuration of the two endpoints
-- make this part of registration
-- add some kind of error procedure to indicate
   when the remote end does not support the format
   you are sending

Comments?  Let's try to clean this up by Wednesday
so it can go into M3UA version 9.

Cheers,

L. Ong

--- [email-masked] wrote:
> Lyndon,
> 
> We must be careful here. I think your interpretation
> is wrong. There is a 
> disconnect in the ITU documents, which leaves an
> opening for different 
> interpretations.
> 
> Table 1/Q.701 refers the reader to 2.3.8/Q.703 for a
> definition of "User 
> Data". However 2.3.8/Q.703 refers to "Signalling
> Information Field", and 
> doesn't mention "User Data" at all.
> 
> You are saying that "User Data" includes the entire
> SIF, but both Brian, 
> in his Data 3 proposal from July 27, most other
> interpretations that I 
> have seen, say that "User Data" includes only that
> part of the SIF that 
> comes AFTER the routing label. For example, In
> Brian's proposal for Data 
> format 3, the last field is Protocol Data, defined
> as:
> 
>  "a byte string of MTP-User information from the
> original SS7 message 
> starting with the first byte of the original SS7
> message following the 
> Routing Label."
> 
> Actually, after looking at this a second time I
> think that Brian is 
> correct and that you and John are not. For ease of
> transmission to the MTP layers, we should stick with
> Brian's 
> interpretation. Thus format 3 should be
> 
> OPC
> DPC
> SLS/SIO/(priority)
> User Data (starting with the first byte of the
> original SS7 message 
> following the Routing Label)
> 
> 
> Barry Nagelberg
> 
> 
> 
> 
> 
> Lyndon Ong <[email-masked]>
> 09/24/01 02:16 PM
> Please respond to sigtran
> 
>  
>         To:     "sigtran"
> <[email-masked]>
>         cc: 
>         Subject:        RE: M3UA Issue 4: Payload
> Format - poll
> 
> 
> Folks,
> 
> Let's try and clarify Payload 3, then.
> 
> The MTP-Transfer primitive from Q.701 lists
> the following contents:
> OPC
> DPC
> SLS
> SIO
> User Data
> 
> User Data references section 2.3.8 of Q.703,
> which describes the Signaling Information
> Field, which includes the routing label 
> (DPC, OPC, SLS).
> 
> If payload 3 follows the format of the MTP-
> Transfer primitive it would have
> OPC
> DPC
> SLS/SIO/(priority)
> User Data
> 
> where User Data provides the SIF.  Is that
> what people need for payload 3?
> 
> Cheers,
> 
> Lyndon
> 
> 
> --- [email-masked] wrote:
> > John is right about the Data msg receiver having
> to
> > reformat. I thought 
> > that Data 3 RL parameters were IN ADDITION to the
> > MTP3-TRANSFER primitive. 
> > However, after looking again at Brian's Data 3
> > proposal from August 9, I 
> > now realize that this is not the case.
> > 
> > I would support Data format 3 only if the RL
> > parameters were IN ADDITION 
> > to the complete MTP3-TRANSFER primitive.
> > 
> > Barry Nagelberg
> 
> 
> 
> 
> 
> 
> 
> ---
> You are currently subscribed to sigtran as:
> [email-masked]
> To unsubscribe send a blank email to
[email-masked]

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com

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

---

From: Lyndon Ong <[email-masked]>
Date: Mon, 24 Sep 2001 15:14:15 -0700 (PDT)

Hi Barry,

Your interpretation obviously avoids
carrying the routing label twice, 
although I was waiting for someone
supporting payload 3 to speak up.

We seem to be pretty evenly divided into 
payload 1/2 vs. payload 3 views.  My
personal preference would be to settle
on one format, since otherwise people 
would probably need to support multiple
formats for interoperability.

However, if people are unwilling to
give up one or the other, we should at
least cut this down to 2 formats.

Payload 1 would carry the MTP message 
starting with the SIO, unchanged from the
received message, i.e., with DPC, OPC,
etc. formatted as in the corresponding
variant of SS7.
 
(NOTE: alternatively, we could start from
the Length Indicator to take into account
the Japanese TTC standard).

Payload 3 would carry a "normalized" MTP
message with DPC, OPC and SIO/Priority/SLS
broken out into separate 4-byte sub-fields 
before the remaining User Data.

Comments?  Let's see if we can at least
reach some agreement on what will be in 
M3UA v9.

Cheers,

Lyndon

---