Subject: Re: [Sigtran] Sigtran Digest, Vol 46, Issue 5

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 25 Feb 2008 01:29:52 -0700

Li,

Why refuse to use the facility that was specifically placed in the RFC to
provide for independent user parts?

That facility is the DPC/SI RK.  If you refuse to use it, do not expect
to benefit from the fuctionality it provides.  Too hard and too complex:
not!  M3UA is the "interface" between MTP and an MTP-User.  It is not even
a stack: it is a shim.  SS7 stacks do this all day long.

Sending SG messages in the wrong direction from an ASP is simply not an
option.  DUPU and SCON corresponds to MTP-STATUS, DUNA to MTP-PAUSE and DAVA
MTP-RESUME.  These primitives go from MTP to MTP-User; *not* *visa* *versa*.
If an MTP User wishes to attach to or withdraw from the MTP/MTP-User interface
and an MTP-SAP it uses an implementation dependent local binding and unbinding
function.  For M3UA this is the ASP TM procedures and messages.  ASP Active/Ack
attaches to the MTP-SAP (PC/SI) and ASP Inactive/Ack detaches from the
MTP-SAP.  Local to the SS7 stack *at* *the* *SG*, an MTP-User detaching from
the MTP-SAP results in UPU(unavailable) being sent for the corresponding
MTP-SAP.  That's how SS7 works.  That's how M3UA works.

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.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 25 Feb 2008 20:38:23 -0700

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

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 26 Feb 2008 13:48:25 -0500

Bryan, Li,

Just summarizing my personal thoughts on this issue:

1) I think using SNMM messages as described, e.g. sending DUPU from ASP to SG, is conceptually against the philosophy of M3UA protocol (It is not an oversight).

2) IMHO, STP type nodes make sense even in IP domain for reasons like security, ease of management etc... I would be interested to hear what operators think about this as they are the ones which actually deploy and use the systems.

3) I am not sure the difficulty arising from configuring sub-PC RKs is significant. Again, would like to hear operator's opinion.

4) It makes sense to me to base something like M3UA SG-SG/M3PA on SSNM (AFAIR -it really has been a long time-, last version was using SSNM).

Thanks,
Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of LI Xinyan
> Sent: Monday, February 25, 2008 9:29 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sigtran] Sigtran Digest, Vol 46, Issue 5
> 
> Hello, Brain
> 
> I don't agree with you.
> 
> brain wrote:                              (2008年2月25日 16:30)
> >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.
> But M3UA has more wide use than M2UA, it can apply to backhauling
> scenario, and also STP like scenario.
> 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.
> 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.
> 
> >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).
> 
> >Thanks,
> >Tolga
> "
> 
> 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.
> 
> 
> Regards
> Li Xinyan
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 2008年2月25日 16:30
> To: LI Xinyan
> Cc: [email-masked]; [email-masked]
> Subject: Re: Sigtran Digest, Vol 46, Issue 5
> 
> Li,
> 
> That facility is the DPC/SI RK.  If you refuse to use it, do not expect to
> benefit from the fuctionality it provides.  Too hard and too complex:
> option.  DUPU and SCON corresponds to MTP-STATUS, DUNA to MTP-PAUSE and
> DAVA MTP-RESUME.  These primitives go from MTP to MTP-User; *not* *visa*
> *versa*.
> If an MTP User wishes to attach to or withdraw from the MTP/MTP-User
> interface and an MTP-SAP it uses an implementation dependent local binding
> and unbinding function.  For M3UA this is the ASP TM procedures and
> messages.  ASP Active/Ack attaches to the MTP-SAP (PC/SI) and ASP
> Inactive/Ack detaches from the MTP-SAP.  Local to the SS7 stack *at* *the*
> *SG*, an MTP-User detaching from the MTP-SAP results in UPU(unavailable)
> being sent for the corresponding MTP-SAP.  That's how SS7 works.  That's
> how M3UA works.
> 
> 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.
> 
> --brian
> 
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 26 Feb 2008 14:02:54 -0500

Tolga,

In the numerous deployments that we are doing with M3UA, we are seeing that operators are not going away from STPs for the reasons that you specified below and others (security, ease of GT management, ease of migration from current SS7 architecture to SIGTRAN based architecture).

Regards,
Lincoln

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Asveren, Tolga
Sent: Tuesday, February 26, 2008 1:48 PM
To: LI Xinyan; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] Sigtran Digest, Vol 46, Issue 5

Bryan, Li,

Thanks,
Tolga

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of LI Xinyan
> 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.
> 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.
> 
> What's more, M3UA with flexible RK is an advantage. Operator can 
> select different granularity RK in various scenarios.
> Why refuse to use the facility that was specifically placed in the RFC 
> to provide for independent user parts?
> 
> That facility is the DPC/SI RK.  If you refuse to use it, do not 
> expect to benefit from the fuctionality it provides.  Too hard and too complex:
> not!  M3UA is the "interface" between MTP and an MTP-User.  It is not 
> even a stack: it is a shim.  SS7 stacks do this all day long.
> 
> Sending SG messages in the wrong direction from an ASP is simply not 
> an option.  DUPU and SCON corresponds to MTP-STATUS, DUNA to MTP-PAUSE 
> and DAVA MTP-RESUME.  These primitives go from MTP to MTP-User; *not* 
> *visa* *versa*.
> interface and an MTP-SAP it uses an implementation dependent local 
> binding and unbinding function.  For M3UA this is the ASP TM 
> procedures and messages.  ASP Active/Ack attaches to the MTP-SAP 
> (PC/SI) and ASP Inactive/Ack detaches from the MTP-SAP.  Local to the 
> SS7 stack *at* *the* *SG*, an MTP-User detaching from the MTP-SAP 
> results in UPU(unavailable) being sent for the corresponding MTP-SAP.  
> That's how SS7 works.  That's how M3UA works.
>