Re: Sigtran Digest, Vol 46, Issue 5

LI,

LI Xinyan wrote:                           (Tue, 26 Feb 2008 10:29:08)
> Hello, Brain
> 
> I don't agree with you.
> 
> brain wrote:                              (2008Äê2ÔÂ25ÈÕ 16:30)
> >Be very clear: when you are using the ASP/SG configuration,
> >the SG is simply backhauling its local MTP/MTP-User interface
> >to the ASP.
> 
> [lxy]
> You are the author of M2UA? M2UA is a complete backhauling
> protocol. 

You haven't done your homework: I authored M3UA as well.  I
count 2 message from 'xinyan' on the SIGTRAN archive and 6330
from 'bidulock'.  My first post (that I kept) was June 16, 1999
(MDTP for IP-base traffic).

> But M3UA has more wide use than M2UA, it can apply to
> backhauling scenario, and also STP like scenario.

You're welcome.  I asked the WG to kick it out or make it work
back around draft-07 and found myself in the position of making
it work.  Nevertheless, the multiple SG as STP configuration is
a backhaul configuration.  The IPSP configuration only supports
point-to-point IP domain communications with not gateway involved.

Nevertheless, I agree more now with Tolga in that STP's are
unnecessary in the all IP domain.  Use DNS instead.  Try ENUM.
The redundancy that was afforded by STP's is better performed in
the all-IP domain by simple multihomed SCTP.

> That is why M3UA is recommended in 3GPP not M2UA, We wish we
> can extend M3UA in order to apply SIGTRAN more widely in
> Mobile Network.

Really.  I think that ETSI simply rubber-stamped it (I think it was
draft-07 or -12 at the time) and didn't give it much thought to
it after the bust.  As I recall, they did so in a rush, did not
have the time to accept the technically superior (for
SCCP/GSM-A) SUA protocol despite the protestations of those
working on SUA in this forum and within the 3GPP standards
bodies as well.

You are still welcome to write an extension draft (as an
individual) and have it considered here.  I warn you the subject
matter will have to be technical instead of standards body
grandstanding and filibusting.
 
> Not say"SG-SG", even for "SG-ASP", current M3UA has
> shortcoming in SSNM handling.  M2UA can inherit the management
> of SS7, but M3UA cann't. So this part of M3UA should be
> strengthened.

Provide some technical details please on the solution you
propose.  Maybe even write it up as an internet draft.  I look
forward to commenting on the technical sufficiency of your
proposal.

> 
> I totoally agree with Tolga's opinion.
> "
> >BTW, it is a pitty/shame we couldn't evaluate M3UA SG-SG/M3PA
> >ideas properly in this WG, as this seems to me exactly what
> >people out there are looking for (and possibly would allow
> >them to use a single protocol throughout their networks,
> >rather than a M3UA/M2PA hybrid).

Your welcome again: (I coined the term M3PA and coauthored the
SG-SG draft with Tolga).  You should read it.  As I recall one
of the initial drafts did not have SNMM at all (at least we were
discussing it).  We use (big suprise) ASP TM in its place.

We go way back.  Take a look at the archive thread that I gave
from 2002.  Tolga was one of the one's agreeing that DPC/SI is
in fitting with the M3UA design and that sending DUPU goes
against it.

You see, ASP TM has all of the ASP management mechanisms at its
disposal to handle unavailability of ASPs serving an AS in
active-standby, loadshare and broadcast arrangements and to
handle traffic flow and ASP management and notification.

By sending DUPU one does not have all of these procedures at
the protocol's disposal.  But, knock yourself out.

> What's more, M3UA with flexible RK is an advantage. Operator
> can select different granularity RK in various scenarios.  But
> you cann't suppose all use RK with SI, to split PC based RK
> out.

If they want multiple user part independence at a point code,
an RK based on DPC/SI is their only choice that follows the
Proposed Standard and is quite sufficient.

At least until we see your detailed technical proposal.

--brian

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