Subject: RE: [Sigtran] SG view of the ASP

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 9 Feb 2006 15:01:32 -0500

Tolga,

The problem with this is that if ASP1 becomes inaccessible from SGP1,
but SGP2 can still talk to ASP1, what should the SG send to the SS7
network?  If SGP1 is not aware that SGP2 can still talk to ASP1, then it
might send out an SSP.  Or am I missing something in your explanation?

There needs to be an overall view that is coordinated amoung SGPs in one
central place in order to manage the view of the ASPs out in to the SS7
network.

Regards,
Lincoln 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tolga Asveren
Sent: Thursday, February 09, 2006 2:33 PM
To: [email-masked]
Subject: RE: [Sigtran] SG view of the ASP

Ooppppss a typo...

ASP2 should read SGP2.

   tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Tolga Asveren
> Sent: Thursday, February 09, 2006 2:08 PM
> To: [email-masked]
> Subject: RE: [Sigtran] SG view of the ASP
>
>
> Bary,
>
> I was maybe not clear from english language point of view.
>
> What I tried to say is:
>
> There is SGP1 and SGP2 and ASP1. SGP1 and SGP2 are part of SG1. SGP1 
> interacts only with a single ASP, i.e. ASP1. ASP2 interacts only with 
> a single ASP, i.e. ASP1. Each SGP keeps their own state machine tables

> for ASPs. Because each of them has only a single ASP in their lists, 
> that ASP will be the only ACTIVE ASP from both SGP point of view.
>
>     Tolga
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Barry Nagelberg
> > Sent: Thursday, February 09, 2006 2:17 PM
> > To: [email-masked]
> > Subject: RE: [Sigtran] SG view of the ASP
> >
> >
> > Tolga,
> >
> > You are contradicting yourself. If "ASP/SGP relationship/state 
> > machines are kep on each SGP separetly", then how can these two 
> > separate SGPs know that they are interacting with a
> single ASP?
> >
> > Barry Nagelberg
> > Adax, Inc.
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Tolga Asveren
> > Sent: Thursday, February 09, 2006 12:55 PM
> > To: [email-masked]
> > Subject: RE: [Sigtran] SG view of the ASP
> >
> >
> > Krishna,
> >
> > Your expectation is how it is supposed to work. ASP/SGP
> relationship/state
> > machines are kep on each SGP separetly. In your example, both SGPs 
> > are interacting with a single ASP, and from their point of view, it 
> > is the only ACTIVE ASP.
> >
> >    tolga
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On
> > > Behalf Of Munnaluru, Krishna
> > > Sent: Thursday, February 09, 2006 12:35 PM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: [Sigtran] SG view of the ASP
> > >
> > >
> > > Brian,
> > >
> > > This is how it is affecting my expected behavior.
> > >
> > > Note: Currently I have only one ASP but in future I intend to add 
> > > a standby ASP. Hence I use the trafficmode=override in the
> messages. Also
> > > the desired behavior is that the ASP to laodshare the traffic 
> > > going to the SG among the two SGPs.
> > >
> > > The problem showed up during the following scenario:
> > >
> > > The ASP comes up, establishes associations and sends ASP UP 
> > > message (ASPIdentifier = 10007) to both SGPs for which the SGPs
> respond with ASP
> > > UP ACK.
> > >
> > > The ASP sends ASP ACTIVE (trafficmode=override) with a routing 
> > > context for the AS to the SGP1 and the SGP1 responds with ASP 
> > > ACTIVE ACK. The status on the SG shows that the AS is active on 
> > > SGP1 and inactive on SGP2.
> > >
> > > Later the ASP sends ASP ACTIVE (trafficmode=override) with the 
> > > same routing context to the SGP2 and the SGP2 responds with ASP
ACTIVE ACK.
> > > The status on the SG shows that the AS is active on SGP2 and
> inactive on
> > > SGP1. I was expecting the AS to be active on both SGPs since
> the ASP had
> > > sent ASP ACTIVE to both SGPs.  This was not what I was expecting.
> > >
> > > The explanation given by the Third party SG team is that since 
> > > they treat association from SGP1 to ASP as one ASP (ASP1) and the
> association
> > > from SGP2 to ASP as a separate ASP (ASP2), they are over writing 
> > > the status when the SGP2 received the ASP ACTIVE message from the
> ASP. They
> > > suggest that I put the trafficmode=loadshare and that would solve 
> > > the problem.  So I am really confused.
> > >
> > > Hope this helps.
> > >
> > > Thanks,
> > > Krishna
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Thursday, February 09, 2006 11:15 AM
> > > To: Munnaluru, Krishna
> > > Cc: [email-masked]
> > > Subject: Re: [Sigtran] SG view of the ASP
> > >
> > > Krishna,
> > >
> > > How is the behaviour different?
> > >
> > > --brian
> > >
> > > Munnaluru, Krishna wrote:                       (Thu, 09 Feb 2006
> > > 10:23:19)
> > > >
> > > >    Hi,
> > > >
> > > >
> > > >    I  am implementing ASP and we are trying to interop with a 
> > > > third
> > > party
> > > >    SG. The following is the scenario.
> > > >
> > > >
> > > >    We  have  one  ASP  and  one  SG  containing  two  SGPs.
>  The  ASP
> > > is
> > > >    establishing  one  SCTP  association  with  each  SGP
> (a total of
> > > two
> > > >    associations).
> > > >
> > > >
> > > >    The problem is that the SG is treating each association as a
> > > different
> > > >    ASP.  So it thinks that there are two separate ASPs in
> the network.
> > > Is
> > > >    this  the  correct  behavior?  My  understanding is that the 
> > > > SG
> > > should
> > > >    treat  it  as  "two associations to the same ASP (from
> each SGPs)"
> > > and
> > > >    NOT "as two separate ASPs".
> > > >
> > > >
> > > >    Could someone please comment on this behavior?
> > > >
> > > >
> > > >    Thanks in advance,
> > > >
> > > >    Krishna
> > >
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > >
> > > --
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > >
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran
--------------------------------------------------------------------
This email message has been scanned by Comverse mail security system

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 9 Feb 2006 14:56:07 -0500

Lincoln,

> From: Haresign Lincoln [mailto:[email-masked]]
> Sent: Thursday, February 09, 2006 3:02 PM
> To: Tolga Asveren; [email-masked]
[TOLGA]In such a case what I expect to happen is SGP1 to send messages it
receives from SS7 network to SGP2 so that it can send it to ASP1. Such a
mechanism -which is implementation dependent- would be necessary even if one
wants to keep a single ASP state machine in SG.
> central place in order to manage the view of the ASPs out in to the SS7
[TOLGA]That is true, but this does not mean to keep a single ASP state
machine in SG. Each SGP will have their own ASP state machines, and some
other mechanims -which is implementation dependent- will coordinate the
unique SPMC view. Such a mechanism is necessary not only to coordinate
different ASP state in different SGPs but also to aggregate the PC status as
well, if RKs in User Part granularity are used.