Subject: RE: Reset of an MGC

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 10 Apr 2001 11:04:18 -0400

I'll try to give some answers.  A general point: the philosophy to date is
to leave the MG in control of creating and maintaining the association.

> -----Original Message-----
> From: Ian Leighton [mailto:[email-masked]]
> Sent: Tuesday, April 03, 2001 9:22 PM
> To: [email-masked]
> Subject: Reset of an MGC
> 
> 
> Hi List
> 
> I have some questions pertaining to MG's
> behavior after a MGC reset.
> 
> Ques 1 - From Sect 11.5 of rfc 3015 
> 
>    If the MG detects a failure of its controlling
>    MGC, ...
> 
> how does the MG determine that the MGC has reset.
> If the MG doesn't need to send any transactions
> to the MGC how will it know that its MGC has reset?
> Won't a reset of the MGC cause MG's to potentially
> remain un-registered forever?

[PTT] Currently the method by which the MG determines that there has been a
reset is unspecified, but a package has been proposed which uses a signal on
ROOT to constitute a heartbeat.  Given, as you say, that most requests come
from the MGC to the MG, there might be a need to standardize an association
maintenance method which allows the MGC to keep from being overwhelmed by
the volume of heartbeat messages from the MGs under its control.
> 
> Ques 2) - From sect 11.5 of rfc 3015 
> 
>    ... it attempts to
> contact the next MGC on its
>    pre-provisioned list. It starts its
>    attempts at the beginning (Primary MGC), unless
>    that was the MGC that failed, in which case it
>    starts at its first Secondary MGC.  It sends
>    a ServiceChange message with a "Failover" method
>    and a " MGC Impending Failure" reason.
> 
> what does an MG do once it has exhausted its list 
> of MGC's to try? I assume that it waits a random
> amount of time as described in 9.2 and starts over.
> Should this be added to the IG?

[PTT] This is covered in section 11 (various places).

> 
> Ques 3) From sect 7.2.8 
> 
>    A ServiceChange Command specifying the "Root" for
>    the TerminationID and ServiceChangeMethod equal 
>    to Restart is a registration command by
> which a
>    Media Gateway announces its existence to the Media
>    Gateway Controller.
> 
> Is it a worth while item to mention in the
> IG that MGC should accept Failover ServiceChanges
> after power up as a registration? 

[PTT] Technically, "Failover" signals a renewal of a previous registration.
The backup MG is saying that it will pick up where the primary MG left off.
See section 11.4.  If an MG is starting from scratch, it should use
"Restart".
> 
> Ques 4) - Why is the method "MGC Impending Failure"?
> Hasn't the MGC already failed?

[PTT]  The associated procedure is shown in section 11.5.  Unfortunately,
the recommended reason in 11.5 is "MGC directed change", so it's not clear
when "MGC Impending Failure" would ever be used.
> 
> Ques 5) - Why does section 7.2.8 specifically refer to
> MG failover
> 
>    6) Failover - sent from MG to MGC to indicate the
>    primary MG is out of service and a secondary MG is
>    taking over.
> 
> but not refer to MGC failure? Is this another item
> that could be added to the IG.

[PTT] See 11.5.
> 
> Any comments would be appreciated.
> 
> Regards
> Ian Leighton
>

---

From: Chuong Nguyen <[email-masked]>
Date: Tue, 10 Apr 2001 10:45:09 -0500

Tom-PT Taylor wrote:

>
>
> I'll try to give some answers.  A general point: the philosophy to
> date is to leave the MG in control of creating and maintaining the
> association.
>
> >
> [PTT] Currently the method by which the MG determines that there has
> been a reset is unspecified, but a package has been proposed which
> uses a signal on ROOT to constitute a heartbeat.  Given, as you say,
> that most requests come from the MGC to the MG, there might be a need
> to standardize an association maintenance method which allows the MGC
> to keep from being overwhelmed by the volume of heartbeat messages
> from the MGs under its control.
>

<cnn>  In lieu of the package, Brian has indicated previously that a
Restart on a termination
               be used for a heartbeat.
               The issue about overwhelming the MGC w/heartbeat can be
limited by the MG
                to issue heartbeat only if it did not receive any
message from its MGC for a
                certain period of time.
                Can it be modeled after TCP heartbeat mechanism?
               MG will have to have some robustness here even if the
heartbeat package was used.

> [PTT] Technically, "Failover" signals a renewal of a previous
> registration.  The backup MG is saying that it will pick up where the
> primary MG left off.  See section 11.4.  If an MG is starting from
> scratch, it should use "Restart".
>

<cnn>    Case 1:  MG switchover between primary and secondary MG.
                An issue is here is the ServiceChangeAddress.
               Said MGA registered w/MGC and MGC specified a
ServiceChangeAddress of 11,000
               for MG to use for further communication w/MGC.
              Upon MGA switch over to MGB, what ServiceChangeAddress
should MGB send
              the "Failover" to MGC - 2944 or 11,000?

             Since MGA and MGB are some kind of duplex MG
implementation, one would assume
             that there are equilization between MGA and MGB.  Therefore
MGB should send
             the "Failover" to MGC at 11,000 which MGA was using to
communicate w/MGC.

             Case 2:  MG detecting MGC failure.
             Section 11.5 specifies that MG should use "Failover" to its
