RE: M3UA notify message

Just to supplement my view with a section from RFC: 

4.3.2 AS States

   The state of the AS is maintained in the M3UA layer on the SGPs.  The
   state of an AS changes due to events. These events include:
      * ASP state transitions
      * Recovery timer triggers

   Thanks,
   Tolga

> -----Original Message-----
> From: Tolga Asveren [mailto:[email protected]]
> Sent: Wednesday, February 22, 2006 3:11 PM
> To: [email protected]
> Subject: RE: [Sigtran] M3UA notify message
> 
> 
> Brian,
> 
> I think RFC is the consensus, not the mailing threads from 
> several years ago
> and I believe RFc is pretty clear about this issue.
> 
>    Thanks,
>    Tolga
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email protected]]
> > Sent: Wednesday, February 22, 2006 3:11 PM
> > To: Tolga Asveren
> > Cc: [email protected]
> > Subject: Re: [Sigtran] M3UA notify message
> >
> >
> > Tolga,
> >
> > I think you need to look at that mail thread, where you agreed
> > to the opposite when the RFC was formed.
> >
> > --brian
> >
> > Tolga Asveren wrote:
> >    (Wed, 22 Feb 2006 14:44:56)
> > > Brian,
> > >
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email protected]]
> > > > Sent: Wednesday, February 22, 2006 2:20 PM
> > > > To: Tolga Asveren
> > > > Cc: [email protected]
> > > > Subject: Re: [Sigtran] M3UA notify message
> > > >
> > > >
> > > > Tolga,
> > > >
> > > > The concensus, to which you agreed, was that each SGP maintains
> > > > its own ASP state, but that AS state is shared across the SGP
> > > > making up an SG.  That is, when notification of AS state is given,
> > > > it is consistent for all SGP in the SG.
> > > [TOLGA]I agree with the first part but disagree with the second
> > part. Notify
> > > procedures seem to be between ASP/SGP based on what it stands
> > in the RFC. It
> > > is true that SG needs to form a uniqie view of SPMC for the AS but I
> > > wouldn't think this corresponds to following SGP/ASP procedures
> > on a SG-wide
> > > basis. I consider Notify procedures as part of the SGP/ASP 
> relationship
> > > based on 4.3.4.5.
> > > >
> > > > If this were not the case, each SGP would form its own SG.  Part
> > > > of the fundamental purpose of an SG is to coordinate AS state,
> > > > both towards the SS7 network and towards the ASPs serving an AS.
> > > [TOLGA]I don't agree exactly with the last statement about SG
> > coordinating
> > > AS state towards ASPs. SG just aggregates the SPMC state towards SS7
> > > network. Each SGP maintains its own relationship with ASPs. It
> > is true that
> > > SGPs, which are  part of the same SG probably would be aware of
> > each others
> > > ASP states and would have an internal mechanism to route
> > messages between
> > > themselves but this kind of state sharing is not maintaining 
> a single AS
> > > state in terms of following ASP/SGP procedures described in the
> > > specification.
> > > >
> > > > This is, indeed, as Nitin indicates, reflected in section 1.4.1.
> > > >
> > > > See the thread "[M3UA] AS state maching sharing between SGPs" from
> > > > May of 2001 for reference.
> > > >
> > > > Therefore, when the AS state changes (on this SG-wide basis), all
> > > > ASPs attached to all SGP in the SG are notified.  This is why I
> > > > say that ASP2 is notified by SGP2 in the original question.
> > > [TOLGA]I think different. 4.3.4.5 Notify procedures speaks of
> > ASP/ASP states
> > > which is kept on SGPs. It also makes sense, because it is the 
> ASP state
> > > which is kept in SGP, is changing and is affecting whether
> > traffic could be
> > > sent/received via that SGP. that NTFY are advisory makes the
> > situation less
> > > drastic, but IMO changing NTFY for the state change on another
> > SGP is less
> > > than perfect.
> > > >
> > > > --brian
> > > >
> >
> > --
> > Brian F. G. Bidulock
> > [email protected]
> > http://www.openss7.org/
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>