RE: SG view of the ASP

Tolga,

You are making this up. There is no statement in the spec such as "ASP/SGP relationship/state machines are kep on each
SGP separetly".

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of Tolga Asveren
Sent: Thursday, February 09, 2006 12:55 PM
To: [email protected]
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 protected] [mailto:[email protected]]On
> Behalf Of Munnaluru, Krishna
> Sent: Thursday, February 09, 2006 12:35 PM
> To: [email protected]
> Cc: [email protected]
> 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 protected]]
> Sent: Thursday, February 09, 2006 11:15 AM
> To: Munnaluru, Krishna
> Cc: [email protected]
> 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 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