Subject: RE: Polls of MGC

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Tue, 17 Jul 2001 10:31:13 -0400

Did we ever come to a conclusion on how to Poll ?Thread "Polls of MGC".  If
yes, can someone
summarize what has been concluded ?

  Thanks
- Madhubabu

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 31 Jul 2001 15:40:51 -0400

I'm sorry to bring this up again (the thread has over 100 messages to date),
but I do not believe we ever resolved this.  It died down May 24 at least
partly because several of the participants began traveling to Porto Seguro, as
well as lack of any consensus.  Two more recent queries about the status failed
to generate much response or claim of consensus, so I will try to summarize
where I think we are.  There are a number of positions:

1) change nothing.  MGC can poll MG using null Audit and MG can poll MGC using
a ServiceChange Restart on an inservice termination
Pro: Needs no change in protocol.  Neither entity needs any special capability
from the other or even need tell the other that the purpose is "polling".
Con: If both want to detect failure, we get two sets of message/replies when
one would do if they had an agreement.  MGC cannot prevent MG from polling or
control frequency.  There may be no terminations in service (but one could then
confirm the out-of-service state by sending ServiceChange Forced on a
termination).  Sending ServiceChange on a termination requires knowing what
Context it is in which may be inconvenient for a link manager routine.

2) change nothing.  MGCs can poll MG using null Audit and MGs should NOT poll.
Pro: Needs no change in protocol. MGC controls polling activity (if polls occur
and frequency).  Avoids two sets of polls. (one arguement was MGC should be
fault tolerant and never fail, but then why do we have alternate MGCs?  Only
for planned handoff?)
Con: MG must establish new assoc with alt MGC but may not be aware of fault in
some cases (calls initiate at MGC, e.g, SS7, and MG cannot tell difference
between low traffic and failed MGC and so alt MGC cannot initiate calls on the
MGs lines).  MG doesn't know the frequency of polling (or if polling is
occurring) and so does not know duration of silence that should constitute
failure.

3) add polling package.  MGC can poll MG using null Audit but inform MG about
polling and frequency using polling package property.
Pro: MGC controls if polling occurs and frequency, avoids two sets of polls.
No change in protocol but a new package.  MG can detect failure from silence
longer than property setting.  Note that package can define polling to occur
only during lack of other messages, MG detects failure from complete message
silence not just lack of polling.  MGC can detect failure even if MG does not
implement package.
Con: if MGC does not choose to use package MG cannot detect failure (maybe ok,
MGC should decide reliability policy).

4) same as #3 but a new more distinctive message rather than null audit.
Con: Little advantage over #3 and changes protocol.

5) Timer Event Package on ROOT.  Not exactly polling, but equivalent.  MGC adds
a "timer" event to event list of ROOT with a specified duration property.  This
causes MG to Notify when timer expires.  MGC detects failure if Notify fails to
arrive on time.  MG detects failure if Notify receives no reply.
Pro: no change in protocol, but new package.  Such a timer package might have
some other uses??  MGC controlls frequency of "polling". MG's failure detection
is nothing special since it normally detects failure on timeout for response -
it need not know that the timer is for this purpose.  Timer package is little
different from polling package in #3 - both set a timer based on a package
property.  If timer were special for failure detect it could implicitly reset
on any message and so Notify only during silence from other messages.  Both MGC
detects failure from silence longer than timeout rather lack of Notify longer
than timeout. Note that message traffic is same, if timer event is assumed to
reset after notify.
method #3: Audit/response - Audit/response - ...
method  #5 Event/response - Notify/response - Notify/response - ...
that is only one pair extra at beginning of association.
Con: requires MG to implement package for failure detect in either direction.
Might cancel signals if we support ROOT signals.

6) add  Method to ServiceChange.  MGC polls using null Audit.  MG polls using
ServiceChange on ROOT using new "no-op" method or "poll" method.
Pro: similar to #1 but avoids problems with using a non-ROOT termination.
Con: changes the protocol (rather than adding a package).

So where are we?
I think #2, #3 and #5 or minor variations on these had the most support, but I
saw no consensus.  Both #3 and #5 require new packages.  I will volunteer to
draft a package for the next Rapporteur's meeting if we have any consensus
between #3 vs #5 or do I need to write both to be looked at in more detail?

--
Waiting for the other shoe to drop but hoping its a one legged man.
------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla