Subject: [Sigtran] Re: [M3UA] AS state machine sharing between SGPs

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Feb 2006 14:52:25 -0700

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-masked]]
>    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-masked] [[2]mailto:[email-masked]]
>    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-masked]
>    To unsubscribe send a blank email to
>    [email-masked]
> 
>    ---
>    You are currently subscribed to sigtran as:
>    [email-masked]
>    To unsubscribe send a blank email to
>    [email-masked]
>    ---
>    You are currently subscribed to sigtran as: [email-masked]
>    To unsubscribe send a blank email to
>    [email-masked]
> 
> References
> 
>    1. mailto:[email-masked]
>    2. mailto:[email-masked]

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 22 Feb 2006 16:58:56 -0500

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

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, February 22, 2006 4:52 PM
> To: Tolga Aversen
> Cc: [email-masked]
> Subject: [Sigtran] Re: [M3UA] AS state machine sharing between SGPs
>
>
> Tolga,
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Feb 2006 15:30:22 -0700

Tolga,

Read the rest of the threads, or at least the note I quoted from Greg
that I sent a moment ago.

Tolga Asveren wrote:                                                 (Wed, 22 Feb 2006 16:58:56)
> state shouldn't be used for ASPSM/ASPTM procedures.

Read the other clip I sent from Greg.  We agreed that Notify reflects the
overall AS status.

> I assume 4) is mainly concerning NTFYs(?)

Acutally, it refers to you note at the bottom: that as long as there is a
concept of an SGP, that AS state needs to be shared between them.

> 1)Is advertising global AS state with NTFY, what we really want?

It is what we agreed.

> It seems like my argument of 5 years ago was not non-sense. OTOH, one could also

I don't think so.  Look at the other note that I sent from Greg to understand
why the text says what it says today.  The AS state is mantained at the SGP.
This is because it is not always necessary to aggregate AS state (when there is
only one SGP, or when only one SGP in the SG serves each AS).  But the AS state
SHOULD be coordinated over the SGP in an SG per 1.4.1.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/