RE: SG view of the ASP

Tolga,

There is no misinterpretation. The problem presented by Krishna is _precisely_ 2 ASPs connecting to the same SG.

If the word "SG" in my suggested text makes you uncomfortable, though, then please change it to "SGP". It's the same
problem - there is no prohibition in the spec against multiple associations between an ASP and an SGP.

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of Tolga Asveren
Sent: Friday, February 10, 2006 12:18 PM
To: [email protected]
Subject: RE: [Sigtran] SG view of the ASP


Barry,

The fundamental problem in the case Krishna presented is that SG rather than
SGP is seen as the signaling peer for ASPTM/ASPSM, which is not correct. I
don't think we should have a change to legitimize such a misinterpretation
of the M3UA specification. The text you proposed speaks about SG as a peer
for ASPSM, wich is not correct. The concept of SG comes into play only for
SSNM.

Actually I was suprised that the use of AspId for dynamic SCTP addresses is
not already there, because it has been discussed many times in this mailing
list.

    Tolga

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Barry Nagelberg
> Sent: Friday, February 10, 2006 12:28 PM
> To: [email protected]
> Subject: RE: [Sigtran] SG view of the ASP
>
>
> Tolga,
>
> Thanks, but I prefer the text that I offered - the case that
> we're discussing has nothing to do with dynamic SCTP
> addresses.
>
> Barry Nagelberg
> Adax, Inc.
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Tolga Asveren
> Sent: Friday, February 10, 2006 11:34 AM
> To: [email protected]
> Subject: RE: [Sigtran] SG view of the ASP
>
>
> I agree that a clarification could be useful. What about the following:
>
>     ASP Identifier: 32-bit unsigned integer
>
>        The optional ASP Identifier parameter contains a unique value that
>        is locally significant among the ASPs that support an AS.
>
>        This parameter identifies the physical ASP that is using this SCTP
>        association when the SCTP endpoint address used by ASP is dynamic,
> 	 e.g. where ASP is using an ephemeral SCTP port.
>
>        The SGP should save the ASP Identifier to be used, if necessary,
>        with the Notify message (see Section 3.8.2).
>
> All ASPAC/ASPUP etc... procedures are considering ASP and SGP as signaling
> peers. I don't see why we should try to change the signaling semantics for
> ASPSM/ASPTM to apply between ASP and SG rather than between ASP and SGP.
>
>     thanks,
>     tolga
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]On
> > Behalf Of Barry Nagelberg
> > Sent: Friday, February 10, 2006 11:41 AM
> > To: [email protected]
> > Subject: RE: [Sigtran] SG view of the ASP
> >
> >
> > All,
> >
> > There seems to be a consensus on the list that an SG with 2 SGPs
> > should be aware that there is one physical ASP with 2
> > SCTP associations (one to SGP1 and one to SGP2), and not assume
> > that there are 2 ASPs. The consensus also seems to be
> > that the method of informing the SG should be via the ASP Id
> > param in the ASPUP msg.
> >
> > I am OK with this consensus, but if we want to adopt this
> > consensus we must update the spec in regard to the definition
> > of the ASP Id param. It currently says:
> >
> > <snip>
> >    ASP Identifier: 32-bit unsigned integer
> >
> >       The optional ASP Identifier parameter contains a unique value that
> >       is locally significant among the ASPs that support an AS.  The SGP
> >       should save the ASP Identifier to be used, if necessary, with the
> >       Notify message (see Section 3.8.2).
> > <snip>
> >
> > This description is misleading, in that it implies that the only
> > use for the ASP Id is in the NTFY msg. In fact, this is
> > the ONLY use described in the entire spec for the ASP Id param.
> >
> > I suggest the following text for this param:
> >
> > <snip>
> >    ASP Identifier: 32-bit unsigned integer
> >
> >       The optional ASP Identifier parameter contains a unique value that
> >       is locally significant among the ASPs that support an AS.
> >
> >       This parameter identifies the physical ASP that is using this SCTP
> >       association, in the case where an ASP is using more than one
> >       association to communicate with the SG.
> >
> >       The SGP should save the ASP Identifier to be used, if necessary,
> >       with the Notify message (see Section 3.8.2).
> > <snip>
> >
> > Barry Nagelberg
> > Adax, Inc.
> >
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]On
> > Behalf Of Samuel Dur D. Jeyaseelan
> > Sent: Friday, February 10, 2006 4:49 AM
> > To: [email protected]
> > Subject: RE: [Sigtran] SG view of the ASP
> >
> >
> >
> > Few comments inline.
> >
> >   Alcatel USA, Inc.                  Internet:
> > <userid>@ssd.usa.alcatel.com
> >   1000 Coit Road, Plano, Texas 75075
> >   ******* The opinions expressed are not those of Alcatel USA,
> > Inc. *******
> >
> > On Thu, 9 Feb 2006, Munnaluru, Krishna wrote:
> >
> > > The ASP is currently sending the ASP UP message with the same
> ASP Id to
> > > both SGPs.
> > >
> > > As per the SG guys suggestion we temporarily changed the ASP
> trafficmode
> > > in the ASP ACTIVE message to loadsharing and this problem
> goes away. But
> > > we see another problem.
> > >
> > > The administrator on the ASP side decides to take down the SCTP
> > > association with SGP2. The ASP sends ASP DOWN message to the
> SGP2. Then
> > > the SGP2 responds with ASP DOWN ACK. So far everything looks good. But
> > > then immediately the SGP1 sends a NOTIFY with the status=ASP
> Failure and
> > > includes the Routing Context value. Why is the SGP1 sending
> this NOTIFY
> > > and what is the expected behavior of the ASP upon receiving the NOTIFY
> > > from the SGP1? The SG is sending the NOTIFY because it treats
> the ASP as
> > > two separate ASPs and so it thinks that it is notifying to the other
> > > ASP.
> > >
> > > I think it came down to the way SG was designed - "The SG
> treating each
> > > association as a separate ASP as supposed to just one ASP with two
> > > associations".  Is this the general way a SG behaves (or designed)?
> > > Should it not treat an ASP as just one rather than two?
> > >
> > > Please provide some input so that I can confirm my
> understanding of the
> > > M3UA protocol.
> > It seems to be a problem with SG's implementation. following are the
> > drawbacks with the SG you are using.
> >
> > 1.SG views two physical ASPs, eventhough you have one physical ASP.
> >   In override traffic mode,as per your mail an ASP has registered with
> >   two SGPs(SGP1 and SGP2) using the same ASP id in the ASP_UP message
> >   then ASP sends ACTIVE message to SGP1 so whole AS becomes
> active at SG.
> >
> >   When SGP2 receives ACTIVE message, SGP1 sends NTFY(ALT_ASP_ACT) with
> >   the same ASP id. This is not a correct behaviour of handling override
> >   traffic mode. If the complete physical ASP goes down, then
> >   alternate(standby) ASP should be able to send ACTIVE message
> but you can
> >   not achieve this with your current configuration.
> >
> > 2.NTFY messages ALT_ASP_ACTIVE and ASP_FAILURE have ASP id but the same
> >   ASP id is used in other SGPs.
> >
> > --Samuel
> >
> >
> >
> > >
> > > Thanks,
> > > Krishna
> > >
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email protected]]
> > > Sent: Thursday, February 09, 2006 12:21 PM
> > > To: Munnaluru, Krishna
> > > Cc: [email protected]
> > > Subject: Re: [Sigtran] SG view of the ASP
> > >
> > > Krishna,
> > >
> > > I suppose you could try adding ASP Id to the ASP Up message and see
> > > if the SG recognizes the ASP as one.
> > >
> > > However, as Ille suggests, perhaps the problem is the SG's traffic
> > > mode (rather than the AS's traffic mode).
> > >
> > > If the SG really believes that the ASP is two distinct ASPs, it should
> > > be sending a NOTIFY("Alternate ASP Active") from SGP1.  If it
> does not,
> > > IMO it is just a bug, so, perhaps the SG does not truly
> support Active/
> > > Standby mode.
> > >
> > > --brian
> > >
> > >
> > > Munnaluru, Krishna wrote:                    (Thu, 09 Feb
> 2006 11:34:46)
> > > > 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
> > > >
> >
> >
> > _______________________________________________
> > 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
>



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