RE: M3UA notify message

"Haresign Lincoln" <[email protected]>
Newsgroups gmane.ietf.sigtran
Message-ID <849535E338E99741B7F7413F73253EDB033630CA@us-nj-mail1.comverse.com>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.