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/