Subject: ServiceChange from a Dead Controller?

From: Alan Whitton <[email-masked]>
Date: Wed, 1 Nov 2000 14:57:42 -0500

{Apologies if this gets reposted, I never saw it appear}
OK,

I'd like to discuss what happens when a controller dies. Can the "new"
(i.e. partner of old controller) send a message to the Gateway "I am the
new controller, LISTEN TO ME NOW" ? (i.e. a servicechange message with that
capability).

In our model the partner controller has a different IP address, and it is
important for the Gateway to know it has a NEW controller at a different IP
address.

Cheers,
Alan

Holistic Metaservices Architect
CVX SS7 Gateway
Nortel Networks,

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 1 Nov 2000 15:18:01 -0500

Two answers depending on how "dead" the old controller is:

If it's alive enough to send a message, the old one sends a
ServiceChange to the MG.

If it's dead, the MG will notice and then go through it's list of MGs
to find the new one.

The security issues associated with an unsolicted "I'm your new boss" were
thought to be too great, and we decided NOT to allow such a message.

Brian

> -----Original Message-----
> From: Alan Whitton [mailto:[email-masked]]
> Sent: Wednesday, November 01, 2000 2:58 PM
> To: [email-masked]
> Subject: ServiceChange from a Dead Controller?
>
>

---

From: Alan Whitton <[email-masked]>
Date: Wed, 1 Nov 2000 18:31:24 -0500

All right,

Security is good, but if it's a message from a machine on the Gateway's
list, wouldn't that be the same?

The concern I have is that if the gateway "ignores" messages from a new
controller, until it figures out that it's OLD controller is dead, you'll
have a fair number of calls "fall on the floor". Is there any way around
losing those calls?

Cheers,
Alan

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 2 Nov 2000 09:47:32 -0500

I'm not sure that it's good enough to be on the list.
You get into problems like, more than one redundant MGC
telling you he's your new leader.  Usually it's best if the
public makes the choice on the leader, and not the other way
around :)

The issue of time to discover dead controllers is complex.  There are
those parameters that give you information on how long to expect
a reply to take.  On well-engineered networks, that time should be
short.  I don't think you would be dropping calls unless it's taking
seconds to declare MGCs dead.  On the Big-I internet, it might take
that long, but on a well-engineered net, it should be okay.

We spent a while talking about these issues when these decisions were
made.  We may not have the ideal solution for everyone, but we tried
to come up with one we believed would work.  If real-life testing
shows it doesn't, we will have to change, but I can assure you that
we did not treat this issue lightly, and there was quite a lot of
discussion on how to do this.  The result is, by every measure, a
compromise.  At the moment, I'd like to try to make what we have got
work, rather than changing the mechanism.

Brian

> Sent: Wednesday, November 01, 2000 6:26 PM
> To: [email-masked]; Rosen, Brian
> Cc: Alan Whitton
> Subject: Re: ServiceChange from a Dead Controller?
>
>
> OK,
>

---

From: Amy Pendleton <[email-masked]>
Date: Thu, 2 Nov 2000 13:21:19 -0600

I hate to keep revisiting decisions made but the fact is, Nortel has more
than one MGC in the market today using protocols which support the
equivalent of a ServiceChange message from the MGC directing its gateway
during a failover.  This mechanism is used both for real failure (dead MGC)
and for software upgrade.  In both cases, the newly activated MGC instance
(as we call it) is the only network element which can reliably determine who
should be in control (back to the issue of more than one MGC announcing it
is the leader -- the protocol used between the MGC instances should take
this case into account).  I question how the gateway can determine that the
MGC is failing at all.  There is no "heartbeating" mechanism in H.248, which
could be a good option for determining failure for either side of the
association, and the backoff algorithm described in H.248 will likely not
determine the failure in a timely manner especially on gateways which are
not doing the bulk of messaging (in an ISUP or PRI network, the MG mainly
responds to commands from the MGC).

I think to simply throw out an already existing solution has the potential
of limiting the coverage for H.248.  If MGC's find that H.248 will not help
their solution or could even hurt it, they will choose to implement a
non-compliant H.248 or stick with their protocols (most often MGCP will be
the protocol of choice).

Regards,
Amy

> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Thursday, November 02, 2000 8:48 AM