Subject: Re: [Sigtran] FW: LS on Clarification of M3UA usage in 3GPP networks

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Feb 2008 14:45:56 -0700

Lyndon,

Here are some comments on the document:

First off, both scenarios have been discussed in great detail on
this list in the (albeit distant) past.

Overall, it is not helpful to think of the ASPs as SPs.  The
management of SPs toward the SS7 network (converged or not) is
clearly the responsibiliy of the SG in the RFC.

In scenario 1:

Yes, SG1 must send DUNA when SP2 is unavailable to it (the
routeset to SP2 is unavailable), as SP2 is a destination in the
SS7 network regardless of whether it is served by the SS7 or IP
domains (cf. RFC4666/1.3.2.3 and RFC4666/3.4.1).

Kindly advise CT4 that all SS7 signalling point code are
"SS7 Destinations" regardless of whether they happen to be
served by the SS7 or IP domains.

IMHO no document or protocol modifications are necessary.

In scenario 2: 

This was discussed many times on the list.

If one defines an AS with an RK at the granularity of a
Signalling Point Code, all user parts must live and die
together.  When the ASP signals ASP-INACTIVE for such an RC, the
entire signalling point becomes unavailable (and the SG would be
expected to mark the point code as unavailable if there are no
other ASPs serving the AS and no other routes to the signalling
point, and potentially send TFP toward the SS7 network and DUNA
toward ASPs serving SPs with a route set toward the affected SP).

If one defines an AS with an RK at the granularity of a single
Signalling Point Code/Service Indicator (DPC/SI) combination,
the user part can live and die independent of other user parts
for the same signalling point code.  When the ASP signals
ASP-INACTIVE for such an RC, the single user part becomes
unavailable (and the SG would be expected to mark the user part
unavailable if there are no other ASP serving the AS and no
other routes to an "Alias" SP serving the same single user
part, and potentially send UPU toward the SS7 network and DUPU
toward ASPs serving the SPs sending traffic to the user part.)

There are some minor compications with using multiple STP/SGs
with user part granularity RKs: one STP/SG cannot reroute
traffic for a user part unavailable due to uavailability of a
directly attached ASP to its mate unless each SG has STP circular
route detection logic incorporated into its M3UA layer and
user part available logic.  That is, unless the SG can detect
that it should not send a message out on the same C-link set
upon which it was received and also that the circular route
attempt was based on the unavailability of a user part
associated with a locally attached ASP and send a UPU in
response, it must send the UPU before attempting to route the
message to its mate.  (Circular route detection is explained in
ANSI T1.111.4/2000.)  Without this logic, remote sending SPs can
be alternately sent UPUs and then responses to (say, UPT or SST)
in rapid succession depending only on the SLS of the messages
sent.  Another policy can be taken up by the ASP attached to
both SGs serving such an AS by performing an ASP-INACTIVE
procedure to the remaining SG when communications is lost with
the first SG.

It is a protocol error for the ASP to send DUPU messages to
the SG (cf. RFC4666/3.4.5).

Kindly advise CT4 that SNMM messages are sent only from an
SG to an ASP.  Traffic management messages sent from an ASP
to an SG are ASP-TM messages.  When user parts need to be
independently available or unavailable, they must use separate
RKs.  (Note that ETSI TS 102 142-V1.1.1 (2003-05) forbids use
of an RK at granularity less than a point code; cf. 4.7.)

IMHO no document or protocol modifications are necessary.

Perhaps a BCP document would be a good idea, but I think that
the RFC would have to proceed to DS instead of PS.

By the way, are these protocols ever going to be advanced to
DS?

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/sigtran

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 22 Feb 2008 10:39:55 -0500

An additional perspective about possible issues with multiple SGs and sub-PC RK  configurations:
SCTP multihoming provides some solution here as well. If multihoming is used and underlying IP network is engineered properly, loss of SCTP association will indicate that ASP is down. So, both SGs will have the same view of the User Part/PC (there possibly would be a slight difference in time when each SGP detects the ASP as down) (I assume if an ASP wants to inactivate a sub-PC AS, it would do so for all SGPs). Again, this explanation relies on resiliency provided by SCTP multihoming against network/NIC failures (so, no need to go into the debate whether this is the case; just pick your side ;-) )

BTW, it is a pitty/shame we couldn't evaluate M3UA SG-SG/M3PA ideas properly in this WG, as this seems to me exactly what people out there are looking for (and possibly would allow them to use a single protocol throughout their networks, rather than a M3UA/M2PA hybrid).

Thanks,
Tolga

-----Original Message-----
From: [email-masked] on behalf of Brian F. G. Bidulock
Sent: Thu 2/21/2008 4:45 PM
To: Ong, Lyndon
Cc: [email-masked]; Jon Peterson
Subject: Re: [Sigtran] FW: LS on Clarification of M3UA usage in 3GPP networks
 
Lyndon,

In scenario 1:

