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

From: "Bep Verberk" <[email-masked]>
Date: Tue, 28 May 2002 16:45:49 -0400

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 !

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.

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.

Now I'm trying to figure out the advantages of using 
m3ua instead of m2pa once I get to this point.

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 ?

Bep 

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, May 28, 2002 2:19 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 13:38:35)
> > 
> >    I want to be convinced :)
> >    But you are not succeeding. See below again.
> >    
> >    Bep
> >    
> >    > -----Original Message-----
> >    > From: Brian F. G. Bidulock [[1]mailto:[email-masked]]
> >    > Sent: Tuesday, May 28, 2002 1:25 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 13:08:32)
> >    > >
> >    > >    Thanks,
> >    > >    see below.
> >    > >
> >    > >    > -----Original Message-----
> >    > >    > From: Brian F. G. Bidulock
> >    [[1][2]mailto:[email-masked]]
> >    > >    > Sent: Tuesday, May 28, 2002 12:50 PM
> >    > >    > To: Verberk, Bep [CAR:7M00:EXCH]
> >    > >    > Cc: 'Tolga Asveren'; [email-masked]
> >    > >    > Subject: Re: [Sigtran] m3ua:SG-SG document status
> >    > >    >
> >    > >    >
> >    > >    > Bep,
> >    > >    >
> >    > >    > Bep Verberk wrote:
> >    > >    > (Tue, 28 May 2002 12:23:07)
> >    > >    > >
> >    > >    > >    Tolga,
> >    > >    > >    well you never answered one of my questions :)
> >    > >    > >
> >    > >    > >    What is the advantages of your SG-SG proposal over
> >    > >    > >    simply using m2pa between 2 SGs.
> >    > >    >
> >    > >    > Multiple streams, routes, and routesets over a single
> >    > association.
> >    > >    > (M2PA can only support 1 link, not even a linkset).
> >    > >
> >    > >    [BEP] 1 m2pa association can carry traffic for multiple
> >    > routesets,
> >    > >    just as one link can. If you want 2 for 
> redundancy - no biggy.
> >    > >    What do you mean by multiple steams ? exactly what
> >    > advantage does this
> >    > >    give ?
> >    >
> >    > Read the SCTP applicability statement.  Multiple streams
> >    > allows SCTP to
> >    > address head-of-line blocking issues: the reason SCTP was
> >    > developed in the
> >    > first place to address SIGTRAN applications.
> >    >
> >    [BEP] That's what I thought, and you get the benefits of SCTP
> >    using m2pa. So at this point I consider the above 
> arguments refuted.
> 
> No you do not.  M2PA uses one stream and one stream only for 
> data.  M2PA
> is subject to HOL blocking, whereas M3PA is not.  M3PA could 
> theoretically
> have 65,535 independent streams making one retransmitted 
> message only block
> 2^-16 of the traffic.  For M2PA 100% of the traffic is 
> blocked waiting for
> a retransmitted packet.
> 
> >    
> >    > >    >
> >    > >    > >    I'm not against proceeding with the draft 
> - but I don't
> >    > >    > >    see why anyone would use it - hopefully 
> your answer to
> >    the
> >    > >    > >    above question will help me understand.
> >    > >    >
> >    > >    > To understand the limitations of M2PA, you need only
> >    > realize that
> >    > >    > it is exactly one link per association.  It 
> requires a fully
> >    > >    > functional
> >    > >    > SS7 MTP Level 3 layer to make it work.  SG-SG does
> >    > not.  Also, SG-SG
> >    > >    > is not restricted to M3PA, it could to SPA, ISPA, TPA.
> >    > >
> >    > >    [BEP] SGs have a fully functional MTP3. The SG-SG 
> draft adds
> >    > >    complications to try to mimick MTP3 behavior that 
> is already
> >    > >    painstakingly defined as MTP3 and available at the SG.
> >    >
> >    > And now wonderfully available between SGs over IP.  Which was
> >    > kinda the
> >    > intention of SIGTRAN: to carry SS7 over IP, not to force
> >    peer-to-peer
> >    > communication via the SS7 network.
> >    
> >    [BEP] Not quite "wonderfully available" yet.
> >    M2PA/SCTP is indeed SS7 over IP.
> >    So I don't understand this argument.
> 
> M2PA is traditional SS7 over IP treated like a wire.  With a 
> single stream
> it is no better than MTP3b/SSCOP-MCE.
> 
> >    
> >    >
> >    > >
> >    > >    >
> >    > >    > Let me ask you the question: what are the advantages
> >    > of M3UA?  Why
> >    > >    not
> >    > >    > just use M2UA?
> >    > >
> >    > >    [BEP] I would use M3UA instead of M2UA because I want to
> >    mimimize
> >    > >    the SS7 transport related functions on my ASPs (ie
> >    > ISUP+m3ua versus
> >    > >    ISUP+mtp3+m2ua). I want the SG to take care of 
> MTP3 for me.
> >    >
> >    > We want to use M3PA instead of M2PA so that the IP network is
> >    > not treated
> >    > like some kind of wire (which it isn't).
> >    
> >    [BEP] Don't understand your point here. I assume you are 
> implying that
> >    by treating IP "like some kind of wire" I loose the 
> inherent benfits
> >    of IP.
> 
> On the contrary, you loose the benefits of the wire: fixed 
> and available
> bandwidth, fixed delay, fixed error rates.  Don't expect M2PA 
> to follow
> Q.703 or SSCOP queueing principles (guaranteed bit rates) or delay
> characteristics.  MTP3 which runs fine with these wire 
> guarantees can be
> disasterous without them.
> 
> >    What I am asking for are the specific benfits I'm losing by using
> >    SG-SG m2pa
> >    versus SG-SG M3UA.
> 
> Multiple streams, low HOL blocking, failover based on SCTP 
> rather than MTP3
> better performance and SG-SG procedures for a non-wire environment.
> 
> --brian
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 May 2002 17:08:33 -0500

Bep,

Bep Verberk wrote:                                            (Tue, 28 May 2002 16:45:49)
>    A: put in a couple of TDM based ss7 links - Ta DA !

TaDa$$$$$$$$$$$AAAaaaah!

>    You can put in the extra linksets - not a show stopper.

No, not a $how $topper.

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

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

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

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.

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

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

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

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