RE: aspcong draft -congestion levels-

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> Sent: Thursday, October 20, 2005 7:07 PM
> To: Tolga Asveren
> Cc: [email protected]
> Subject: Re: [Sigtran] aspcong draft -congestion levels-
>
>
> Tolga,
>
> Tolga Asveren wrote:                    (Thu, 20 Oct 2005 11:43:40)
> > IMHO, it is not that straightforward what to do about improved TID based
> > routing support. First let't see what TCAP and SCCP provide:
> >
> > SCCP: transport functionality
> > TCAP: asynchronous remote procedure call semantics
> >
> > As far as I can see, one can't just provide TCAP-User interface to
> > applications and expect them to do something usefull, they need
> to receive
> > SCCP primitives as well to decide reachability of destinations.
> So, there is
> > no architecturally pure solution to that problem, any solution
> mimicing TCAP
> > user-interface should also include transport related messaging like
> > DUNA/DAVA etc... , which is not part of TCAP-user interface.
>
> On the contrary, the TCAP-user interface described in the Q.77X series
> of specifications, does include primitives for the availability and
> reachability of destinations.  They happen to be the same as the SCCP
> ones:
[TOLGA]Yes, you are right -should not think on just TCAP primitives,
destination status related ones are SCCP primitives but they are sent to the
user after all-.
>
>  Q.771/2.2.3 Management aspects
>
>  SCCP Management primitives used to inform SCCP users of availability
>  and non- availability of SCCP (local or remote), wil be passed
>  transparently by TC to the TC-user.
>
> That's pretty clear.  draft-bidulock-sigtran-tua-04.txt provides
> DUNA/DAVA/DRST/SCON in the same fashion as SUA to accomodate this.
> These are summarized in section 1.3.5.3 of the draft and detailed in
> Sections 3.5.1 (DUNA), 3.5.2 (DAVA), 3.5.3 (DRST), 3.5.4 (SCON),
> procedures in 4.1.2.1, and all of 4.5.
>
> >
> > Considering the distributed architecture of SIGTRAN UA protocols, all of
> > them also have some transport functionality in that context,
> e.g. ASPs may
> > communicate with multiple SGPs adn based on reachability
> information of the
> > SGPs, status for SS7 destinations may change as well.
> >
> > It seems, a SCCP User-Interface based solution would need to
> perform some
> > TCAP processing to be able to support improved TID based
> routing. Similarly
> > a TCAP User-Interface based solution needs to implement some transport
> > related functionality and should support transport of SCCP
> primitives, which
> > is not what TCAP is doing.
>
> No, I'm sorry, but that is simply wrong: SCCP management is included in
> TCAP per TCAP standard specifications.  TUA simply follows standard TCAP
> in passing SCCP management messages transparently to the TC-User, and
> even does so with the same semantics and syntax of SUA.
[TOLGA]As far as I can see, it is not totally wrong, if a TCAP-User
Interface based UA solution supports ASPs to use multiple SGP(SG?)s. Still
some type of transport functionality need to be implemented on ASP side,
e.g. to select a SGP, and if communciation with multiple SGs are not
supported -I did not think on that one yet at all, whether it makes sense-
aggregating destination status based on SSNM for such a solution.
>
> --brian
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>