Subject: [Sigtran] m3ua:SG-SG document status

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 28 May 2002 11:47:39 -0400

Lyndon,

Do you think, we got enough feedback about SG-SG document? All questions
asked are answered and my opinion is people see it as something needed.

So I propose again to make it a WG item, i don't see any reason to delay it
more.

   Tolga

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Bep Verberk" <[email-masked]>
Date: Wed, 29 May 2002 12:35:02 -0400

Brian.
I think we (or maybe just I) have made some progress with this
thread.

See a few comments below.

Bep 

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, May 28, 2002 6:09 PM
> To: Verberk, Bep [CAR:7M00:EXCH]
> Cc: [email-masked]
> Subject: Re: [Sigtran] m3ua:SG-SG document status
> 
> 
> Bep,
> 
> Bep Verberk wrote:                                            
> (Tue, 28 May 2002 16:45:49)
> > 
> >    Let me back up a bit.
> >    Here is my logic.
> >    
> >    Q: how can I connect 2 SGs together.
> >    A: put in a couple of TDM based ss7 links - Ta DA !
> 
> TaDa$$$$$$$$$$$AAAaaaah!
> 
> >    
> >    Q; OK, but I need seperate linksets for each Network.
> >    A: That has always been the case since
> >    the inception of SS7 when connecting two SS7 nodes.
> >    You can put in the extra linksets - not a show stopper.
> 
> No, not a $how $topper.
> 
> >    
> >    Q: I don't have TDM facilities - I have IP.
> >    A: well then just replace your TDM ss7 links with these
> >    new cool m2pa links that run over IP using SCTP.
> 
> But will they work like TDM links enough for your existing MTP
> not to bite the bullet, cascade failures, syndromes, network
> outages?? $$$$$$$$$  If you want mostly SS7, stick with SDH.
> 

[BEP] This is the expectation of many. 

> >    Now I'm trying to figure out the advantages of using
> >    m3ua instead of m2pa once I get to this point.
> 
> You probably also have a hard time figuring out why to use
> M2PA instead of MTP2.  Gee your IP runs over that ATM backbone
> anyway, so why not just use ATM links?  Gee, they've got ITU
> conformacne tests...

[BEP] Actually yes I do.

> 
> >    1. I can combine all my traffic for different networks.
> >    2. I can use mutiple SCTP streams to ensure lost messaged
> >    for a given traffic stream do not impact other unrelated
> >    traffic streams.
> >    BTW  - can you remind me why this was not included in m2pa ?
> 
> Changeover XCO/XCA couldn't handle it.  SCTP would give a gap
> list on changeover which XCO/XCA cannot handle.  Also MTP3 cannot
> handle having 65,535 signalling links failing simultaneously
> (although it is quite easy for SCTP to handle 65,635 streams failing
> simultaneously).
> 
> Bep, I suggest you look at the SIGTRAN requirements and framework
> documents.  SIGTRAN UAs were not developed so that your STPs could
> talk to each other over IP.  It was developed to solve some specific
> protocol needs in the MGC/MG/SG (see for example ETSI TIPHON)
> architecture.  Backhauling M2PA from an MG/SG to and MGC doesn't
> make much sense when you don't want the MGC having an MTP layer
> at all (just ISUP).  You can pull your M2PA (or TDM for that matter)
> links from the remote MG/SG to several centralized SGs running MTP
> and serving M3UA up to MGCs.   It would be convenient for these
> all-IP SGs to be able to communicate more directly with one another.
> Thus the M3PA.
> 

[BEP] I agree with what you say here.

> Why would you do this?  Because TDM to the MG/SG is expensive (and
> costs more with distance), so you want to collect your MG/SG near
> the edge of the PTSN and distibute over IP back to concentrating SGs.
> To cover a wider area, SG will be spaced out and would be better
> communicating with each other directly over (lower cost) IP while
> providing the distributed capabilities of M3UA (having SGs act in
> concert as SGPs in a distributed SG).  Less point codes, easier on
> the point code space.  MGCs then talk with the SGs in a far less
> sS7 network specific fashion.
>

[BEP] Again, I agree.
 
> But maybe you want International Toll bypass where all you want to
> do is get SS7 signalling off of an expensive channel onto a cheap
> data channel.  Go ahead: use M2PA (but watch out for the delay: it's
> an SS7 network killer).
> 
> Quite frankly I don't know why you would want to use M3PA or M2PA.
> You haven't told us what your application is.  These protocol layers
> are intended to suit different purposes in different applications
> and architecture.  Rather than searching around for the one you
> don't need, concentrate on searching for the one you do need.
> 
> (Next you'll be asking why one needs SUA when one has M3UA, or even
> why one needs SUA when one has M2PA!).

[BEP] No I think Tolga is asking that :)

> 
> Perhaps you will volunteer to write the SIGTRAN Applicability 
> Statement
> for M2PA (I don't think we'll let you for M3UA or M3PA, because you
> don't need those).
> 
> --brian
> 
> >    
> >    Bep
> >    
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>