Subject: Re: [Sigtran] m3ua- IG

From: "TOLGA ASVEREN" <[email-masked]>
Date: Mon, 13 Jan 2003 13:14:19 +0200

Brian,
--- "Brian F. G. Bidulock" <[email-masked]> wrote:
> Samuel,
>
> DPC, DPC/SI, even OPC/DPC, OPC/DPC/SI.
>
> But don't forget that the SG can easily Load-Share
> on CIC, SSN,
> DLR/SLR, TID, etc.  We have just been talking the
> use of Routing
> Keys (which are 1:1 with the definition of the AS).
>
> So we are saying that it doesn't make too much sense
> to split
> Application Servers into sub-SI Application Servers.
>  SGs are
> worried about point code status and user part status
> and don't
> care about things like subsystem status.  Having
> Application
> Servers (remember, defined by Routing Keys) that are
> either
> point codes or user parts therefore makes a lot of
> sense.
>
> But *within* an Application Server there can be
> multiple ASPs
> serving the AS.  Load-sharing permits some messages
> to be sent
> to some ASPs and other messages to be sent to
> others.  With an
> extension such as
> draft-bidulock-sigtran-loadsel-01.txt or
> draft-bidulock-sigtran-loadgrp-01.txt the ASP can
> even be under
> control of which range of traffic it receives.  With
> a Broadcast
> AS, the ASPs are in control over which messages it
> chooses to
> process and which it does not choose to process.
>
> So, to summarize, using Load-Share or Broadcast
> Application
> Servers, everyting that one thought could be
> accomplished with
> sub-SI granularity Routing Keys, is possible with
> Load-Sharing.
> It, however, does not mess up the SG's view of PC
> and SI state
> and is therefore interoperable.
>
> Sub-SI RKs are just the wrong solution for the wrong
> problem.
> Load distribution with Load-sharing or Broadcast is
> the
> proscribed way of distributing traffic over multiple
> ASPs.
[TOLGA] I totally agree, if loadsaring addresses the needs, it is the way
to go. But not always it might be a perfect solution, one has to make the
upper layers distributed over multiple ASPs to work as a single entity. If
the number of ASPs serving the same AS increases, this might be too costly
and if one limits number of ASPs -let´s say they are low end systems- one
might not have desired processing power. With separete RKs, this wouldn´t
be a problem, one could slice the traffic into multiple AS, where each of
them is served by a reasonable number of ASPs -not as much as the
loadsharing case, so that synchronization is less costly- adn because there
are multiple AS, total number of ASPs is still big enough to have the
needed processing power. So, IMO loadsharing and separete RKs are not
exactly the same. But I also agree, trying to support non-MTP3 RKs is quite
ugly/for some of them maybe not possible.
>
> So, we should remove SSN and CIC from Routing Key
> (even restrict
> RK to not have non-MTP3 RKs) and yet, keep the
> sections where
> they are mentioned for load-sharing.  This gives
> maximum
> interoperability without sacrificing any
> functionality.
>
> --brian
>
> Samuel Dur D. Jeyaseelan wrote:
>                                (Mon, 13 Jan 2003
> 04:29:54)
> >
> > Hi,
> >
> > So the concensus was M3UA can not be used
> effectively between
> > STP(SG) to SCP(AS) -- unawareness of SSN
> >
> > can not be used effectively with MGC- unawareness
> of cic
> >
> > now i have a doubt , Where M3UA can be used
> effectively?
> >
> > any node which routes messae on DPC- here it is
> used , thats all?

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 13 Jan 2003 04:47:50 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Mon, 13 Jan 2003 13:14:19)
> >
> > Sub-SI RKs are just the wrong solution for the wrong problem.  Load
> > distribution with Load-sharing or Broadcast is the proscribed way of
> > distributing traffic over multiple ASPs.
>

