Re: ????: Re: FW: LS on Clarification of M3UA usage in 3GPP networks

wuhongjian,

The reason for not pursuing M3PA (SG-SG) or whatever you want to
call it has been that there is no network functionality that it can
provide that cannot already be provided by standard M3UA in
conjunction with an STP.

So for example, for Scenario 1, the equivalent standard M3UA
approach is as follows:

       .---------.             ,---------.
       |         |             |         |
       |   ASP   |             |   ASP   |
       |         |             |         |
       | RK=DPC1 |             | RK=DPC2 |
       |         |             |         |
       `----v----'             `----v----'
            |                       |
            | ^                     X
            | |                      
            | | DUNA                X
            | |                     |
            |                       |
            | MTP-PAUSE   AS INACT  |
            |     /           \     |
       .----^----.             ,----^----.
       |        /|             |\        |
       |   SG1 / |             | \ SG2   |
       |      /  |             |  \      |
       |- - - - -|             |- - - - -|
       |         |   <-- TFP   |         |
       |         |             |         |
       |   STP   :>-----------<:   STP   |
       |         |   C-links   |         |
       |         |             |         |
       `---------'             `---------'

 - Communications is lost with the ASP serving RK=DPC2.
 
 - The corresponding AS moves to the AS-INACTIVE state in SG2 and
   SG2 unbinds the MTP-SAP from the SS7 stack in the STP resulting
   in an unavailable SS7 destination and the transfer-prohibited
   procedures are invoked for the destination (unavailable routeset).

 - TFP is sent on C-links (which can be M2PA, narrow-band, broadband
   or carrier pidgeon links).

 - The STP at SG2 receiving the TRP delivers the corresponding
   MTP-PAUSE indication primitives to user parts with a route to the
   unavailble destination per standard SS7 and standard RFC4666 M3UA
   procedures.

 - The M3UA NIF translates this to a DUNA according to standard RFC
   4666 M3UA procedures and delivers it to the ASP serving RK=DPC2.

 - The MTP user withholds traffic for DPC2 per SS7 standards.


Scenario 2, simple replace RKs.

       .---------.             ,---------.
       |         |             |         |
       |   ASP   |             |   ASP   |
       |         |             |         |
       | RK=DPC1 |             |DPC2,SI=3|
       |         |             |         |
       `----v----'             `----v----'
            |                       |
            | ^                     X
            | |                      
            | | DUPU                X
            | |                     |
            |                       |
            | MTP-STATUS  AS INACT  |
            |     /           \     |
       .----^----.             ,----^----.
       |        /|             |\        |
       |   SG1 / |             | \ SG2   |
       |      /  |             |  \      |
       |- - - - -|             |- - - - -|
       |         |   <-- UPU   |         |
       |         |             |         |
       |   STP   :>-----------<:   STP   |
       |         |   C-links   |         |
       |         |             |         |
       `---------'             `---------'

 - Communication is lost or the ASP serving DPC2/SI=3 becomes
   otherwise inactive for the AS.

 - The corresponding AS moves to the AS-INACTIVE state in SG2 and
   SG2 unbinds the MTP-SAP from the SS7 stack in the STP resulting
   in an unavailable user part.

 - Per standard SS7 procedures, when the STP receives messages for
   the unavailable user part, say from DPC1, it responds with UPU.

 - At SG1, the UPU translates to an MTP-STATUS primitive indication
   to concerned users according to standard SS7 procedures.

 - At SG1 the MTP-STATUS primitive is converted by the NIF into a
   DUPU message and is delivered to ASP serving the AS corresponding
   to DPC1.

 - The user at the ASP serving DPC1 starts periodic test procedures
   (e.g. UPT or SST) per SS7 standards.


So, the scenarios presented so far do not require M3PA.  Can you
think of a need that would actually require an M3PA?  These
scenarios simple do not require M3PA, standard RFC 4666 M3UA is
sufficient.

--brian



wuhongjian wrote:                              (Wed, 27 Feb 2008 18:28:07)
> 
>    
> 
>    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.
> 

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