Subject: Re: MG-MGC association for redundant MGC

From: Amy Pendleton <[email-masked]>
Date: Sun, 4 Feb 2001 13:16:20 -0600

Unless I am misreading it,  annex N looks like a congestion control
mechanism, not a heartbeat.

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]]
Sent: Saturday, February 03, 2001 10:44 AM
To: [email-masked]
Cc: [email-masked]; Pendleton, Amy [NGC:B815:EXCH]
Subject: Re: MG-MGC association for redundant MGC

Let's see if I understand you correctly.  The same IP address will be used
for
both the primary and secondary MGC.  If UDP/ALF is being used and primary
and
secondary are sharing state, I would think it would be unnecessary to
reestablish the association.  If those conditions are not met,
reestablishment
is necessary.  As Amy Pendleton and I have argued in the past, switchover
would
come more quickly if it could be triggered by the newly active MGC.
Otherwise
the MG has to infer the need for switchover from a loss of communications
with
the primary (probably using a heartbeat mechanism like the proposal in draft
H.248 Annex N -- see
ftp://standards.nortelnetworks.com/megaco/docs/Current/ITU-SG16/
).

Sarika Gupta wrote:
>
> Hi,
>    We are trying to develop fault tolerant platform(with 1+1 redundancy)
over
> which multiple MGC applications can run.
>      MG is an external entity which is from a different vendor and  we
don't
> have any control over its implementation.
>      For switchover from active to standby node, in case the active fails,
we
> are using the Floating IP concept, so that only one IP address is visible
to the
> external world. Thus for MG there is only one MGC visible with this
Floating IP
> address configured in its primary MGC IP address parameter.
> Now since MGC acts as server and the MG acts as a client, so whenever  we
do the
> switchover, the MGC server shall be established again.
> But MG shall have to connect as a client to this server again which
implies it
> shall have to create a new n/w association.
> My query is is there any way to avoid this creation of a new association
by MG?
> If yes then how?
> Plus is there any standard which can give us some exact figueres as to
what
> should be the value of retransmission timers  for MG and the number of
retries
> before it tries to make a new association.
>
> Regards
> Sarika

---

From: Tom Taylor <[email-masked]>
Date: Sun, 4 Feb 2001 17:09:24 -0500

Oops.  Christian did have a heartbeat proposal -- a signal on root.  I've lost
track of where that is documented.

> Amy Pendleton wrote:
>
> Unless I am misreading it,  annex N looks like a congestion control mechanism,
> not a heartbeat.
>
> Let's see if I understand you correctly.  The same IP address will be used for
>
> both the primary and secondary MGC.  If UDP/ALF is being used and primary and
> reestablish the association.  If those conditions are not met, reestablishment
>
> come more quickly if it could be triggered by the newly active MGC.  Otherwise
>
> the MG has to infer the need for switchover from a loss of communications with
>
> >      MG is an external entity which is from a different vendor and  we don't
>
> > are using the Floating IP concept, so that only one IP address is visible to
> the
> > external world. Thus for MG there is only one MGC visible with this Floating
> IP
> > Now since MGC acts as server and the MG acts as a client, so whenever  we do
> the
> > But MG shall have to connect as a client to this server again which implies
> it
> > My query is is there any way to avoid this creation of a new association by
> MG?
> > If yes then how?
> > Plus is there any standard which can give us some exact figueres as to what

---

From: Christian Groves <[email-masked]>
Date: Mon, 5 Feb 2001 10:26:34 +1100

G'Day Tom,

Its only in a contribution. As H248v2 we'll produce an updated draft
with this change. It was a small change just saying that signal were
applicable for root.

Cheers, Christian