RE: SG view of the ASP
"Tolga Asveren" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Barry, I think some passage similar to what we have for SUA is most appropriate, because it covers the generic use of ASP-Id for ASP identifying purposes. Please also have a look to "Multiple SCTP associations" thread, starting 1/10/2006, where the issue of multiple associations between signaling peers is discussed. Thanks, Tolga > -----Original Message----- > From: [email protected] [mailto:[email protected]]On > Behalf Of Barry Nagelberg > Sent: Friday, February 10, 2006 1:59 PM > To: [email protected] > Subject: RE: [Sigtran] 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 > > > _______________________________________________ > Sigtran mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/sigtran >