Subject: RE: [Sigtran] Re: M3UA Notify message

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 25 Feb 2003 14:03:32 +0100

Hi Samuel et al., 

Take into account that if you define two ASes:
- AS1 DPC+SLS1  with two ASPs (ASP1 and ASP2) and redundancy: n=1 k=1
- AS2 DPC+SLS2  with two ASPs (ASP1 and ASP2) and redundancy: n=1 k=1

And 
- ASP1 active for AS1 and backup for AS2
- ASP2 active for AS2 and backup for AS1

You get the desired behaviour. This case can be solved with a right network configuration without changing the current "required" qualification for "n".

Apart from this, 

I would say that a compromise option would consist of considering "n" as the normal working case, but make it implementation dependent (maybe configurable) whether an implementation may have more than "n" ASPs working at the same time for an AS, and whether the SG keeps working when the number of ASP is under "n". We could make a recommendation with "MAY" allowing both options.

But now, the problem comes with the AS state machine. If we agree upon here, we could say the AS is ACTIVE in the range n_min to n_max, where these two values are configurable.

Could this be considered as a compromise solution about n+k behaviour?

Cheers // Javier.

> -----Original Message-----
> From: Samuel Dur D. Jeyaseelan [mailto:[email-masked]]
> Sent: martes, 25 de febrero de 2003 10:56
> To: Brian F. G. Bidulock
> Cc: TOLGA ASVEREN; [email-masked]
> Subject: Re: [Sigtran] Re: M3UA Notify message
> 
> 
> 
> Brian,
> 
>   Alcatel USA, Inc.                  Internet: 
> <userid>@ssd.usa.alcatel.com
>   1000 Coit Road, Plano, Texas 75075
>   ******* The opinions expressed are not those of Alcatel 
> USA, Inc. *******
> 
> On Tue, 25 Feb 2003, Brian F. G. Bidulock wrote:
> 
> > TOLGA,
> > 
> > TOLGA ASVEREN wrote:                                        
>                          (Tue, 25 Feb 2003 08:39:11)
> > > 
> > > Not necessarily because I disagree with some change, but 
> just to clarify
> > > where the changes might take us:
> > 
> > If we cannot agree, we let the RFC stand.
> > 
> > > NTFY was used till now only as an advisory message, this 
> will be changed.
> > 
> > No it will not.  An ASP is not forbidden from acting on any 
> Notify message.
> > All Notify messages are still advisory.  The ASP can take 
> into consideration
> > Notify messages, information that it has about other ASPs, 
> the time of day,
> > direction of the wind, etc.
> > 
> > > Starting/stopping(till now we focused more on starting 
> but why not stopping
> > > also? So SG can decide based on load/other dynamic 
> conditions when to stop
> > > traffic to/from AS) traffic will be controlled by SGP with NTFY.
> > 
> > The SG has always been permitted to start or stop traffic 
> when it considers
> > it necessary and has always been permitted to perform its 
> necessary functions
> > with the SS7 network.  The SGP can send ASPIA Ack or drop 
> associations any
> > time it wishes to stop traffic.
> 
> Please let me know what are we achieving by stopping the 
> traffic in the
> following case(n+k - reduntancy)
> 
> When 'n' ASPs are active
> ------------------------
> SLS-X  ---->ASP1
> SLS-Y  ---->ASP2
> 
> When ASP1 goes down
> -------------------
> SLS-(Y,X)  ----->ASP2
> 
> Here 3 cases can be dealt
> 
> case 1) If SG receives  message with SLS Y - this traffic can be
>         successfully (100%) handled by ASP2 according to the 
> configured
>         databse.
>  
> case 2) If SG receives messages with SLS X and Y - this traffic can be
>         successfully (100%) handled by ASP2, provided 
> congestion has not
>         occured(according to q.704 section 3.8.2)
> 
> case 3) Don't allow SG to process the traffic when n<2 ?????????.
>         SG disallows traffic when n=0.
> 
> IMO, SG has capability to reroute the traffic to ASP1 and there is no
> meaning if SG stops traffic when n < 2.
> 
> This is just like a MTP3 link failure concept when link1 goes down ,
> traffic carried by link1 will be rerouted to available link. 
> All we need to do at SG is just change the SLS-ASP dynamic 
> table to carry
> SLS X.
> 
> 
> --Samuel
> > 
> > > IMO, this requires still a change to the original AS 
> state machine for
> > > transitions from INACTIVE to ACTIVE and possibly from 
> ACTIVE to PENDING.
> > 
> > It does not.  The SG is only withholding a Notify message 
> as proscribed
> > by the RFC.
> > 
> > > In general all this will change the meaning of 
> ASPAC/ASPAC-ACK exchange, it
> > > will mean that ASP is ready to be triggered to 
> send/receive traffic for a
> > > specific AS (something to be determined just by ASP, when 
> the triggering
> > > will happen will be decided by SGP)rather than ASP can start to
> > > send/receive traffic for a specific AS(something to be 
> determined by both
> > > ASP and SGP). I believe this migth require some other 
> changes throughout
> > > the document. For example instead of unsolicited 
> ASPIA-ACK, I would think
> > > SGP should send NTFY(INACTIVE). My opinion is, if we are changing
> > > something, let's do it clean and correct.
> > 
> > No nothing changes here because withholding NTFY(ACTIVE) is 
> already part
> > of the RFC.  Nothing in the RFC changes.
> > 
> > > 
> > > IMO, overall this is more than just a clarification, 
> let's decide carefully
> > > to prevent rollbacks (as much as possible).
> > 
> > Not even clarification is required.  The RFC details the 
> necessary actions.
> > 
> > The only thing that needs to be done is strike section 3.15 
> from the IG
> > because it conflicts with the RFC (which is fine as it is).
> > 
> > --brian
> > 
> > -- 
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> > 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 25 Feb 2003 06:57:28 -0700