In scenario 2: 

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 27 Feb 2008 00:50:59 -0700

liu.jia,

Please see comments below...

[email-masked] 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-masked]
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sigtran

---

From: "wuhongjian" <[email-masked]>
Date: Wed, 27 Feb 2008 18:28:07 +0800

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-masked] 
  Cc: [email-masked] 
  Sent: Wednesday, February 27, 2008 3:50 PM
  Subject: Re: [Sigtran] ´ð¸´: Re: FW: LS on Clarification of M3UA usage in 3GPP networks

  liu.jia,

  --brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 27 Feb 2008 13:21:15 -0700

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.
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 27 Feb 2008 15:48:52 -0500

Could the reason be that some people want to replace traditional STPs with their SIGTRAN equivalents? And they don't want to use M2PA because they think it is heavyweight for their purposes? (Some people do have faith in SCTP ;-) )

So, I guess, there is the practical, operational side of the coin as well as the purely theoretical/technical one.

I am also aware of cases, where people needed to build IPSPs proxying remote PCs to overcome this problem.

Thanks,
Tolga

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian F. G. Bidulock
> Sent: Wednesday, February 27, 2008 3:21 PM
> To: wuhongjian
> Cc: [email-masked]
> Subject: Re: [Sigtran] ????: Re: FW: LS on Clarification of M3UA usage
> in3GPP networks
> 
> wuhongjian,
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 27 Feb 2008 14:08:45 -0700

Asveren,,

Asveren, Tolga wrote:                 (Wed, 27 Feb 2008 15:48:52)
> Could the reason be that some people want to replace traditional STPs with
> their SIGTRAN equivalents?

The SIGTRAN equivalent of an STP is an STP.

The IP equivalent of an STP at MTP is a router, and at SCCP is a
router and a directory.

> And they don't want to use M2PA because they think it is
> heavyweight for their purposes? (Some people do have faith in
> SCTP ;-) )

Let me see, you mean that M2PA is to heavyweight but an STP nodal
function is not?  Strange, it is M2PA that keeps one from having to
change to much in the STP.  If you don't already have an STP, you
don't need one (just a router and a directory server).

> 
> So, I guess, there is the practical, operational side of the coin
> as well as the purely theoretical/technical one.

If by practical, you mean legacy, then minimal changes to STP nodal
functions is paramount: that is best accomplished with existing
C-links (not even M2PA) and M3UA in pure backhaul model (can be run
outside the SS7 stack at the STP).

> 
> I am also aware of cases, where people needed to build IPSPs
> proxying remote PCs to overcome this problem.

Why would one ever need to do that?  The only reason for that that
I can think of is VASP or CAT mediation and that is a whole
different ball of wax: it is near impossible to apply to the SS7
network far less one intended to work seamlessly with one.

--brian

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 27 Feb 2008 16:19:52 -0500

I guess, it is crucial to understand that different
people/networks/equipment have different needs. For me, feedback from an
operator is valuable (definitely more than just rhetoric [routers,
directory servers etc... ;-) ] ).

People needed to invent/implement proxying in IPSPs exactly for the same
reasons already mentioned in the latest posts: security, ease of
management, ease of migration etc...)

BTW, yes, I stand by my opinion that M2PA is too heavyweight. People
seem to be happy enough with redundancy provided by SCTP. 

Thanks,
Tolga

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2008 4:09 PM
> To: Asveren, Tolga
> Cc: [email-masked]
> > Could the reason be that some people want to replace traditional
STPs
> with

---

From: "wuhongjian" <[email-masked]>
Date: Thu, 28 Feb 2008 15:43:43 +0800

Hi, brian:

First,thank u for your patient in giving your explanation again and again.

In scenario 1, Provided that the figure changes into IPSP1--IPSTP--IPSP2, when IPSP2 becomes inactive, does RFC 4666 specify clearly that IPSTP has to send DUNA to IPSP1? I don't think so. You have told us, IPSP-IPSP is a point to point configuration, in which IPSTP is excluded. But IPSP1--IPSTP--IPSP2 and IPSP1--IPSTP1--IPSTP2--IPSP2 are the most needed network configurations in large IP-based signalling network. We can't slide over this issue.

In scenario 2, according to your explanation, one MSCserver shall populate 2 ASs: AS1 with RK=DPC1+SI3(SCCP), AS2 with RK=DPC1+SI13(BICC). And how many associations will MSCserver establish with one SG, one common association or two separated associations? IMHO,if the answer is the former, it is really complex; If the latter,I think it is a kind of waste of resources.

Furthermore, after reading the scenario 2 described in the Statement from 3GPP, I notice that it is quite different from the one you mentioned in your letters. 

thank u again.

Wu Hongjian

----- Original Message ----- 
  From: Brian F. G. Bidulock 
  To: wuhongjian 
  Cc: [email-masked] 
  Sent: Thursday, February 28, 2008 4:21 AM
  Subject: Re: [Sigtran] ????: Re: FW: LS on Clarification of M3UA usage in 3GPP networks

  wuhongjian,

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

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

  --brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 28 Feb 2008 01:34:45 -0700

