Subject: ASPAC Standby in M3UA

From: "Benjamin J. Wilson" <[email-masked]>
Date: Tue, 27 Mar 2001 14:57:04 -0500

> 
> Greg,
> 
> At the M3UA work group meeting there was some question about the
> procedures
> for "flip-flopping" ASPs.  More precisely, when an active ASP wants to
> go
> standby, what should happen?  Should the SG find an alternate standby
> ASP
> and make that one active?  Here are two proosed solutions.
> 
> Sorry for the shorthand (o = override mode) (ostby = override standby)
> Hope this text aligns properly for everyone.
> 
> Solution 1
> 
> SG                      ASP1                    ASP2
>  |                      |                       |
>  |<-----ASPUP-----------|                       |
>  |------ASPUP Ack------>|                       |
>  |<--------------------------ASPUP--------------|
>  |-----------------------ASPUP Ack------------->|
>  |                      |                       |
>  |<--ASPAC (o)----------|                       |
>  |---ASPAC Ack (o)----->|                       |
>  |<------------ASPAC (ostby)--------------------|
>  |-------------ASPAC Ack (ostby)--------------->|
>  |                      |                       |
>  |<--ASPAC (o-sby)------|                       |
>  |--ASPAC Ack (o-sby)-->|                       |
>  |------------ASPAC Ack (o)-------------------->|
> 
> If an ASP desires to go standby an ASPAC message is sent to the
> SG with traffic mode in the appropriate standby mode (override or
> loadshare).
> The SG determines if there is an alternate ASP in standby mode.  If an
> alternate ASP exists, the SG will send an ASPAC Ack (non-standby) to the
> previously
> standby ASP and reply with an ASPAC Ack (standby) to the requesting
> ASP.  All traffic will
> now be directed to the alternate ASP.
> 
> SG                      ASP1                    ASP2
>  |                      |                       |
>  |<-----ASPUP-----------|                       |
>  |------ASPUP Ack------>|                       |
>  |<--------------------------ASPUP--------------|
>  |-----------------------ASPUP Ack------------->|
>  |                      |                       |
>  |<--ASPAC (o)----------|                       |
>  |---ASPAC Ack (o)----->|                       |
>  |                      |                       |
>  |<--ASPAC (o-sby)------|                       |
>  |--ASPAC Ack (o)------>|                       |
>  |                      |                       |
> 
> If an ASP desires to go standby an ASPAC message is sent to the
> SG with traffic mode in the appropriate standby mode (override or
> loadshare).
> The SG determines if there is an alternate ASP in standby mode.  If no
> alternate ASP exists, the SG will reply with an ASPAC Ack to the
> requesting ASP which
> denies his request.
> 
>                 +++++++++ OR ++++++++++
> 
> Solution 2
> 
> SG                      ASP1                    ASP2
>  |                      |                       |
>  |<-----ASPUP-----------|                       |
>  |------ASPUP Ack------>|                       |
>  |<--------------------------ASPUP--------------|
>  |-----------------------ASPUP Ack------------->|
>  |                      |                       |
>  |<--ASPAC (o)----------|                       |
>  |---ASPAC Ack (o)----->|                       |
>  |<------------ASPAC (ostby)--------------------|
>  |-------------ASPAC Ack (ostby)--------------->|
>  |                      |                       |
>  |<--ASPIA (o)----------|                       |
>  |--ASPIA Ack (o)------>|                       |
>  |------------ASPAC Ack (o)-------------------->|
>  |                      |                       |
>  |<--ASPAC (ostby)------|                       |
>  |--ASPAC Ack (ostby)-->|                       |
> 
> This solution pretty much fits into the working model already defined
> (although not explicitly) in M3UA.  It might be worth adding this for
> clarity.
> It requires a bit more messaging at the ASP but is certainly requires
> less
> processing at the SG.  The problem with this solution is that ASP1 may
> have no clue ASP2 is acting standby, therefore it risks dropping
> traffic.
> 
> Cheers,
> 
> Ben

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Benjamin J. Wilson" <[email-masked]>
Date: Tue, 27 Mar 2001 15:37:16 -0500

Greg,

Just as an aside.  If Solution 1 is desirable/acceptable then the
following
text in 4.3.3.4...

