RE: M3UA notify message

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
>
> Tolga Asveren wrote:
>    (Wed, 22 Feb 2006 09:10:52)
> > 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
> > >
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>