RE: AS, RK , RC concepts in SE model

Ilie,

> -----Original Message-----
> From: Ilie Glib [mailto:[email protected]]
> Sent: Tuesday, December 06, 2005 9:50 AM
> To: Tolga Asveren
> Cc: [email protected]
> Subject: Re: [Sigtran] AS, RK , RC concepts in SE model
>
>
> Hello Tolga, Brian,
>
> Thank you very much indeed for your clarifications. It  is hard for me
> to understand how on earth a concept of a sink (AS) has evolved to a
> concept of two sinks. Anyway,
[TOLGA]AS never has been a "sink", even not for ASP. An AS can both send
*and* receive messages. Like I said below, this concept has not changed at
all between ASP and SE-IPSP. Please note that on each SE-IPSP the 1:1
relationship between AS and RK still hold and it is still two different AS
communicating with SE-IPSP model. What has changed is only that RK defines
trafic range at both ends -which was also possible for an ASP with
RK=DPC+OPC-, to allow a peer-to-peer model.
> - is this view largely accepted by the SIGTRAN community?
[TOLGA]This is what has been described by RFC and the bis document, just not
very clearly.
> - Will other adaptation layers (say SUA) follow this model?
>
> I would expect a separate draft/RFC that describes this model, one
> draft per xxUA. As far as I understood a new WI is planned for M3UA
> (for SG to SG), will it cover this model? How about other xxUAs?
>
> Thank you in advance
>
> Ilie
>
> On 12/6/05, Tolga Asveren <[email protected]> wrote:
> > 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
> > >
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
>