wuhongjian,

wuhongjian wrote:                      (Thu, 28 Feb 2008 15:43:43)
>    In    scenario    1,   Provided   that   the   figure   changes   into
>    IPSP1--IPSTP--IPSP2,  when  IPSP2  becomes  inactive,  does  RFC  4666
>    specify  clearly  that IPSTP  has to send DUNA to IPSP1? I don't think
>    so. You  have told us, IPSP-IPSP is a point to point configuration, in
>    which    IPSTP    is    excluded.    But    IPSP1--IPSTP--IPSP2    and
>    IPSP1--IPSTP1--IPSTP2--IPSP2    are    the    most    needed   network
>    configurations  in  large  IP-based signalling network. We can't slide
>    over this issue.

There is no such thing as an IPSTP in the standard.  What you can
have according to the standard is an SG that is also an STP.  That
is what is shown.

However, as the SE IPSP is simply the following:

   ,-------.       ,-------.
   |       |       |       |
   | ASPF  |-      | ASPF  |
   |       | \     |       |
   '-------'  \    '-------'
               \       |    
   ,-------.    \  ,-------.
   |       |     \ |       |
   |  SGF  |      -|  SGF  |
   |       |       |       |
   '-------'       '-------'
    SE-IPSP         SE-IPSP

One could conceive of this vague IPSP-IPSTP-IPSTP-IPSP arrangement
as simply:

   ,-------.       ,-------.     ,-------.       ,-------.
   |       |       |       |     |       |       |       |
   | ASPF  |-      | ASPF  |     | ASPF  |      -| ASPF  |
   |       | \     |       |     |       |     / |       |
   '-------'  \    '-------'     '-------'    /  '-------'
               \                             /            
   ,-------.    \  ,-------.     ,-------.  /    ,-------.
   |       |     \ |       |     |       | /     |       |
   |  SGF  |      -|  SGF  |     |  SGF  |-      |  SGF  |
   |       |       |       |     |       |       |       |
   '-------'       :-------:     :-------:       '-------'
                   |       |     |       |                
                   | STPF  |-----|  STPF |                
                   |       |     |       |                
                   '-------'     '-------'                
    SE-IPSP         SE-IPSTP      SE-IPSTP        SE-IPSP

And, because the SGF (SG Function) is not needed on the SE-IPSPs and
the ASPF (ASP Function) is not needed on the SE-IPSTPs, this reduces
simply to:

   ,-------.                                     ,-------.
   |       |                                     |       |
   |  ASP  |-                                   -|  ASP  |
   |       | \                                 / |       |
   '-------'  \                               /  '-------'
               \                             /            
                \  ,-------.     ,-------.  /             
                 \ |       |M3PA?|       | /              
                  -|  SG   |- - -|   SG  |-               
                   |       |     |       |                
                   :-------:     :-------:                
                   |       |M2PA |       |                
                   |  STP  |-----|  STP  |                
                   |       |     |       |                
                   '-------'     '-------'                
      ASP             SG             SG             ASP   

Which is possible today according to the standard and is what I
diagrammed.  Now we had conceived of this SG-SG protocol based on
M3UA, once called M3PA that could connect SGs instead of using M2PA
between STPs, but it does not obviate the need for an STP function
and the existing standard also permits traditional SS7 links from
the STPs.

>    In  scenario  2,  according  to  your explanation, one MSCserver shall
>    populate     2     ASs:     AS1    with RK=DPC1+SI3(SCCP), AS2    with
>    RK=DPC1+SI13(BICC). And how many associations will MSCserver establish
>    with one  SG,  one  common  association or two separated associations?
>    IMHO,if  the  answer  is  the  former,  it  is  really complex; If the
>    latter,I think it is a kind of waste of resources.

You should know from the standard that only one SCTP association can
exist between an ASP and an SG.  It is not overly complex in this
case, rather it is necessary and sufficient: you need two AS
definitions because you need two state machines to track the
independent state of the two user parts.  If you do not need to
track the independent state of each user part, used a DPC RK,
resulting in only one AS state machine.

>    Furthermore,  after  reading the scenario 2 described in the Statement
>    from  3GPP,  I notice  that  it  is  quite  different from the one you
>    mentioned in your letters.

How so?  I don't see any differences significant to the discussion.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 28 Feb 2008 03:52:55 -0700

wuhongjian,

wuhongjian wrote:                        (Thu, 28 Feb 2008 17:03:24)
> 
>    The trigger mechanism of the DUPU from SP2 is different.
> 

What do you mean by "trigger mechanism"?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 28 Feb 2008 03:58:15 -0700

Tolga,

Then you must love Q.2150.3: MTP User directly on SCTP
without all that heavy-weight M3UA.

Asveren, Tolga wrote:                      (Wed, 27 Feb 2008 16:19:52)

--brian