Re: M3UA notify message
"Brian F. G. Bidulock" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Organization | http://www.openss7.org/ |
| Message-ID | <[email protected]> |
Lincoln, The SG does not notify ASP state, it notifies AS state. So, a loadshare AS would look like this (just change ASP to AS under SG view): ASP1 SGP1 SGP2 SG view | | | | |----ASPUP------->| | | | | | | |<--ASPUP-ACK-----| | | | | | | | | ASP INACTIVE| AS INACTIVE | | | | |<--NTFY(INACTIVE)| | | | | | | |----ASPAC------->| | | | | | | |<---ASPAC-ACK----| | | | | | | | | ASP ACTIVE | AS ACTIVE | | | -------->SS7 control msgs if relevant |<--NTFY(ACTIVE)--| | | | | | | |------------ ASPUP------------>| | | | | | |<----------ASPUP-ACK-----------| | | | | | --brian Haresign Lincoln wrote: (Wed, 22 Feb 2006 17:10:39) > OK, I spoke to Barry and had a chance to review this further. I think > there is a two-tiered view (and I believe this might be what Brian is > saying). > > Each SGP needs to maintain it's own view of ASP1. However, there needs > to be an overall SG view of the ASP. So let me see if I can illustrate > this using the call flow. > > ASP1 SGP1 SGP2 SG view > | | | | > |----ASPUP------->| | | > | | | | > |<--ASPUP-ACK-----| | | > | | | | > | | ASP INACTIVE| ASP INACTIVE > | | | | > |<--NTFY(INACTIVE)| | | > | | | | > |----ASPAC------->| | | > | | | | > |<---ASPAC-ACK----| | | > | | | | > | | ASP ACTIVE | ASP ACTIVE > | | | -------->SS7 control msgs if relevant > |<--NTFY(ACTIVE)--| | | > | | | | > |------------ ASPUP------------>| | > | | | | > |<----------ASPUP-ACK-----------| | > | | | | > > > Regards, > Lincoln > > > -----Original Message----- > From: Tolga Asveren [mailto:[email protected]] > Sent: Wednesday, February 22, 2006 12:25 PM > To: [email protected] > Subject: RE: [Sigtran] M3UA notify message > > Let's consider the following scenario: > > There is ASP1 and SG1 which consists of SGP1/SGP2. SG1 keeps a single > SG-wide ASP state machine, instead of two indpendent ASP state machines > on each SGP. Below is the message flow and the ASP states for the > corresponding AS in the SG-wide ASP state machine. There are two > interesting steps, which are marked as (1) and (2). > > For (1), Error is totally unexpected for ASP. For (2), although it is > normal from ASP1 point of view to send DATA to SGP1 -because it should > be seeing > ASP1 as ACTIVE-, that DATA won't go anywhere. Furthermore ASP1 will be > assuming that it is connected to SS7 network through SGP1 but actually > after ASPDN/ASPDN-ACK exchnage with ASP2 it isn't from SG1 point of > view. > > ASP1 SGP1 SGP2 > | | | > |----ASPUP------->| | > | | | > |<--ASPUP-ACK-----| | > | | | > | | ASP INACTIVE| > | | | > |<--NTFY(INACTIVE)| | > | | | > |----ASPAC------->| | > | | | > |<---ASPAC-ACK----| | > | | | > | | ASP ACTIVE | > | | | > |<--NTFY(ACTIVE)--| | > | | | > |------------ ASPUP------------>| > | | | > |<----------ASPUP-ACK-----------| > | | | > |<--------Error---+-------------+ (1) > | (Unexpected Message) | > | | | > | | ASP INACTIVE| > | | | > |<--------NTFY(INACTIVE)--------| > | | | > |---------ASPDN---+------------>| > | | | > |<---------ASPDN-ACK------------| > | | | > | | ASP DOWN | > | | | > |-----DATA------->| | (2) > | | | > | | | > > > > Tolga > > > -----Original Message----- > > From: Barry Nagelberg [mailto:[email protected]] > > Sent: Wednesday, February 22, 2006 11:01 AM > > To: [email protected] > > Subject: RE: [Sigtran] M3UA notify message > > > > > > Tolga, > > > > Please illustrate how "interoperability would be broken" if each SGP > > doesn't run its own ASP state machine. Thanks. > > > > Barry Nagelberg > > Adax, Inc. > > > > -----Original Message----- > > From: Tolga Asveren [mailto:[email protected]] > > Sent: Wednesday, February 22, 2006 9:40 AM > > To: [email protected] > > Subject: RE: [Sigtran] M3UA notify message > > > > > > Prabind, > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] > > > Sent: Wednesday, February 22, 2006 9:49 AM > > > To: [email protected] > > > Subject: RE: [Sigtran] M3UA notify message > > > > > > > > > Tolga, > > > Right, but the question nitin asked is per AS! So suppose one AS > > > would provide one user part functionality and taking services from > > > multiple SGPs, then should't all SGPs share the information about > remote AS/ASPs? > > > I suppose that's the situation depicted. > > [TOLGA]Sharing information about them does not mean running a single > > ASP state machine in the SG. Each SGP runs its own ASP state machine > > and follows procedures described in the specification according to > > that. Otherwise interoperability would be broken. How to create a > > unique SPMC view is an implementation dependent issue. > > > > Nitin's question is about whether NTFY needs to be sent to ASP2 from > SGP1. > > If one follows the procedures defined in the RFC, it shouldn't be. > > NTFY for this case is sent to all ASPs which are not in DOWN state, > > when the state for an AS in a SGP changes. > > > > > > Please let me know which sections deals with: "State machines are > > > kept per SGP". > > [TOLGA]Have a look to 4.3 AS and ASP/IPSP State Maintainenece. All > > procedures are defined between ASP/SGP, not between ASP/SG. > > > > > > > > > Regards, > > > > > > Prabind > > > > > > > > > -----Original Message----- > > > From: Tolga Asveren [mailto:[email protected]] > > > Sent: Wednesday, February 22, 2006 7:41 PM > > > To: [email protected] > > > Subject: RE: [Sigtran] M3UA notify message > > > > > > Prabind, > > > > > > > -----Original Message----- > > > > From: [email protected] [mailto:[email protected]] > > > > Sent: Wednesday, February 22, 2006 9:19 AM > > > > To: [email protected] > > > > Cc: [email protected] > > > > Subject: RE: [Sigtran] M3UA notify message > > > > > > > > > > > > Nitin, > > > > Refer to section "1.4.1 Signalling Point Code Representation". It > > > > clearly says: > > > > "Where an SG contains more than one SGP, the MTP3 routeset, SPMC > and > > > > remote AS/ASP states of each SGP SHOULD be coordinated across > > > > all > > > the > > > > SGPs. Rerouting of traffic between the SGPs MAY also be > > > supported.: > > > > " > > > [TOLGA]This section refers to aggragating the unique SPMC view and > > > supporting the implementation dependent internal routing > functionality. > > > State machines are kept per SGP. > > > > > > 4.3 AS and ASP/IPSP State Maintenance > > > > > > The M3UA layer on the SGP maintains the state of each remote ASP, > in > > > each Application Server that the ASP is configured to receive > > > traffic, as input to the M3UA message distribution function. > > > Similarly, where IPSPs use M3UA in a point-to-point fashion, the > M3UA > > > layer in an IPSP maintains the state of remote IPSPs. > > > > Since SGP2 will know what SGP1 has, it will send notifications to > ASP. > > > > > > > > Regards, > > > > > > > > Prabind > > > > > > > > > > > > -----Original Message----- > > > > From: nitin [mailto:[email protected]] > > > > Sent: Wednesday, February 22, 2006 7:55 PM > > > > To: [email protected] > > > > Cc: [email protected] > > > > Subject: Re: [Sigtran] M3UA notify message > > > > > > > > hi , > > > > I think i had not explained my questions clearly . I am trying to > > > > explain them again . > > > > > > > > Please have a look at the diagram :- > > > > > > > > ----------- ----------- > > > > SGP1 SGP2 > > > > ---|-------- ----|-------- > > > > | | > > > > | | > > > > | | > > > > | | > > > > | | > > > > ------------ ---------- > > > > ASP1 ASP2 > > > > ------------ ----------- > > > > > > > > In this diagram, SGP1 and SGP2 are both part of SG1. ASP1 and ASP2 > > > > > are part of AS1. > > > > > > > > ASP1 has made sctp associatiion with SGP1 only . > > > > ASP2 has made sctp association with SGP2 only. > > > > AS is in override mode. > > > > > > > > ASP1 is INACTIVE at SGP1 and ASP2 is INACTIVE at SGP2. > > > > > > > > 1. Now, if ASP1 sends ASP ACTIVE message to SGP1 . will SGP2 be > > > sending > > > > notify for AS ACTIVE to ASP2. > > > > > > > > 2. If yes, now suppose ASP2 sends ACTIVE to SGP2 . > > > > Should Alternate ASP active notify be given to ASP1. > > > > If yes , in earlier discussions we have observed that Notify > > > should > > > > be > > > > done per SGP and not SG. > > > > > > > > 3. To add further , ASPSM, ASPTM, SSNM/SPMC ,notify messages be > > > > considered > > > > per SG or per SGP. > > > > > > > > 4. The question 4 that i had written in previous mail , i am > > > explaining > > > > again. > > > > In that question I was not very clear in saying that n+k was for > > > > SGP > > > or > > > > SG. > > > > > > > > Actually what i want to ask is that ..............n+k is per SG or > > > > > per SGP. > > > > > > > > For example :- suppose 2+1 architecture is there . Now SG has two > > > SGP's > > > > and > > > > AS has two ASP's. > > > > ASP1 is active on SGP1 and ASP2 is active on SGP2. > > > > Since in this case total number of active ASP's is two , we should > > > > > consider AS to be active at SG. > > > > > > > > OR > > > > suppose ASP1 and ASP2 are both active on SGP1 but none of them is > > > > on SGP2. > > > > So in that case also > > > > the number of ASP's active is two. Should we consider AS active at > > > > > SG > > > in > > > > this case . > > > > > > > > Which of the above two cases is valid or both. > > > > > > > > ----- Original Message ----- > > > > From: "Brian F. G. Bidulock" <[email protected]> > > > > To: "nitin" <[email protected]> > > > > Cc: <[email protected]> > > > > Sent: Wednesday, February 22, 2006 5:19 PM > > > > Subject: Re: [Sigtran] M3UA notify message > > > > > > > > > > > > > nitin, > > > > > > > > > > nitin wrote: (Wed, 22 Feb 2006 > > > > 17:28:49) > > > > > > Hi, > > > > > > if this is the case, then what will happen when(4 cases given > > > below > > > > are > > > > > > different from each other) :- > > > > > > 1. AS(consisting of ASP1 and ASP2) is active at SG (consisting > > > > > > > of > > > > SGP1 > > > > and > > > > > > SGP2) since ASP1 has done ASP active at SGP1. AS is in > > > > > > override > > > mode > > > > and > > > > now > > > > > > ASP2 sends ASP active message to SGP2 , now what will happen. > > > Should > > > > SGP1 > > > > > > send alternate ASP active notify to ASP1 and mark ASP2 as > active. > > > > But if > > > > > > such is the case , ASP2 has not yet formed the association > > > > > > with > > > > SGP1. > > > > > > > > > > SGP2 sends it. > > > > > > > > > > > 2. should the SS7 traffic of SGP2 be routed through SGP1 since > > > > AS(load > > > > share > > > > > > mode) is active(ASP1 has done active at SGP1) and SGP2 has > > > > > > already > > > > sent > > > > the > > > > > > notify for AS active to ASP2. > > > > > > > > > > Yes. > > > > > > > > > > > 3. If AS is in loadshare mode (rest of the configuration same > > > > > > > as > > > in > > > > 1) > > > > . > > > > > > Now when ASP2 sends active to SGP2 , should notify be sent > > > > > > again > > > to > > > > the > > > > > > ASP2. > > > > > > > > > > What Notify? > > > > > > > > > > > 4. In n+k architecture should this n be taken for SG or this > > > > > > is > > > for > > > > SGP. > > > > I > > > > > > mean to say AS should become active at SG (when it is active > > > > > > at n > > > > SGP's > > > > , > > > > > > supposing single ASP of AS is active at each of n SGP)or > > > > > > (should n > > > > ASP's > > > > be > > > > > > active at any SGP) or (n ASP's should be active only no matter > > > where > > > > and > > > > how > > > > > > they are). > > > > > > > > > > n+k refers to ASPs (and possibly IPSPs), not SGPs. > > > > > > > > > > > > > > > > > There was an earlier mail (copied below) , in which SGP2 sends > > > > notify > > > > again > > > > > > to ASP which should not happen if we are going according to > > > > > > the > > > > current > > > > > > scenario. > > > > > > > > > > The extra Notify is redundant (but not forbidden). > > > > > > > > > > --brian > > > > > > > > > > -- > > > > > Brian F. G. Bidulock > > > > > [email protected] > > > > > http://www.openss7.org/ > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > No virus found in this incoming message. > > > > > Checked by AVG Free Edition. > > > > > Version: 7.1.375 / Virus Database: 268.0.0/266 - Release Date: > > > > 2/21/2006 > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > _______________________________________________ > > Sigtran mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > Sigtran mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/sigtran > -------------------------------------------------------------------- > This email message has been scanned by Comverse mail security system > > _______________________________________________ > Sigtran mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock [email protected] http://www.openss7.org/