Re: ´ð¸´: Re: FW: LS on Clari fication of M3UA usage in 3GPP networks

liu.jia,

Please see comments below...

[email protected] wrote:            (Wed, 27 Feb 2008 14:14:11)
> 
>    Hi brain,
>    I don't agree with you.
>    The  below is from RFC4666, in scenario 1, SG1 don't receive MTP-PAUSE
>    indication, so SG1 can't send DUNA message.
>    I       agree      with      'draft-zhang-sigtran-m3ua-req-00.txt¡¯and
>    'draft-chen-sigtran-m3ua-ext-00.txt'.
>    regards
>    Liu jia

Those drafts describe completely different protocols from that of
RFC 4666.  RFC 4666 explicitly excludes IPSP communicating with
anther IPSP that has the "transfer function"; that is an SG.  That
is roughly what I described as "M3PA" six years ago.  Is has never
been developed because M2PA is sufficient to the task (both between
STP's and between SEP and STP) and has already been standardized.
RFC 4666 (and RFC 3332 before it) expliclity exclude IPSP
interworking with SG because ASP to SG communications is only
supported purely in the MTP/MTP-User (backhaul configuration).
IPSP solely as point-to-point.  Anything different is simply not
M3UA.

If you just want centralized GTT, use SUA for SCCP and M3UA
point-to-point IPSP for things like ISUP; or, use M2PA for both:
then you will be able to keep all of the legacy SS7 STP OAM&P that
you known and love so well.

If you want puruse this IPSEP, IPSTP thing: as it is so different
from M3UA, you need to call it M3PA or something different from M3UA
and describe the *entire* protocol, not just these rather naive
increments on M3UA.

Now, the situation is that Scenario 1 and Scenario 2 as you have it
work quite fine.  Scenario 1 always and sceneario 2 whenever you
have the foresight to choose DPC/SI RK.

So, it is not necessary to imagine two new protocols layered on top
of M3UA to accomplish what is desired.

I disagree that anything such as this is missing from RFC 4666, and
so did the entire WG when concensus moved it forward.

That said, China Mobile is invited to provide whatever proprietary
protocols they would like within their own network.  No need to
bother the IETF about it.

--brian


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