Subject: Reset of an MGC

From: Ian Leighton <[email-masked]>
Date: Tue, 03 Apr 2001 21:22:08 -0400

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?

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?

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? 

Ques 4) - Why is the method "MGC Impending Failure"?
Hasn't the MGC already failed?

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.

Any comments would be appreciated.

Regards
Ian Leighton

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 11 Apr 2001 15:02:31 -0400

We've been talking at cross-purposes because I was working from the method
descriptions in section 7.2.8.  There is a clear discrepancy between the
description of method Failover there and the instructions in section 11.5.
We definitely have to fix that.  I would actually propose that 11.5 be
altered to use method "Disconnected" and the reason "Transmission Failure",
since it can't tell that from MGC failure.  I would also broaden the
definition of "Disconnected" in section 7.2.8 to cover a change of MGCs in
this situation.

Your proposed additional behaviour in the search for an MGC is reasonable.
The editors probably just goit tired of repeating the same thing from one
section to the next.
 
-----Original Message-----
From: Ian Leighton [mailto:[email-masked]]
Sent: Wednesday, April 11, 2001 11:05 AM
To: Taylor, Tom-PT [NORSE:B881:EXCH]; [email-masked]
Cc: Ian Leighton
Subject: Re: Reset of an MGC

Hi Tom/List 
My comments [IL] are below. 
Regards 
Ian 
  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. 
> -----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 
> 
[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. 
> Should this be added to the IG? 
[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." 
  
> 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".

[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...." 
  
> 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.
[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. 
[PTT] See 11.5.
[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."