Ilie,

An AS is a User (MTP-User, SCCP-User).  In a peer-to-peer signalling
relation without relay or transfer, there are two Users, however,
there is only one signalling relation.  Each end has an address.
the pair of addresses defines the signalling relation.  A signalling
relation is an RK, and an RC.

As Tolga puts it well, at one IPSP, there is a 1:1:1 relationship
between an AS (local concept) and RC and an RK.  Same at the other.
The RCs are the same and the RK's are symmetric (both define the
signalling relation from the view at only one end).  If you know
one RK you know the other.  Each end defines an AS (without relay)
and both form one signalling relation.

--brian


Ilie Glib wrote:                                                      (Tue, 06 Dec 2005 15:49:36)
> 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,
> - is this view largely accepted by the SIGTRAN community?
> - 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 <asveren@ulticom.com> wrote:
> > Ilie,
> >
> > > -----Original Message-----
> > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On
> > > Behalf Of Ilie Glib
> > > Sent: Tuesday, December 06, 2005 6:10 AM
> > > To: bidulock@openss7.org; Ilie Glib; sigtran@ietf.org
> > > 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 <bidulock@openss7.org> 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
> > > > > Sigtran@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > >
> > > > --
> > > > Brian F. G. Bidulock
> > > > bidulock@openss7.org
> > > > http://www.openss7.org/
> > > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > Sigtran@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > Sigtran@ietf.org
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> 
> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/

_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran