Subject: [Megaco] Question on MG failure

From: "Hou, Hao" <[email-masked]>
Date: Thu, 11 Jul 2002 15:05:10 -0500

All,

In section 11.4 of the Megaco protocol spec, it decribes the scenario of a MG failure, 
while THE MG is still capable of sending a message to the MGC to indicate the failure.

It seems to me that we are missing the scenario that a MG is totally dead. In that case
the MGC won't get a indication of failure from the dead MG. 

How does the protocol handle this scenario?

Thanks,

Hao Hou
[email-masked]

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

---

From: [email-masked]
Date: Fri, 12 Jul 2002 19:16:57 +0530

Hi Hao

In case of complete failure of MG where it is unable to send messages, MGC
should have mechanism to identify the state of MG. As suggested in Inactivity
Timer Package, MGC will have polling mechanism and after expiry of this timer it
sends empty AUDIT command to MG. Having sent this transaction, the protocol
defined retransmission logic takes over, that is,  if the MGC does not receive
its response even after retransmitting that transaction  N times, it should
assume that the MG is down. After this MGC can start the recovery mechanism
where it clears all the calls at its end and expect the MG to send service
change on ROOT termination when it is back in service again.

Regards
Vivek Bansal
NGN Group

www.hssworld.com

"Hou, Hao" <[email-masked]> on 07/12/2002 01:35:10 AM

To:   [email-masked]
cc:    (bcc: Vivek Bansal/HSS)

Subject:  [Megaco] Question on MG failure

All,

In section 11.4 of the Megaco protocol spec, it decribes the scenario of a MG
failure,
while THE MG is still capable of sending a message to the MGC to indicate the
failure.

It seems to me that we are missing the scenario that a MG is totally dead. In
that case
the MGC won't get a indication of failure from the dead MG.

Thanks,

Hao Hou
[email-masked]

---

From: [email-masked]
Date: Fri, 12 Jul 2002 19:16:57 +0530

Hi Hao

Regards
Vivek Bansal
NGN Group

www.hssworld.com

To:   [email-masked]

All,

Thanks,

Hao Hou
[email-masked]

---

From: "Hou, Hao" <[email-masked]>
Date: Fri, 12 Jul 2002 10:18:49 -0500

Vivek,

Thanks for your answer. It covers the scenario very well where there is only one 
MG, and the MG doesn't have a redundant MG to protect it.

But there are still to scenarios in the case that the failed MG has an redundant MG protecting it,
1.  The rendundant MG detect the failure of its pair before the MGC does. 
      In this case,  should the redundant MG initiate a failover? How ?
      
2.  The MGC detect the MG failure first.
      In this case, shoud the MGC initiate a failover to the redundancy MG? How?

These two scenarios are not clearly addressed in the Megaco spec.

There is another issue regarding the second paragraph of section 11.2
It says,  " Allowing the MGC to send duplicate message to both MGs accomodates pairs of
MGs that are capable of redundant failover of one of the MGs. Only the working MG shall 
accept or reject transacctions."
It also says, " Upon failover, the primary MG sends a ServiceChange command with a 
Failover method and the MG Impending Failure reason. The MGC then use the secondary 
MG as the acitve MG".

The above text addresses the scenario of primary MG failure, while still be able to talk with
MGC. But It is not clear to me how does the MGC then use the secondary MG as the active.

If it just simply directs the new transaction requests to the secondary MG, the MG may still
think itself as Non-active, and thus ignore all the requests.
It seems to me either the MGC should send a kind of ServiceChange command to the 
secondary MG to indicate the change of role, or the secondary MG get the role change 
information directly from the primary MG.

Which one does the Megaco spec imply?

Thanks,

Hao Hou
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 12, 2002 8:47 AM
To: Hou, Hao
Cc: [email-masked]
Subject: Re: [Megaco] Question on MG failure

Hi Hao

Regards
Vivek Bansal
NGN Group

www.hssworld.com

To:   [email-masked]

All,

Thanks,

Hao Hou
[email-masked]

---

From: "Hou, Hao" <[email-masked]>
Date: Fri, 12 Jul 2002 10:18:49 -0500

Vivek,

      

Thanks,

Hao Hou
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 12, 2002 8:47 AM
To: Hou, Hao
Cc: [email-masked]
Subject: Re: [Megaco] Question on MG failure

Hi Hao

Regards
Vivek Bansal
NGN Group

www.hssworld.com

To:   [email-masked]

All,

Thanks,

Hao Hou
[email-masked]

---

From: Carl Rutter <[email-masked]>
Date: Fri, 12 Jul 2002 13:46:45 -0400

1) If its redundant ideally the redundant MG will keep the same IP address
   transparent to the MGC.  Also it may send up a SVC with method FailOver
   as an indication to the MGC that a FailOver happened and it may want to
Audit
   the box etc.   If it has a different IP address I believe you'd hav to
send
   the SVC FailOver.
2) If its a "hotswap" redundant the MG really should pick up the failure way
before the MGC does.  If it doesn't and its a different IP address then you
could
do a handoff.

CArl

-----Original Message-----
From: Hou, Hao [mailto:[email-masked]]
Sent: Friday, July 12, 2002 11:19 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Megaco] Question on MG failure

Vivek,

Thanks for your answer. It covers the scenario very well where there is only
one 
MG, and the MG doesn't have a redundant MG to protect it.

But there are still to scenarios in the case that the failed MG has an
redundant MG protecting it,
1.  The rendundant MG detect the failure of its pair before the MGC does. 
      In this case,  should the redundant MG initiate a failover? How ?
      
2.  The MGC detect the MG failure first.
      In this case, shoud the MGC initiate a failover to the redundancy MG?
How?

There is another issue regarding the second paragraph of section 11.2
It says,  " Allowing the MGC to send duplicate message to both MGs
accomodates pairs of
MGs that are capable of redundant failover of one of the MGs. Only the
working MG shall 
accept or reject transacctions."
It also says, " Upon failover, the primary MG sends a ServiceChange command
with a 
Failover method and the MG Impending Failure reason. The MGC then use the
secondary 
MG as the acitve MG".

The above text addresses the scenario of primary MG failure, while still be
able to talk with
MGC. But It is not clear to me how does the MGC then use the secondary MG as
the active.

If it just simply directs the new transaction requests to the secondary MG,
the MG may still
think itself as Non-active, and thus ignore all the requests.
It seems to me either the MGC should send a kind of ServiceChange command to
the 
secondary MG to indicate the change of role, or the secondary MG get the
role change 
information directly from the primary MG.

Thanks,

Hao Hou
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 12, 2002 8:47 AM
To: Hou, Hao
Cc: [email-masked]
Subject: Re: [Megaco] Question on MG failure

Hi Hao

In case of complete failure of MG where it is unable to send messages, MGC
should have mechanism to identify the state of MG. As suggested in
Inactivity
Timer Package, MGC will have polling mechanism and after expiry of this
timer it
sends empty AUDIT command to MG. Having sent this transaction, the protocol
defined retransmission logic takes over, that is,  if the MGC does not
receive
its response even after retransmitting that transaction  N times, it should
assume that the MG is down. After this MGC can start the recovery mechanism
where it clears all the calls at its end and expect the MG to send service
change on ROOT termination when it is back in service again.

Regards
Vivek Bansal
NGN Group

www.hssworld.com

To:   [email-masked]

All,

In section 11.4 of the Megaco protocol spec, it decribes the scenario of a
MG
failure,
while THE MG is still capable of sending a message to the MGC to indicate
the
failure.

It seems to me that we are missing the scenario that a MG is totally dead.
In
that case
the MGC won't get a indication of failure from the dead MG.

Thanks,

Hao Hou
[email-masked]

---

From: Carl Rutter <[email-masked]>
Date: Fri, 12 Jul 2002 13:46:45 -0400

CArl

-----Original Message-----
From: Hou, Hao [mailto:[email-masked]]
Sent: Friday, July 12, 2002 11:19 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Megaco] Question on MG failure

Vivek,

      

Thanks,

Hao Hou
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 12, 2002 8:47 AM
To: Hou, Hao
Cc: [email-masked]
Subject: Re: [Megaco] Question on MG failure

Hi Hao

Regards
Vivek Bansal
NGN Group

www.hssworld.com

To:   [email-masked]

All,

Thanks,

Hao Hou
[email-masked]

---

From: [email-masked]
Date: Sat, 13 Jul 2002 00:32:05 +0530

Hi Hao

Please look for comments embedded in the text below.

Regards
Vivek Bansal
NGN Group

www.hssworld.com

"Hou, Hao" <[email-masked]> on 07/12/2002 08:48:49 PM

To:   Vivek Bansal/HSS@HSS
cc:   [email-masked]

Vivek,

But there are still to scenarios in the case that the failed MG has an redundant
MG protecting it,
1.  The rendundant MG detect the failure of its pair before the MGC does.
      In this case,  should the redundant MG initiate a failover? How ?

[Vivek] When the redundant MG takes over, it will send service change with
DISCONNECTED method to MGC. The level of redundancy would be governed by the
service change reason. This would assist the MGC in taking decision about the
state of the calls at MG.

[Vivek] The MGC may not configured with the information of the redundant MG. So
to keep the behavior consistent, MG should always initiate the failover
procedure. Moreover this would be restricted by the transports like TCP which
forces master/slave architecture.

There is another issue regarding the second paragraph of section 11.2
It says,  " Allowing the MGC to send duplicate message to both MGs accomodates
pairs of
MGs that are capable of redundant failover of one of the MGs. Only the working
MG shall
accept or reject transacctions."

[Vivek] The above behavior mentioned in the protocol in one of the possible
implimentations of redundancy at MG. The protocol does not mandate that the MGC
should always send messages to both active and standby MGs.

It also says, " Upon failover, the primary MG sends a ServiceChange command with
a
Failover method and the MG Impending Failure reason. The MGC then use the
secondary
MG as the acitve MG".

The above text addresses the scenario of primary MG failure, while still be able
to talk with
MGC. But It is not clear to me how does the MGC then use the secondary MG as the
active.

[Vivek] In case of failover, active MG which is going down will send service
change message with FAILOVER method and the secondary MG when it comes up will
send service change with DISCONNECTED method. This acts a trigger for MGC to
assume that the secondary MG is the active MG.

If it just simply directs the new transaction requests to the secondary MG, the
MG may still
think itself as Non-active, and thus ignore all the requests.
It seems to me either the MGC should send a kind of ServiceChange command to the
secondary MG to indicate the change of role, or the secondary MG get the role
change
information directly from the primary MG.

[Vivek] MGC should wait for the service change from the secondary MG before it
decides to direct messages to the secondary MG. This will resolve the problem
that you are mentioning.

Thanks,

Hao Hou
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 12, 2002 8:47 AM
To: Hou, Hao
Cc: [email-masked]
Subject: Re: [Megaco] Question on MG failure

Hi Hao

Regards
Vivek Bansal
NGN Group

www.hssworld.com

To:   [email-masked]

All,

Thanks,

Hao Hou
[email-masked]

---

From: [email-masked]
Date: Sat, 13 Jul 2002 00:32:05 +0530

Hi Hao

Regards
Vivek Bansal
NGN Group

www.hssworld.com

To:   Vivek Bansal/HSS@HSS
cc:   [email-masked]

Vivek,

Thanks,

Hao Hou
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 12, 2002 8:47 AM
To: Hou, Hao
Cc: [email-masked]
Subject: Re: [Megaco] Question on MG failure

Hi Hao

Regards
Vivek Bansal
NGN Group

www.hssworld.com

To:   [email-masked]

All,

Thanks,

Hao Hou
[email-masked]

---

From: "Hou, Hao" <[email-masked]>
Date: Fri, 12 Jul 2002 16:07:07 -0500

Vivek,

Please see my comments following your comments start with [HH],

Thanks,

Hao

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 12, 2002 2:02 PM
To: Hou, Hao
Cc: [email-masked]
Subject: RE: [Megaco] Question on MG failure

Hi Hao

Regards
Vivek Bansal
NGN Group

www.hssworld.com

To:   Vivek Bansal/HSS@HSS
cc:   [email-masked]

Vivek,

[HH] If the IP address of the primary and the secondary MG are of the same
It seems to me using "Disconnected" is a good choice although it has some 
conflicts with the Megaco spec. (section 7.2.8, where "Disconnected" is defined).
In Carl's reply to my email, (right before your reply), he suggest to use the "failover"
But since the IP addresses are of the same, the two MGs looks like one logic
MG to MGC, and the , using "Diconnected" seems more natural.
If the IP address of the primary and the secondary MG different, it seems to me
using "Failover" is a good choice. But I have a question on which reason should
be used, or what are parameters should be included in the ServiceChange command
so that the MGC knows the secondary MG is trying to take over the primary MG,
instead of the secondary MG failed itself.

[Vivek] The MGC may not configured with the information of the redundant MG. So
to keep the behavior consistent, MG should always initiate the failover
procedure. Moreover this would be restricted by the transports like TCP which
forces master/slave architecture.
[HH] I think the MGC should be configured with the redundant MG, if the IP address are
different for security reason. Otherwise any Box can pretend as if it is a redundant MG
for a MG. 

It also says, " Upon failover, the primary MG sends a ServiceChange command with
aFailover method and the MG Impending Failure reason. The MGC then use the
secondary MG as the acitve MG".

The above text addresses the scenario of primary MG failure, while still be able
to talk with MGC. But It is not clear to me how does the MGC then use the secondary
MG as theactive.

[Vivek] In case of failover, active MG which is going down will send service
change message with FAILOVER method and the secondary MG when it comes up will
send service change with DISCONNECTED method. This acts a trigger for MGC to
assume that the secondary MG is the active MG.
[HH] How does the secondary MG know that the primary MG failover? Are you assuming
the primary MG will inform the secondary MG of the failover right before or right after
it send ServiceChange to MGC? 

Thanks,

Hao Hou
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 12, 2002 8:47 AM
To: Hou, Hao
Cc: [email-masked]
Subject: Re: [Megaco] Question on MG failure

Hi Hao

Regards
Vivek Bansal
NGN Group

www.hssworld.com

To:   [email-masked]

All,

Thanks,

Hao Hou
[email-masked]

---

From: "Hou, Hao" <[email-masked]>
Date: Fri, 12 Jul 2002 16:07:07 -0500

Vivek,

Thanks,

Hao

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 12, 2002 2:02 PM
To: Hou, Hao
Cc: [email-masked]
Subject: RE: [Megaco] Question on MG failure

Hi Hao

Regards
Vivek Bansal
NGN Group

www.hssworld.com

To:   Vivek Bansal/HSS@HSS
cc:   [email-masked]

Vivek,

Thanks,

Hao Hou
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 12, 2002 8:47 AM
To: Hou, Hao
Cc: [email-masked]
Subject: Re: [Megaco] Question on MG failure

Hi Hao

Regards
Vivek Bansal
NGN Group

www.hssworld.com

To:   [email-masked]

All,

Thanks,

Hao Hou
[email-masked]

---

From: "Hou, Hao" <[email-masked]>
Date: Fri, 12 Jul 2002 15:37:45 -0500

Carl,

Thanks for the reply,
Please see my further questions embedded in your reply started with [HH]

Hao 

-----Original Message-----
From: Carl Rutter [mailto:[email-masked]]
Sent: Friday, July 12, 2002 12:47 PM
To: Hou, Hao; [email-masked]
Cc: [email-masked]
Subject: RE: [Megaco] Question on MG failure

   Audit   the box etc.  

[HH] If the two MG are redundant pairs and have same IP address, 
   then to the MGC there is only logically one MG, the switchover of MG 
   should be transparent to MGC. So I would think to use ServiceChange 
   with method "Disconnected" with reason   " Service Restore ????? " 
   ( What is the proper reason code? I'm afraid we can't use MG 
   Inpending failure")   In this way, it looks to  the MGC as if there is only a 
  temperary communication failure.  (Please refer to Vivek's email after yours,
  who also suggest to use Disconnect for this case.)

 If it has a different IP address I believe you'd hav to send   the SVC FailOver.
[HH] In this case, what is the reason code?  How does the MGC knows that 
   the Secondary MG is trying to take over the primary MG, insteady of the 
   failure of Secondary MG itself?

2) If its a "hotswap" redundant the MG really should pick up the failure way
before the MGC does.  If it doesn't and its a different IP address then you
could do a handoff.
[HH] But in the Megaco spec, it is said that the "handoff" is used for changing
  MGC, not for MG. (section 7.2.8)

CArl

-----Original Message-----
From: Hou, Hao [mailto:[email-masked]]
Sent: Friday, July 12, 2002 11:19 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Megaco] Question on MG failure

Vivek,

      

Thanks,

Hao Hou
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 12, 2002 8:47 AM
To: Hou, Hao
Cc: [email-masked]
Subject: Re: [Megaco] Question on MG failure

Hi Hao

Regards
Vivek Bansal
NGN Group

www.hssworld.com

To:   [email-masked]

All,

Thanks,

Hao Hou
[email-masked]

---

From: "Hou, Hao" <[email-masked]>
Date: Fri, 12 Jul 2002 15:37:45 -0500

Carl,

Thanks for the reply,

Hao 