"In the case of Over-ride (Standby) mode the traffic is not started to 
the ASP until the previously active ASP transitions to "Inactive or 
"Down" state.  At this point the ASP that sent the Over-Ride (Standby) 
ASPAC is moved to the Active state and the traffic is redirected.  A 
second ASP-Active Ack message with a new Traffic Mode Type ("Over-
ride", previously "Over-ride(Standby)") is sent to the ASP. A Notify 
(Alternate ASP-Active) message is not sent in this case."

...would need to state "..Inactive, Down, or Standby state."

Cheers,

Ben

---

---

From: Alex Audu <[email-masked]>
Date: Wed, 28 Mar 2001 09:25:19 -0600 (CST)

Benjmain,

A standby ASP should not send ASPAC message unless it is about to go ACTIVE.
So, messages like ASPAC (ostby) are pretty misleading. Section 5.2.2 of the
M3UA draft shows clearely the scenario of an ASP becoming ACTIVE in an 
OVERRIDE traffic mode.

Regards,
Alex.

5.2.2 (1+1 Sparing, Back-up Over-ride)

Following on from the example in Section 5.1.2, and ASP2 wishes to 
over-ride ASP1 and take over the traffic:

       SG                       ASP1                       ASP2 
        |                         |                          | 
        |<------------------------------ ASP Active----------| 
        |-------------------------------ASP-Active Ack------>|
        |----NTFY(Alt ASP-Act)--->| 
        |                         |                          | 

--- original message ---

> Date: Tue, 27 Mar 2001 14:57:04 -0500
> From: "Benjamin J. Wilson" <[email-masked]>
> Subject: ASPAC Standby in M3UA 
> > 
> > Greg,
> > 
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Benjamin J. Wilson" <[email-masked]>
Date: Wed, 28 Mar 2001 11:11:06 -0500

Alex,

I agree that 5.2.2 works but my scenarios answer the question "What
should an SG do
if an already active ASP sends an ASPAC(standby) message?"  5.2.2 does
not cover
this.  Suppose an ASP wants to go from active to active-standby...the
ASP doesn't want
to handle traffic anymore yet it doesn't want to go inactive and lose
all the call traffic.
Assume, it has no idea that ASP2 is out there.

Sorry for not being clearer.

Ben

---

---

From: Alex Audu <[email-masked]>
Date: Wed, 28 Mar 2001 11:08:53 -0600 (CST)

Benjamin,

I would assume a traffic carrying  ACTIVE ASP wishing to go INACTIVE or
Standby, would send an ASP INACTIVE request to the SG (see below). Traffic 
would still be carried by ASP1 untill it gets ASP INACTIVE ACK from SG.

SG then goes through the routines to bring an alternate ASP ACTIVE. While
waiting for the new ASP to be ACTIVE, incoming traffic would be buffered up.
When new ASP becomes ACTIVE, the buffered up traffic messages would be sent
through it.  This assumes the new ASP comes on line fast enough before the
PENDING STATE timer expires (after which buffered up messages are trashed)

What could be done is to have the SG ACK back to ASP1 only after getting
an ASP ACTIVE request from ASP2 (or after sending ASP_ACTIVE ACK to ASP2), but
the buffering mechanism in the AS_PENDING state is meant to guard against
messages being lost when an active ASP withdraws from service. Of course, if
there is no other ASP to assume the traffic, I don't think we can do anything
about that. 

Regards,
Alex.

5.2 ASP Traffic Fail-over Examples

5.2.1 (1+1 Sparing, withdrawal of ASP, Back-up Over-ride) 

Following on from the example in Section 5.1.2, and ASP1 withdraws from 
service:

       SG                       ASP1                       ASP2 
        |                         |                          |
        |<-----ASP Inactive-------|                          |
        |----ASP Inactive Ack---->|                          |
        |------------------------NTFY(AS-Pending)----------->| 
        |                         |                          | 
        |<------------------------------ ASP Active----------| 
        |------------------------------ASP-Active Ack)------>| 
        |                                                    |

--- original message ---

> Subject: Re: ASPAC Standby in M3UA

---

---

From: Ken Morneault <[email-masked]>
Date: Wed, 28 Mar 2001 14:15:35 -0500

Ben,

If I remember correctly, the editing session focused on how to handle the 
case of a Loadshare transition to Loadshare-Standby.  

I thought we agreed we didn't have to worry about Override-Standby
because in the Active-Standby case the ASP Active and ASP Inactive 
messages would be used.  Which means we should consider
removing "Override-Standby".  Otherwise, there are two ways to 
support Active-Standby redundancy.

Regards,

Ken

At 11:08 AM 3/28/01 -0600, Alex Audu wrote:
>You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Benjamin J. Wilson" <[email-masked]>
Date: Wed, 28 Mar 2001 16:30:36 -0500

Ken,

I agree the active/inactive messages "should" be used for the
appropriate
active-standby procedures.  I was just concerned about the error
case...and
then I determined that this could maybe be a feature.

Currently, here is my interpretation of what would happen at an SG...

 SG                      ASP1
  |                      |
  |<-----ASPUP-----------|
  |------ASPUP Ack------>|
  |                      |
  |<--ASPAC (o)----------|
  |---ASPAC Ack (o)----->|
  |			 |
  |<--ASPAC (o-sby)------|                
  |--ASPAC Ack (o)------>|

Now if I introduce an ASP2 currently in standby mode, should I treat the
ASPAC (osby) from
ASP1 as a request.  Basically, ASP1 would be saying "Hey SG, if you have
another ASP in standby
mode please use him, because I wish to not receive traffic any more but
I sure don't want to
risk making the AS inactive."

Cheers,

Ben

p.s.  I don't agree with getting rid of override standby, though

Ken Morneault wrote:
> You are currently subscribed to sigtran as: [email-masked]

---