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

chenxu,

Please see comments below...

chenxu wrote:                              (Thu, 26 Jul 2007 14:04:03)
> Dear,Brian F. G. Bidulock
> 
> 	Thank you for your comments!
> 
>     For M3UA and SCTP£¬I'll check if ETSI docs can slove our problems.

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.

For M3UA IPSP communicating directly with each other, no intervening IPSTP is
necessary.  In the SS7 network, an STP is a relay point.  No relay point for
SS7 is necessary in the IP network: the IP network itself provides for the
routing of packets between source and destination.  Therefore, for M3UA IPSP,
only point to point operation is provided (SS7 relay being unnecessary).
Anything else is trying to recreate the SS7 network within the IP domain,
which was neither part of the framework nor within the scope of the working
group.

>     For M2PA, I think national standardization is not enough.  As I refered
>  in Slides,compared with M3UA and SCTP, Some procedures in M2PA are
>  described a little bit simply ,they're referred to MTP2 directly, which
>  makes IPSTP providers realizing the procedures in different ways.  For
>  there¡¯s difference between MTP2 and M2PA in some aspects.

M2PA procedures are referred to the MTP2 standards particularly where
otherwise it would require that portions of the SS7 MTP Level 2 documents
(e.g. Q.703, ANSI T1.111.3, TTC JQ.703, etc.) would need to be copied directly
into the RFC, an in many cases, different text from each standard, as in: if
ITU-T do this (which is identical to Q.703), but if ANSI do this (which is
identical to T1.111.3).  Then if any of these standards documents are ever
updated, the text would also need to be updated in the M2PA RFC.

Rather than do that, the M2PA RFC only highlights where M2PA is different from
the "applicable" MTP2 specification.  It is up to your national standards
bodies to identify the "applicable" MTP2 specification for M2PA.  Having done
so, I do no see how implementation could possibly realized the procedures in
different ways.

>  By the protocol test£¬we find that some IPSTP providers use the same idea
>  as MTP2,and others take the relation between M2PA and SCTP into account.

IETF RFCs do not place requirements on implementations to do things in a
specific way unless doing so has a negative impact on the Internet, or causes
significant interoperability issues (and here "interoperability" means
functioning at all, not meeting performance or grade of service objectives).
Other things are "operational considerations" that are certainly important to
those operating the service, but not to the network.  It is up to the service
operator to place their own requirements for their own equipment to meet
objectives such as performance and grade of service.  For example, the value
of T7 does not affect the Internet, nor does it affect interoperability.  It
has a large impact on service performance and grade of service.  Therefore it
is up to the service operator to choose its value.

>     Most of the IP Signaling networks exsited are smaller than China
>  Mobile's, only one IPSTP vender is enough.  Maybe that's reason why SIGTRAN
>  Working Group hasn't received the Revision Requirement for M2PA.

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.

--brian


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