RE: AS, RK , RC concepts in SE model

Ilie,

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Ilie Glib
> Sent: Tuesday, December 06, 2005 6:10 AM
> To: [email protected]; Ilie Glib; [email protected]
> Subject: Re: [Sigtran] AS, RK , RC concepts in SE model
>
>
> Hello Brian,
>
> in my view this is a considerable change of AS concept. In SIGTRAN an
> AS is an application server sitting behind its ASPs/IPSPs. Now you say
> an AS is a bidirectional signalling relation and not an Application
> Server.
[TOLGA]Two points related with this:
- From M3UA stack point of view, an AS is a signaling realtionship for
SGP/ASP/IPSP cases. It is true that AS is not only a M3UA stack but the
functional areas of M3UA specification deal only with M3UA stack behavior.
If you look from architectural perspective, I would say that an AS consists
of multiple ASPs -with M3UA stack, SS7 User Parts and Application logic-,
rather than AS sits behind ASPs/IPSPs.

- From modeling point of view, 1:1 relationship between AS and RK still
holds for SE-IPSP. One can think that two ends of an SE-IPSP relationship
are different AS using the same RK. On each IPSP you still have the 1:1
relationship between AS and RK, because you care only about your local AS
definiton -it defines traffic at both ends-.
>
> The same goes for RK,  RK1 cannot be the same as RK2, because Routing
> Key defines where messages go, it defines routing.
[TOLGA]For SE-IPSP RK defines traffic at both ends. Still you have your
"local" RK to guide you for routing decisions. Obviously two sides need to
use the same RC so that messages are exchanged properly.
>
> In my view the concept of Application Server cannot be dependent on
> the exchange model used. How can we make the main SIGTRAN concept
> dependent on the communication model?
[TOLGA]It isn't.
>
> Any other opinions?
>
> Regards
>
> Ilie
>
> On 12/6/05, Brian F. G. Bidulock <[email protected]> wrote:
> > Ilie,
> >
> > For SE AS1==AS2 (and RK1==RK2).
> >
> > For DE AS1!=AS2 (and RK1!=RK2).
> >
> > You need double the AS, RC and RKs in DE as you do in SE.
> >
> > Because they can't relay, IPSPs only need 1 AS betwixt them.
> >
> > --brian
> >
> > Ilie Glib wrote:                              (Tue, 06 Dec 2005
> 11:40:47)
> > > Hello Folks,
> > >
> > > According to the current definition of AS and RK there is 1:1
> > > relationship between them. The AS is an Application Server that
> > > process traffic routed according to the routing key, that is it
> > > process traffic that comes from unidirectional signalling relations,
> > > it does not process traffic that goes in the opposite direction, it
> > > generates traffic in the opposite direction.
> > >
> > > For example
> > > The RK1=(OPC=2-200, DPC=2-100) is different from RK2=(OPC=2-100,
> > > DPC=2-200). Each RK defines its own AS, in this case AS1, which
> > > corresponds to RK1, sits in 2-200 signalling point and AS2, which
> > > corresponds to RK2, is in 2-100, and each AS has its own RK.
> > >
> > > Could you please clarify
> > >
> > > Q1: What is correct 1) or 2)
> > > 1) In the described above configuration it is one AS =
> AS1=AS2, or otherwise
> > > 2) AS1 and AS2 are different ASes
> > >
> > > I assume 2) is correct. Then Routing Context RC1 corresponding to RK1
> > > is assigned in AS2 and Routing Context RC2 corresponding to RK2 is
> > > assigned in AS1. RC1 and RC2 are different but may be the same by
> > > chance.
> > >
> > > Routing Context parameter is mandatory in SUA traffic messages.
> > >
> > > In case of SE model could you please clarify
> > >
> > > Q2: What Routing Context values will be used in traffic messages
> > > between AS1 and AS2?
> > > Q3: Does it depend on the direction of the message?
> > >
> > > Q4: When RC1 is used and when RC2?
> > >
> > > Q5: what RC shall be used by response messages?
> > >
> > >
> > > Thank you in advance
> > >
> > > Ilie
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> > --
> > Brian F. G. Bidulock
> > [email protected]
> > http://www.openss7.org/
> >
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>