RE: SG view of the ASP
"Tolga Asveren" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Ilie, > -----Original Message----- > From: Ilie Glib [mailto:[email protected]] > Sent: Friday, February 10, 2006 12:39 PM > To: Tolga Asveren > Cc: [email protected] > Subject: Re: [Sigtran] SG view of the ASP > > > 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. [TOLGA]I think the idea was to coordinate the ASP-Id among ASPs serving a specific AS in a way -which is impelementation dependent-, where each ASP is assigned a unique ASP-Id. Once this is done on ASP side, I don't see why knowledge about SG side is necessary but I may be missing something. > > 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 >