RE: M3UA notify message
"Tolga Asveren" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Yes, this is also what I mean -I prefer the term aggregated SPMC status
instead of the SG view because it may include aggregating state of different
AS as well but it is conceptually the same thing-
Just to further clarify, ASP-INACTIVE, ASP-ACTIVE should be under SGP1, not
between SGP1 and SGP2. Originally I put it between them to symbolize that it
is a shared state in the SG.
This is a historical day for SIGTRAN WG, we seem to have a consesus with
more than one person :-)
Thanks,
Tolga
> -----Original Message-----
> From: Haresign Lincoln [mailto:[email protected]]
> Sent: Wednesday, February 22, 2006 5:20 PM
> To: [email protected]
> Cc: Tolga Asveren; [email protected]
> Subject: RE: [Sigtran] M3UA notify message
>
>
> Brian,
>
> You're right. My error. I guess the bottom line is that after the
> second ASPUP/ACTIVE transaction on SGP2, the overall state of the AS
> (and the ASP) from the SG's viewpoint does not change.
>
> Regards,
> Lincoln
>
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> Sent: Wednesday, February 22, 2006 5:17 PM
> To: Haresign Lincoln
> Cc: Tolga Asveren; [email protected]
> Subject: Re: [Sigtran] M3UA notify message
>
> 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/
> --------------------------------------------------------------------
> This email message has been scanned by Comverse mail security system
>