Re: ´ð¸´: Re: FW: LS on Clarific ation of M3UA usage in 3GPP networks

Hi，brian：

I agree with you that what those drafts describe is a different protocol in some sense,supposed that it can be named as M3PA,not M3UA. But that is really what those scenarioes such as  IPSEP-IPSTP-IPSEP needed, and these kind of application are very popular in IP-based signalling network deployment recently. 

So, shall we have to focus on the name of the protocol, or on the functions or mechanisms which the protocol provieded to us? I think We just need a protocol to meet our need,and solve our problem, whaterver it is called as M3PA or extended M3UA, though I understand there is some difference between "User adaptation" and " Peer-to-Peer User adaptation".

In the scenario mentioned above, M3UA does not so qualify in a large IP-based signalling network, While M2PA maybe can meet our need. But I don't think M2PA is a good choice. Compared with OSI/RM, M2PA is something like a duplicated stack with SCTP. Network elements implemented MTP3/M2PA/SCTP can not work efficiently compared with those implemented M3UA/SCTP. 

There is one question I am interested in is that why IETF did not develop M3PA six years ago？Sigtran used in a large IP-based signalling network maybe is a new requirement for us, M3PA or extended M3UA may be needed this time,I think. 

Thank you.

Best regards
Wu Hongjian
  ----- Original Message ----- 
  From: Brian F. G. Bidulock 
  To: [email protected] 
  Cc: [email protected] 
  Sent: Wednesday, February 27, 2008 3:50 PM
  Subject: Re: [Sigtran] ´ð¸´: Re: FW: LS on Clarification 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/
  _______________________________________________
  Sigtran mailing list
  [email protected]
  https://www.ietf.org/mailman/listinfo/sigtran

_______________________________________________
Sigtran mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sigtran