Loadsharing extensions are still better than non-MTP3 RKs because they
can be described in an interoperable way.  Also, loadsharing can be made
to scale by grouping even low-end ASPs in load groups.  See:

	draft-bidulock-sigtran-loadsel-01.txt
	draft-bidulock-sigtran-loadgrp-01.txt
	draft-bidulock-sigtran-regext-01.txt

available now on the I-D server.

Also, there's an example on how to do ISUA (ISUP User Adamptation Layer)
also on the I-D server, and a re-released TUA:

	draft-bidulock-sigtran-isua-00.txt
	draft-bidulock-sigtran-tua-01.txt

Also, ASP extrensions and an updated CORID draft:

	draft-bidulock-sigtran-aspext-01.txt
	draft-bidulock-sigtran-corid-01.txt

But the loadsharing extensions (registering a load selection key and
activating and deactivating within a load selection or load group)
are probably just what you're looking for.

--brian

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Mon, 13 Jan 2003 05:54:19 -0600 (CST)

Brian,Tolga,

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

> > Keys (which are 1:1 with the definition of the AS).
Mean to say ,having multiple SGs pre-configured to serve
set of SSN and set of CIC range ...?

> > Application Servers into sub-SI Application Servers.

But SUA does it.

> > point codes or user parts therefore makes a lot of
disagree, Almost all STPs(SG) more worried about subsystem status...
because they are the only nodes which performs GTT to reach 'centralized
databse'

> > process and which it does not choose to process.

Load -sharing on SLS?

> > sub-SI granularity Routing Keys, is possible with

what is 'sub-SI granularity Routing Keys' ?
(said below 'sub-SI granularity Routing Keys' wrong solution
for wrong problems)

> > > any node which routes messae on DPC- here it is

I understood RFC 3332 was written with an idea of supporting 
SSN and CIC but after mail communication both were removed.

Instead of having separate RFC for SUA , we should have merged
both into a single RFC.
[just i put my thoughts :-)]

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 13 Jan 2003 05:12:27 -0700

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Mon, 13 Jan 2003 05:54:19)
> > > But don't forget that the SG can easily Load-Share on CIC, SSN, DLR/SLR,
> > > TID, etc.  We have just been talking the use of Routing Keys (which are
> > > 1:1 with the definition of the AS).
> > >
> Mean to say ,having multiple SGs pre-configured to serve set of SSN and set
> of CIC range ...?

Having any number of SGs pre-configure to serve a set of SSN or set of CIC
range...

> > > Application Servers into sub-SI Application Servers.

SUA sits above SCCP.  M3UA sits below SCCP.  Having M3UA try to
route to SCCP-User is a silly as having M2UA (yes, em-two-ua)
route to MTP Users.

> 
> > >  SGs are worried about point code status and user part status and don't
> > >  care about things like subsystem status.  Having Application Servers
> > >  (remember, defined by Routing Keys) that are either point codes or user
> > >  parts therefore makes a lot of sense.
>

M3UA SG's.  Subsystem status is peformed by SCCP.

> 
> > >
> > > But *within* an Application Server there can be multiple ASPs serving
> > > the AS.  Load-sharing permits some messages to be sent to some ASPs and
> > > other messages to be sent to others.  With an extension such as
> > > draft-bidulock-sigtran-loadgrp-01.txt the ASP can even be under control
> > > of which range of traffic it receives.  With a Broadcast AS, the ASPs
> > > are in control over which messages it chooses to process and which it
> > > does not choose to process.
> 
> Load -sharing on SLS?

Load-sharing on anything.  SLS is a good one...

