Re: The requiremnts and proposals forM2PA/M3UA/SCTPExtension from China Mobile

chenxu,

chenxu wrote:                                    (Thu, 26 Jul 2007 16:33:41)
> Hi,Brian F. G. Bidulock,
> 
>    Thank you for your comments!
> 
>    As you refered, M3UA is designed for SGP-ASP and IPSP-IPSP
> applications.But it's such a  welcome protocol,so 3GPP defines it to
> transport core network signaling,such as BICC,MAP and CAP.And for China
> Mobile and other big carriers,IPSP-IPSP application isn't enough.we need
> relay points(IPSTP) in SS7 over IP network. M3UA is a good choice for
> IPSTP-IPSEP interface of IP signaling network,why not extend its application
> only because of its initial design idea? 

I suggest you talk to 3GPP, because they have already extended, restricted,
modified and otherwise altered all these RFCs.  Nevertheless, 3GPP has not
defined an IPSTP, nor has IETF, nor have you offerred a pressing need to do
so.

> >   If they can't you likely are expecting M3UA to do something that it was not
> >intended to do.  M3UA was not intended to replace an SS7 network with an IP
> >network.  It was intended to provide transparent interworking between an
> >existing traditional SS7 network and Application Servers in the IP domain.
> >Primarily for backhaul of SS7 signalling protocols from a Signalling Gateway,
> >possibley collocated with a Media Gateway, to a Media Gateway Controller.  See
> >the framework document RFC 2719.
> 
> 
>   As we know,IP Signaling networks exsited only have one IPSTP vender,and
>   without the IPSTP-IPSTP interworking scene. That's the 4 IPSTP
>   venders(include TEKELEC and CISCO) told us.Maybe the performance of one
>   IPSTP is better that one STP since the rapid development of signaling
>   technology and IP technology.So£¬that's the difference between the
>   traditional signaling network(use STPs) and IP signaling network(use
>   IPSTPs) .

Please avoid mentioning vendor names on this list.

First, what is an IPSTP?  If you mean an STP that has M2PA signalling links,
that is a supported by RFC 4165 and illustrated in ETSI EG 202 360.  If you
mean an M3UA SG as STP as also illustrated in ETSI EG 202 360 in the access
network, then that is supported by RFC 4666.

If you mean some sort of IPSTP that relays between two IPSPs, then is is
explicitly not suported by RFC 4666.  If your vendors are claiming to
implement such a thing, it is a proprietary protocol and implementation and is
not based on any standard.  I wouldn't expect interoperability in such a case,
would you?  I hasten to recommdend that you do not implement proprietary
protocols and implementations as such if at all possible, otherwise you will
always be at the mercy of the vendor.

> 
> >  All of the telcommunications carriers that I used to work for required STPs
> >from multiple vendors.  In fact, after the 9-hour AT&T SS7 network outage, it
> >was required that STPs in an STP pair be from different vendors.  I doubt that
> >STPs from one vendor (IP or not) is the norm today.  So you are not alone
> >here.
> 
> 
>  I'm  looking forward to your support £¬cause I believe that both of us hope
>  the international specification is perfect and authoritative.

Please start by identifying why you think that such a thing as an IPSTP is
needed.  And please stop saying just because you need a relay function: please
identify and illustrate which you think that a relay function in the IP domain
is needed from an operational sense, engineering advantage, sizing and
scaling, capacity constraints, operational economics, or other tangible
factors that could be experienced by more than one operator.  Also, please
illustrate why IP domain relaying is the only way to solve those particular
problems and why point-to-point IPSP communications cannot solve them equally
well.  Then we might be in a position to start discussing IPSTPs.

--brian


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