Subject: Re: MGC-Initiated Control

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Jun 2000 15:05:37 -0500

Amy (more eloquently) states a number of my concerns as well.  I am
interested as to how they might be addressed.  I am concerned about
fault-tolerant mated MGCs with separate transport addresses, and load
sharing between the mates.  I also agree that exposure of the MGC
redundancy architecture to the MG should not be necessary.

On Tue, 06 Jun 2000, Amy Pendleton wrote:

> Hi,
>
> I would like to present some more justification for the proposal of which
> Tom Taylor spoke.
>
> (1) The MGC is the central point of control within the network.  All call
> services run through the MGC and only it knows when it is ready to
> receive calls and to establish connections.
>
> (2) MGC failover strategy is exposed to MG's by allowing the MG to
> attempt to "rehouse" itself when it detects an MGC instance has failed.
> The MGC maintains a fault tolerance system between its instances and
> should remain in complete control of which instance is active at a given
> time.  It has always looked to me like by allowing the MG's to hunt for
> their serving MGC, the  specification is suggesting that the MG should
> have some part in the failover of an MGC. In the case where an MG is
> isolated from its serving MGC but the MGC is in fact working fine with
> the rest of the network, what is achieved by having the MG try the next
> MGC instance in its list.
>
> (3) MGC's ability to provide call services will be delayed by waiting for
> the gateways to establish communication with it both on initialization
> and failover.
>
> I recognize that the random spreading of (re)connection from the MG to
> the MGC may work but note that MGC-initiated control does not require
> this to scale -- the MGC will establish connectivity based on it own
> ability to handle call or network traffic.
>
> Thanks,
> Amy
>

--
Brian F. G. Bidulock

---

From: Amy Pendleton <[email-masked]>
Date: Tue, 6 Jun 2000 14:15:37 -0500

Hi,

(1) The MGC is the central point of control within the network.  All call
services run through the MGC and only it knows when it is ready to receive
calls and to establish connections.

(2) MGC failover strategy is exposed to MG's by allowing the MG to attempt
to "rehouse" itself when it detects an MGC instance has failed.  The MGC
maintains a fault tolerance system between its instances and should remain
in complete control of which instance is active at a given time.  It has
always looked to me like by allowing the MG's to hunt for their serving MGC,
the  specification is suggesting that the MG should have some part in the
failover of an MGC. In the case where an MG is isolated from its serving MGC
but the MGC is in fact working fine with the rest of the network, what is
achieved by having the MG try the next MGC instance in its list.

(3) MGC's ability to provide call services will be delayed by waiting for
the gateways to establish communication with it both on initialization and
failover.

I recognize that the random spreading of (re)connection from the MG to the
MGC may work but note that MGC-initiated control does not require this to
scale -- the MGC will establish connectivity based on it own ability to
handle call or network traffic.

Thanks,
Amy

> -----Original Message-----
> From: Brian F. G. Bidulock [SMTP:[email-masked]]
> Sent: Tuesday, June 06, 2000 1:15 PM
> To:   [email-masked]
> Subject:      Re: MGC-Initiated Control
>
> Christian,
>
> Thanks for the tips.  Are you referring to your v5 draft of MGCP?  Does it
> include recommended time intervals and priorities?
>
> Also, I am confused as to which timers do not need to be maintained doing
> it "from the MG".
>
> On Tue, 06 Jun 2000, Christian Huitema wrote:
>
> >
> > > I understand that you have considerable experience in this
> > > area.  How did
> > > you intend to handle the recovery situation where the network
> > > between MGC
> > > and MG is interrupted and all MGs attempt to reconnect as soon as the
> > > network is re-established?
> >
> > This is discussed at length in the MGCP documentation (ask the Cable
> Labs).
> > Basically, you use a random spreading of the [re]connection attempts
> over an
> > appropriate time interval, and you skew the spreading so that MG's that
> > actually need to speak, because they have some change of state to
> report,
> > become more impatient than those with nothing special to say. Note that
> this
> > second part, providing priority to the MG's that need it most, would be
> > impossible in an MGC-driven reconnection. Also, doing it "from the MG"
> > reduces the load at the MGC, which does not need to maintain timers,
> etc.
>
> --
> Brian F. G. Bidulock