Re: [Sigtran] M3UA notify message

["Brian F. G. Bidulock" <[e-mail]>]

Lincoln,

The SG is required to reveal its coordinated view of AS state to
attached ASPs using the Notify message.  This coordinated view
is also used for providing a SPMC management view both towards
the SS7 networks and towards MTP Users at ASPs using SNMM messages.

This is the reason for the "SHOULD" language in 1.4.1.  If the
SG does not coordinate both AS state and SPMC view, interoperability
problems such as those raised on this an recent threads will ensue.

--brian

Haresign Lincoln wrote:                                           (Wed, 22 Feb 2006 15:51:50)
> Perhaps I'm mistaken, but this whole discussion seems to be
> implementation specific and shouldn't really relate to the outside view
> of the SG.  Please correct me if I'm wrong.
> 
> Regards,
> Lincoln 
> 
> -----Original Message-----
> From: Tolga Asveren [mailto:[e-mail]] 
> Sent: Wednesday, February 22, 2006 3:28 PM
> To: [e-mail]
> Subject: RE: [Sigtran] M3UA notify message
> 
> Barry,
> 
> Let me retry to explain my position:
> 
> Coordination of AS/ASP is necessary to create the unique SPMC view. This
> does not mean that the coordinated state should be used for M3UA
> procedures on each SGP. Each SGP should maintain its own staet machine
> from ASP/SGP procedures point of view.
> 
>     Tolga
> 
> > -----Original Message-----
> > From: Barry Nagelberg [mailto:[e-mail]]
> > Sent: Wednesday, February 22, 2006 3:47 PM
> > To: [e-mail]
> > Subject: RE: [Sigtran] M3UA notify message
> >
> >
> > Tolga,
> >
> > You are wrong. Section 1.4.1 is not only about SPMC.
> >
> > It specifically says "SPMC and remote AS/ASP states of each SGP SHOULD
> 
> > be coordinated across all the SGPs."
> >
> > Barry Nagelberg
> > Adax, Inc.
> >
> > -----Original Message-----
> > From: Tolga Asveren [mailto:[e-mail]]
> > Sent: Wednesday, February 22, 2006 2:55 PM
> > To: [e-mail]
> > Subject: RE: [Sigtran] M3UA notify message
> >
> >
> > Barry,
> >
> > > -----Original Message-----
> > > From: Barry Nagelberg [mailto:[e-mail]]
> > > Sent: Wednesday, February 22, 2006 3:06 PM
> > > To: [e-mail]
> > > Subject: RE: [Sigtran] 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>
> > [TOLGA]This section is about Signalling Point Code Representation. To 
> > give the SG-wide unique view for the SPMC, one needs to coordinate 
> > AS/ASP states, but IMO this does not mean running a single ASP/AS 
> > state machine from M3UA procedures point of view, e.g. AS:PC=1-1-1, 
> > and there are two SGPs in the SG. Unless AS is INACTIVE in both of 
> > them, SPMC will be AVAILABLE but each SGP is running its own ASP state
> 
> > machine and following M3UA procedures independently. The result of a 
> > such coordination could be considered as the "global ASP state" but I 
> > think it shouldn't affect M3UA procedures between SGP and ASP.
> > >
> > > 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:[e-mail]]
> > > Sent: Wednesday, February 22, 2006 2:20 PM
> > > To: Tolga Asveren
> > > Cc: [e-mail]
> > > 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: [e-mail] 
> > > > > [mailto:[e-mail]]
> > > > > Sent: Wednesday, February 22, 2006 9:19 AM
> > > > > To: [e-mail]
> > > > > Cc: [e-mail]
> > > > > 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
> > > [e-mail]
> > > http://www.openss7.org/
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> > _______________________________________________
> > Sigtran mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/sigtran
> --------------------------------------------------------------------
> This email message has been scanned by Comverse mail security system
> 
> _______________________________________________
> Sigtran mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/sigtran

-- 
Brian F. G. Bidulock
[e-mail]
http://www.openss7.org/

_______________________________________________
Sigtran mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sigtran