RE: SG view of the ASP
"Tolga Asveren" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
As far as I understand, the scenario presented by Krishna should follow the following flow: ASP1 SGP1 SGP2 | | | |---ASPAC(RC1)-->| | | | | |<-ASPAC-ACK(RC1)| | | | | |<-NTFY(AS1 ACT)-| | | | | | ASP1 is now | | ACTIVE for AS1 | | | | | AS1 is now | | ACTIVE | | | | |-------ASPAC(RC1|---------->| | | | |<------ASPAC-ACK(RC1)-------| | | | |<------NTFY(AS1 ACTIVE)-----| | | | | | ASP1 is now | | ACTIVE for AS1 | | | | | AS1 is now | | ACTIVE |---ASPIA(RC1)-->| | | | | |<-ASPIA-ACK(RC1)| | | | | |<-NTFY(AS1 INACT) | | | | | ASP1 is now | | INACTIVE for | | AS1| | | | | | AS1 is now | | INACTIVE | | Based on the following passage in his message: "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." I believe the problem is that SG executes SGP semantics as behaving as a single distributed SGP, but this will cause interoperability problems because an ASP would expect each SGP peer to execute these procedures separetly and independently. Please note that ASP will see each remote SCTP endpoint as a different SGP. > -----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 >