-----Original Message-----
From: Carl Rutter [mailto:[email-masked]]
Sent: Friday, July 12, 2002 12:47 PM
To: Hou, Hao; [email-masked]
Cc: [email-masked]
Subject: RE: [Megaco] Question on MG failure

CArl

-----Original Message-----
From: Hou, Hao [mailto:[email-masked]]
Sent: Friday, July 12, 2002 11:19 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Megaco] Question on MG failure

Vivek,

      

Thanks,

Hao Hou
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 12, 2002 8:47 AM
To: Hou, Hao
Cc: [email-masked]
Subject: Re: [Megaco] Question on MG failure

Hi Hao

Regards
Vivek Bansal
NGN Group

www.hssworld.com

To:   [email-masked]

All,

Thanks,

Hao Hou
[email-masked]

---

From: Carl Rutter <[email-masked]>
Date: Mon, 15 Jul 2002 09:58:09 -0400

#1 - My bad - If its redundant, Disconnected is right & should trigger
     the Audit from the MGC.
There was/is a failover scenarios doc.  I couldn't find my copy off-hand
Maybe someone can give a pointer?

Carl

-----Original Message-----
From: Hou, Hao [mailto:[email-masked]]
Sent: Friday, July 12, 2002 4:38 PM
To: Carl Rutter; [email-masked]
Cc: [email-masked]
Subject: RE: [Megaco] Question on MG failure

Carl,

Thanks for the reply,

Hao 

-----Original Message-----
From: Carl Rutter [mailto:[email-masked]]
Sent: Friday, July 12, 2002 12:47 PM
To: Hou, Hao; [email-masked]
Cc: [email-masked]
Subject: RE: [Megaco] Question on MG failure

[HH] If the two MG are redundant pairs and have same IP address, 
   then to the MGC there is only logically one MG, the switchover of MG 
   should be transparent to MGC. So I would think to use ServiceChange 
   with method "Disconnected" with reason   " Service Restore ????? " 
   ( What is the proper reason code? I'm afraid we can't use MG 
   Inpending failure")   In this way, it looks to  the MGC as if there is
only a 
  temperary communication failure.  (Please refer to Vivek's email after
yours,
  who also suggest to use Disconnect for this case.)

 If it has a different IP address I believe you'd hav to send   the SVC
FailOver.
[HH] In this case, what is the reason code?  How does the MGC knows that 
   the Secondary MG is trying to take over the primary MG, insteady of the 
   failure of Secondary MG itself?

2) If its a "hotswap" redundant the MG really should pick up the failure way
before the MGC does.  If it doesn't and its a different IP address then you
could do a handoff.
[HH] But in the Megaco spec, it is said that the "handoff" is used for
changing
  MGC, not for MG. (section 7.2.8)

CArl

-----Original Message-----
From: Hou, Hao [mailto:[email-masked]]
Sent: Friday, July 12, 2002 11:19 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Megaco] Question on MG failure

Vivek,

      

Thanks,

Hao Hou
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 12, 2002 8:47 AM
To: Hou, Hao
Cc: [email-masked]
Subject: Re: [Megaco] Question on MG failure

Hi Hao

Regards
Vivek Bansal
NGN Group

www.hssworld.com

To:   [email-masked]

All,

Thanks,

Hao Hou
[email-masked]

---

From: Carl Rutter <[email-masked]>
Date: Mon, 15 Jul 2002 09:58:09 -0400

Carl

-----Original Message-----
From: Hou, Hao [mailto:[email-masked]]
Sent: Friday, July 12, 2002 4:38 PM
To: Carl Rutter; [email-masked]
Cc: [email-masked]
Subject: RE: [Megaco] Question on MG failure

Carl,

Thanks for the reply,

Hao 

-----Original Message-----
From: Carl Rutter [mailto:[email-masked]]
Sent: Friday, July 12, 2002 12:47 PM
To: Hou, Hao; [email-masked]
Cc: [email-masked]
Subject: RE: [Megaco] Question on MG failure

CArl

-----Original Message-----
From: Hou, Hao [mailto:[email-masked]]
Sent: Friday, July 12, 2002 11:19 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Megaco] Question on MG failure

Vivek,

      

Thanks,

Hao Hou
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 12, 2002 8:47 AM
To: Hou, Hao
Cc: [email-masked]
Subject: Re: [Megaco] Question on MG failure

Hi Hao

Regards
Vivek Bansal
NGN Group

www.hssworld.com

To:   [email-masked]

All,

Thanks,

Hao Hou
[email-masked]