RE: M3UA notify message

Brian,

The AS state is just the combinatorial sum of the ASP states.

So I don't think that it makes sense to say that "each SGP maintains its own ASP state, but that AS state is shared
across the SGPs making up an SG" - this falls apart as soon as the ASP states differ on the SGPs.

Futhermore, "ASP state" doesn't exist in a vaccuum. Each ASP has a separate state in each AS to which it belongs. So I
think that the management of both AS and ASP states must be done at the same level - either at the SG or the SGP level.

So the next logical question is: "At which level"? I think that we have a big problem here. There are conflicting
answers in the RFC (draft-ietf-sigtran-rfc3332bis-06.doc). I think that we urgently need to get rid of these
contradictions.

Those in favor of maintenance at the SG level can point to the following:

>From section 1.4.1
<snip>
   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.
<snip>

Those in favor of maintenance at the SGP level can point to the following:

<snip>
1.3.2.4 Support for the Management of SCTP Associations between the SGP
and ASPs.

   The M3UA layer at the SGP maintains the availability state of all
   configured remote ASPs, to manage the SCTP Associations and the
   traffic between the M3UA peers.
<snip>

<snip>
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.
<snip>

<snip>
4.3.2 AS States

   The state of the AS is maintained in the M3UA layer on the SGPs.
<snip>

Barry Nagelberg
Adax, Inc.

-----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.

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.

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.

--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/

_______________________________________________
Sigtran mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sigtran