RE: M3UA notify message

Lincoln,

As long as it does not effect interoperability, I would agree with you, but
I believe it may -please see the message flow I sent in this thread-.

   Thanks,
   Tolga

> -----Original Message-----
> From: Haresign Lincoln [mailto:[email protected]]
> Sent: Wednesday, February 22, 2006 3:52 PM
> To: Tolga Asveren; [email protected]
> Subject: RE: [Sigtran] M3UA notify message
>
>
> 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:[email protected]]
> Sent: Wednesday, February 22, 2006 3:28 PM
> To: [email protected]
> 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:[email protected]]
> > Sent: Wednesday, February 22, 2006 3:47 PM
> > To: [email protected]
> > 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:[email protected]]
> > Sent: Wednesday, February 22, 2006 2:55 PM
> > To: [email protected]
> > Subject: RE: [Sigtran] M3UA notify message
> >
> >
> > Barry,
> >
> > > -----Original Message-----
> > > From: Barry Nagelberg [mailto:[email protected]]
> > > Sent: Wednesday, February 22, 2006 3:06 PM
> > > To: [email protected]
> > > 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:[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
> > >
> > >
> > > _______________________________________________
> > > 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
>