Re: SG view of the ASP

Ilie Glib <[email protected]> Fri, 10 Feb 2006 18:38:38 +0100
Newsgroups	gmane.ietf.sigtran
Message-ID	<[email protected]>
Hello Tolga,

First sentence

>       The optional ASP Identifier parameter contains a unique value that
>       is locally significant among the ASPs that support an AS.

looks confusing because of "AS" at the end. ASP_UP can be sent before
any knowledge about ASes is available in SG. Therefore ASP ID shall
have SG or SGP uniqueness scope. I would prefer SGP scope, to fit the
IPSP-IPSP traffic case best.

In case of IPSP-IPSP, all remote SUA peers of an IPSP shall have
different ASP_IDs.

Regards

Ilie

On 2/10/06, Tolga Asveren <[email protected]> wrote:
> 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
>


--
Ilie