> 
> > >
> > > So, to summarize, using Load-Share or Broadcast Application Servers,
> > > everyting that one thought could be accomplished with sub-SI granularity
> > > Routing Keys, is possible with Load-Sharing.
> 
> what is 'sub-SI granularity Routing Keys' ?  (said below 'sub-SI granularity
> Routing Keys' wrong solution for wrong problems)

RKs with a granularity finer than a Service Indicator (or smaller
than an MTP-User).

> I understood RFC 3332 was written with an idea of supporting SSN and CIC but
> after mail communication both were removed.

SSN and CIC were placed in the draft before RKs and most of the model was
formalized.  Experience has shown that they are not very useful for routing,
but are quite useful for loadsharing.  This is because the RK:AS:RC concept
had to be formalized to permit the SG management of the SPMC, making it no
longer suited to other more esoteric tasks better addressed with load-sharing
and broadcast.

> 
> Instead of having separate RFC for SUA , we should have merged both into a
> single RFC.  [just i put my thoughts :-)]

There is nothing stopping an implementor from runnign M3UA and SUA over the
same association (with different PPI).  Most of the messaging and and
proceudre text is identical (even with M2UA).  These protocols reside at
different layers in the protocol stack and work at different layer interfaces
within the SS7 stack.  Attempting to generalize all provider/user interfaces
at all levels of the SS7 stack would have been a recipe for failure.

Nevertheless, a one point I did say that SUA could have been easily  adjusted
to do what M3UA claimed to do as well.  All that was necessary was the
trivial MTP-TRANSFER primitive representation.  SUA supports all other
necessary message classes and parameters to perform all of M3UA's functions.

But, SUA still cannot handle CIC routing keys.  But ISUA can: see

With ISUP and SCCP covered by ISUA and SUA, who needs no stinkin' M3UA?

--brian

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Mon, 13 Jan 2003 06:35:20 -0600 (CST)

Brian,

> Having any number of SGs pre-configure to serve a set of SSN or set of CIC

repeated same.
IMO, dynamic ocnfiguration is better than static.

> Load-sharing on anything.  SLS is a good one...

Can please give an example other than SLS?

> RKs with a granularity finer than a Service Indicator (or smaller

Can you give an example?

> 	draft-bidulock-sigtran-isua-00.txt

Where this is available?
 
> With ISUP and SCCP covered by ISUA and SUA, who needs no stinkin' M3UA?

means what?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 13 Jan 2003 05:59:09 -0700

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Mon, 13 Jan 2003 06:35:20)
> > Having any number of SGs pre-configure to serve a set of SSN or set of CIC

I wrote "any number" of SGs, you wrote "multiple".

> IMO, dynamic ocnfiguration is better than static.

What has that to do with the CIC/SSN dicussion?

> Can please give an example other than SLS?

CIC, SSN, TID, SLR/DLR.

> > RKs with a granularity finer than a Service Indicator (or smaller

CIC, SSN.

> > 	draft-bidulock-sigtran-isua-00.txt

   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 

   but you can find it here too:

	ftp://ftp.ietf.org/internet-drafts/draft-bidulock-sigtran-isua-00.txt
	http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-isua-00.txt
	http://www.openss7.org/sigtran01.html
	
> > With ISUP and SCCP covered by ISUA and SUA, who needs no stinkin' M3UA?

means that!

---

From: "Valerie Gastaud" <[email-masked]>
Date: Mon, 13 Jan 2003 15:17:21 +0100

I don't want to restart the debate, I think we all agree that M3UA must be
preferably used with PC and/or SIO type of RK.
Can we however add a section in the M3UA-IG indicating that M3UA RK=SSN

is limited to:
- class 0/1
- single SG

and requires:
- NIF to intercept SCCP management messages received from SS7 and to send
them to all the SSNs (AS), with the exception of SST which should only be
sent to the Affected SSN (AS).
The SCCP management message must be sent within the AS depending on the
traffic mode and ASP status.

Valerie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
TOLGA ASVEREN
Sent: lundi 13 janvier 2003 12:14
To: [email-masked]
Subject: Re: [Sigtran] m3ua- IG

Brian,

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 13 Jan 2003 06:59:19 -0700

Valerie,

An editor of the IG thought it was worth a separate draft.
Would you care to start one seeing as you seem to have an
idea how your would like to see it set up?

--brian

Valerie Gastaud wrote:                                                             (Mon, 13 Jan 2003 15:17:21)