Javier,

The state machine is fine as it appears in the RFC.  AS are not considered
PENDING or INACTIVE until all ASPs are down or inactive for the AS.

Anything else is merely an expansion of the ACTIVE state, which the
implementer is already welcome to expand in any manner they like.

No change is needed to the state machine or text of the RFC.

--brian

Javier Pastor-Balbas (ECE) wrote:                                                   (Tue, 25 Feb 2003 14:03:32)

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Tue, 25 Feb 2003 08:11:31 -0600 (CST)

Javier,

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

On Tue, 25 Feb 2003, Javier Pastor-Balbas (ECE) wrote:

> You get the desired behaviour. This case can be solved with a right 
  network configuration without changing the current "required"
  qualification for "n".
> 
> 
> 
> Apart from this, 
> 
> I would say that a compromise option would consist of considering "n" as 
  the normal working case, but make it implementation dependent (maybe
configurable) whether an implementation may have more than "n" ASPs 
 working at the same time for an AS, and whether the SG keeps working when
the number of ASP is under "n". We could make a recommendation with "MAY" 
allowing both options.
[Samuel] Yes .SG keeps working when n=1 or n >=2.
but current RFC says that SG NOTIFIES 'k' ASP to become active only
when n<2 and it does not say what will happen when SG requires more than
'n' ASP to handle the traffic 't+1'.
 
> But now, the problem comes with the AS state machine. If we agree upon here,
 we could say the AS is ACTIVE in the range n_min to n_max, where these two
 values are configurable.
[Samuel] To handle the 'normal(best) traffic T' SG requires 'n=2' ASPs.
In the course of traffic if 'n became 1'(means ASP1 failed), here SG can
handle the traffic with 'n=1' ASP. 
So only intially SG requires 'n=2' ASPs to make the AS state as ACTIVE
and 'n=2' is fed during configuration.But while handling traffic due to 
failure of ASP1 'n' becomes '1', here still AS is ACTIVE with single ASP.

--Samuel

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 25 Feb 2003 12:30:56 -0800 (PST)

Javier,

> Apart from this, 
> 
> I would say that a compromise option would consist
> of considering "n" as the normal working case, but
> make it implementation dependent (maybe
> configurable) whether an implementation may have
> more than "n" ASPs working at the same time for an
> AS, and whether the SG keeps working when the number
> of ASP is under "n". We could make a recommendation
> with "MAY" allowing both options.
> 
> But now, the problem comes with the AS state
> machine. If we agree upon here, we could say the AS
> is ACTIVE in the range n_min to n_max, where these
> two values are configurable.
> 
> 
[TOLGA]My opinion after the discussions in this thread
is, let the SG decide when to start/stop traffic
between ASP/SGP. So, SG can decide how it will
interprete n and there is no need to expose the
concept of n to ASPs, they can act based on NTFYs sent
by SGP. I would think this should be suitable for
various configurations. But before proposing text
let's see, whether the WG is happy with this solution.

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Wed, 26 Feb 2003 00:04:35 -0600 (CST)

Javier,

               SG                        +------+  AS1
 normal SS7  +-----+             +-------|      |
-----------> |     |------------/--------| ASP1 |      
 traffic(T)  |     |           /         +------+        'n' ASPs
             | SGP1|          /          +------+
             |     |---------/-----------| ASP2 |
             +-----+        /     +------|      |
               *           /     /       +------+
               *          /     /        +------+  
               **************************| ASP3 |  spare 'k' ASP
                        /     /          +------+
                       /     /              *
             +---- +  /     /               *
             |     |-+     /                *
             |     |      /                 *
             |SGP2 |-----+                  *
             |     |                        *
             +-----+                        *
               *                            *
               *                            *
               ******************************

At SGP1 SLS-ASP table
--------------------
SLS             ASP
---             ---
X               ASP1
Y               ASP2
-               ASP3 (spare ASP)

AT AS1 SLS-ASP table
-------------------
SLS             ASP        PRIMARY-RT         SECND-RT
---             ---        ----------         --------
A               ASP1        SGP1               SGP2
B               ASP2        SGP1               SGP2

Initially AS1 state at SGP is AS-DOWN.

SGP requires 'n' ASPs to handle the normal SS7 Traffic 'T', this can be
called as 'best traffic'.AS1 state is changed to AS-ACTIVE when 'n' ASPs
have become active.

Suppose ASP1 is failed so 'n' becomes '1'.

Now the question.

1) If AS1 state is changed from ACTIVE to PENDING(as per IG)
   then no DATA messages will be sent to AS.
   
   IMO, we should keep the AS state as ACTIVE.
   
   According to q.704 section 3.8.2 we should reroute the 
   traffic to ASP2 provided congestion has not occured.

   Just reroute the SLS(X,Y) to available ASP1 , i beleive this is
   what we follow in legacy SS7 network.
   
   When ASP2 transmission buffer reaches congestion level then
   we can send NTFY to spare 'k' ASP and change the AS1 state to
   PENDING along with timer running.
   
 2)What will happen when the traffic reaches from 'T' to 'T+1'?
 
   At SG 'n' ASPs are not sufficient to handle this 'worst case'.
   So SG is required to send NTFY to spare 'k' ASP.
   But RFC and IG ignores to handle this case.We should enhance IG to
   support this case.
   
 IG section 3.15 misguides and should be re-writen to handle the above two 
 points.
 
--Samuel