RE: Re: [M3UA] AS state machine sharing between SGPs

Brian,


I am fine with 1), it basically tells that ASPTM/ASPSM is between ASP/SGP
and for corresponding procedures ASP state is kept separate at each SGP.
Actually, this is the most important point in thread IMO from
interoperability point of view.

I agree with 2) too, it is necessary to create the unique SPMC view -and
maybe for NTFY depending on interpretation (please see below)- but this
state shouldn't be used for ASPSM/ASPTM procedures.

I agree with 3) as well.

I assume 4) is mainly concerning NTFYs(?)

IMHO, two questions still need to be answered:
1)Is advertising global AS state with NTFY, what we really want? It seems
like my argument of 5 years ago was not non-sense. OTOH, one could also
argue that if ASP state is kept per SGP and if NTFYs are going to be used to
possibly trigger some activity on ASPs, isn't it logical to expect that this
trigger is originating from the SGP, which wants a certain ASP do perform
some action?
2)Regardless of the answer to 1), do we need text changes?


    Tolga

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> Sent: Wednesday, February 22, 2006 4:52 PM
> To: Tolga Aversen
> Cc: [email protected]
> Subject: [Sigtran] Re: [M3UA] AS state machine sharing between SGPs
>
>
> Tolga,
>
> You appear to have forgotten this whole discussion.  Here was the
> conclusion that lead to the statements in 1.4.1 (at your request).
> Greg notes that it is not always required to aggregate AS state:
> that is, when there is only one SGP per SG, or when only one SGP
> in the SG serves each AS.
>
> Does this settle the matter... again?
>
> --brian
>
> Sidebottom, Greg [BCNR:7M01:EXCH] wrote:
> (Fri, 27 Apr 2001 14:29:05)
> >
> >    Greetings,
> >
> >    I'd  hoped  to  avoid this because I'm not implementing this
> approach,
> >    but here is a stab at a proposed conclusion:
> >
> >    1) Each ASP-SGP association uses the M3UA protocol independently
> >
> >    For  example,  where an ASP is connected to two SGPs, it
> MUST initiate
> >    ASP-Up,  REG, ASP-Active independently on both associations.
>  Each SGP
> >    responds  accordingly.    This  keeps the protocol common
> and does not
> >    force an ASP to know which SGPs form what SGs.  However,
> some ASPs MAY
> >    wish  to maintain knowledge of the SGPs in an SG to help
> interpret any
> >    Notification  of AS-state changes.  The ASP achieves SGP
> redundancy by
> >    sending traffic to any two (or more) SGPs on different
> hosts.  Network
> >    Operators  must  ensure  that  the  two SGPs are actually on
> different
> >    hosts  and,  if  forming part of the same SG, the ASPs can
> achieve any
> >    inter-SGP communication required.
> >
> >    2) Overall SG state of an AS is required where more than one
> SGP in an
> >    SG support the same AS.
> >
> >    Each SGP keeps local AS/ASP status based on the status of
> the ASPs via
> >    a  local association.  Where two or more SGPs in an SG
> maintain status
> >    of  the  same  AS,  these  must  be  aggregated  into an
> overall SG AS
> >    status.  How this is done is implementation dependent.  This
> status is
> >    required to avoid potential traffic loss to the ASPs and to
> coordinate
> >    any SS7 management procedures to the SS7 network.
> >
> >    3)  Inter-SGP  communication  and  traffic  handling  within
>  an SG is
> >    implementation dependent.
> >
> >    This  communication  is  required  to support the AS state
> control and
> >    traffic  routing  between SGPs when SGP local knowledge of
> an AS state
> >    diverges  between SGPs in an SG.  An overall SG view of each
> AS served
> >    by  the  SG  is  required  to make this traffic routing
> possible.  For
> >    example,  where  an SGP locally determines that an AS has
> transitioned
> >    to  inactive,  it  must  check  with  all  other SGPs in the
> SG before
> >    discarding any traffic.
> >
> >    4) Figure 1 will be updated to the view expressed by Tolga.
> >
> >    There  are  some  real  challenges  for  the  SGPs  to
> operate in this
> >    environment,  including  some  state  convergence issues not
> mentioned
> >    above, but I don't see any way around it.   I think I'd
> rather use the
> >    redundant SG approach - that way my brain doesn't hurt so much   2:^(
> >
> >    As  for  Tolga's  point  below,  AS  state sharing between
> SGPs is not
> >    always  required.    State  sharing requirements would be
> dependent on
> >    there being more than one SGP in an SG and also whether the
> same AS is
> >    available via two or more of the SGPs in the same SG.
> >
> >    Cheers,
> >
> >      Greg
> >
> >     -----Original Message-----
> >    From:   Asveren, Tolga [[1]mailto:[email protected]]
> >    Sent:   Friday, April 27, 2001 10:20 AM
> >    To:     sigtran
> >    Subject:        RE: [M3UA] AS state machine sharing between SGPs
> >
> >    Hi all,
> >
> >    I  have  to say I also wait for a conclusion for this topic.
> According
> >    to  me, as long as there is the concept of SGP, AS states
> between them
> >    should  be  shared.  Otherwise,  I  cannot  see any reason
> to have the
> >    concept  of  SGP.  I don't think this is an implementation
> issue and I
> >    think this topic should be clarified.
> >
> >      Regards,
> >      Tolga
> >
> >    -----Original Message-----
> >    From: [email protected] [[2]mailto:[email protected]]
> >    Sent: Wednesday, April 25, 2001 8:22 AM
> >    To: sigtran
> >    Subject: RE: [M3UA] AS state machine sharing between SGPs
> >
> >    Hi all,
> >
> >    Just wondering if we came to a conclusion on this.  My general
> >    feeling is that SGP state sharing will be an implentation
> >    issue (I think we've tried to keep this outside of the scope
> >    of the UAs).
> >
> >    thanks,
> >    John
> >
> >    ---
> >    You are currently subscribed to sigtran as: [email protected]
> >    To unsubscribe send a blank email to
> >    [email protected]
> >
> >    ---
> >    You are currently subscribed to sigtran as:
> >    [email protected]
> >    To unsubscribe send a blank email to
> >    [email protected]
> >    ---
> >    You are currently subscribed to sigtran as: [email protected]
> >    To unsubscribe send a blank email to
> >    [email protected]
> >
> > References
> >
> >    1. mailto:[email protected]
> >    2. mailto:[email protected]
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>