secondary MGC.

              Now what ServiceChangeAddress should MG use to send
"Failover" to MGC2?

              MG was in associated w/MGC1 and MGC1 has specified
ServiceChangeAddress
               of 11,000.

              MG should send "Failover" to MGC2 using 2944 instead of
11,000 since MGC2
              does not know anything about MGC1 use of 11,000.
               Therefore MGC2 would not be listening on 11,000 for
message from MG.

              Thus, depending on what the Reason used for "Failover" to
MGC, the behavior
               at MGC is different.

              For Case 1:  Reason should be "MG Impending Failure" and
MGC continues
               call processing as before and as Tom said it is like "a
renewal of a previous registration."

              For Case 2: Reason should be "MGC Impending Failure" and
this "Failover" to
               the new MGC can't be considered as "a renewal of a
previous registration."
                since the new MGC has no previous info about a "previous
registration"
               and the new MGC can still decide whether to accept this
registration
               based on MGC load condition or security/provisioning
info.

               ANY COMMENTS??

> [PTT]  The associated procedure is shown in section 11.5.
> Unfortunately, the recommended reason in 11.5 is "MGC directed
> change", so it's not clear when "MGC Impending Failure" would ever be
> used.
>

<cnn> Section 11.5 first paragraph uses "MGC Impending Failure" for SC
Method Failover
             I think the Reason Code is
             what is important here.  Yes, the Reason text which is
optional is kind of misleading.

             "MGC directed change" is mention in  the Second paragraph
for MGC partial failure or
             maintenance reasons and the SC Method is Handoff.

--
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

---

From: Paul Rheaume <[email-masked]>
Date: Tue, 10 Apr 2001 15:29:52 -0400

> > registration.  The backup MG is saying that it will pick up where
> > the primary MG left off.  See section 11.4.  If an MG is starting
> > from scratch, it should use "Restart".
> >
> 
>              that there are equilization between MGA and MGB.
> Therefore MGB should send

[Paul] I agree. The redundant MG that is taking over should act just
like the MG that failed.

>              Section 11.5 specifies that MG should use "Failover" to
> its secondary MGC.
> 

[Paul] Exactly.

> 
>               Thus, depending on what the Reason used for "Failover"
> to MGC, the behavior
>                at MGC is different.
> 

[Paul] As far as the MG is concerned, this is "a renewal of a previous
registration". IMO that is the whole point of using Failover instead of
Restart, i.e. this indicates to the MGC that there may be some active
terminations and that the MGC should do an audit. Otherwise using
Restart with Root indicates that all terminations in the MG are in the
null context.

>                 since the new MGC has no previous info about a
> "previous registration"

[Paul] This is fine. The MG can keep trying to register with the other
MGC's it is configured with.

> > change", so it's not clear when "MGC Impending Failure" would ever
> > be used.
> >
> 

[Paul] It would be nice if we could clean this up a bit.

---

From: Ian Leighton <[email-masked]>
Date: Wed, 11 Apr 2001 11:05:16 -0400

Hi Tom/List

My comments [IL] are below.

Regards
Ian

> [PTT] This is covered in section 11 (various places).

[IL] All of which specifically refer to MG reset or Handoff
proceedures. IMO the first paragraph of section 11.5 should
read as follows (I have highlighted the changes in red);

"  If the MG detects a failure of its controlling MGC, it attempts to
   contact the next MGC on its pre-provisioned list.  It starts its
   attempts at the beginning (Primary MGC), unless that was the MGC that

   failed, in which case it starts at its first Secondary MGC.  It sends

   a ServiceChange message with a "Failover" method and a " MGC
   Impending Failure" reason. If the MG is
   unable to establish a control relationship with any MGC, it shall
   wait a random amount of time as described in section 9.2 and then
   start contacting its primary, and if necessary, its secondary MGCs
   again."

> scratch, it should use "Restart".

[IL] I don't understand what you mean by backup MG. The problem
I'am trying to address is MG behaviour after an MGC reset.  If I
understand this correctly the MG will send a Forced ServiceChange
(with "MGC Impending Failure") once it detects that the MGC has
reset. The MGC after powering up will have to accept a forced
ServiceChange as a registration. As a result of this I'am suggesting
that Section 7.2.8 should read as follows (additions in red);

"   A ServiceChange Command specifying the "Root" for the TerminationID
   and ServiceChangeMethod equal to Restart is a registration command by

   which a Media Gateway announces its existence to the Media Gateway
   Controller.  The Media Gateway may also announce a registration
command by
   specifying the "Root" for the TerminationID and ServiceChangeMethod
   equal to  Failover when the MG detects MGC failures. The Media
Gateway
   is expected to be provisioned with the name of one primary and
optionally
   some number of alternate Media Gateway Controllers...."

> change", so it's not clear when "MGC Impending Failure" would ever be

[IL] "MGC directed change" is part of the Handoff text. Failover uses
"MGC
Impending Failure". Should this be changed?

> > that could be added to the IG.

[IL] I'am suggesting additions to the IG because of discrepencies
between
section 7.2.8 and section 11.5. IMO section 7.2.8 should be changed as
follows
(additions in red);

"   6) Failover - sent from MG to MGC to indicate the primary MG is out
      of service and a secondary MG is taking over. This serviceChange
method
      is also sent from the MG to the MGC when the MG detects that MGC
has
      failed."