Re: sending ASP UP in IPSP SE

Hello Brian, et al.

here is a copy of an old mail. Enjoy it

BR //Ilie


---------- Forwarded message ----------
From: Ilie Glib <[email protected]>
Date: Tue, Dec 6, 2005 at 5:11 PM
Subject: Re: [Sigtran] AS, RK , RC concepts in SE model
To: [email protected], Ilie Glib <[email protected]>, Tolga
Asveren <[email protected]>, [email protected]


Brian,

perfect, I was exactly after this statement.

Now, we have consensus.

Thank you very much indeed.

Ilie

On 12/6/05, Brian F. G. Bidulock <[email protected]> wrote:
> 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 <[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
> > >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>



-- 
Ilie


On Tue, Nov 23, 2010 at 10:50 AM, Ilie Glib <[email protected]>wrote:

> And how would they automatically register?
>
> Which SPC would would be DPC and which OPC in the RK?
>
>   On Mon, Nov 22, 2010 at 4:03 PM, Brian F. G. Bidulock <
> [email protected]> wrote:
>
>> Ilie,
>>
>> Ilie Glib wrote:
>>                (Mon, 22 Nov 2010 13:57:12)
>> >
>> >    we had this discussion ages ago, and as far as I remember our
>> >    conclusion was that in the SE IPSP to IPSP scenario one has two ASes
>> -
>> >    one on each side. They have symmetric RKs and a same value of the RC.
>>
>> No.  One AS, one RC, one RK, describing both directions of traffic.
>>
>> --brian
>>
>> --
>> Brian F. G. Bidulock
>> [email protected]
>> http://www.openss7.org/
>>
>
>
>
> --
> Ilie
>



-- 
Ilie

_______________________________________________
Sigtran mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sigtran