Subject: Re: [Megaco] Re: Polls of MGC

From: Christian Groves <[email-masked]>
Date: Wed, 01 Aug 2001 11:58:06 +1000

G'Day Terry,

I'm still of the opinion that if you have a well designed MGC you are
not going to encounter this problem. If we look at todays phones there's
only about 6min a year where your line should be down. Another problem I
see is the flooding of MGCs with lots of "are you alive messages?". So I
support no change to the main protocol and option 2.

Having said that if someone wants to create a package to do polling
where the MGC can control the interval (ie. option #3 or #5) then I'm
not going to stop them. Supporting it is optional and I see it only
being used in limited scenarios. The MGC then has full control over how
the MG is operating with respect to sending messages.

Cheers, Christian

Terry L Anderson wrote:
> 
> 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

_______________________________________________
Megaco mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/megaco

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 1 Aug 2001 05:26:30 -0400

All,

I still firmly believe that MGs should only watch for messaging and should
not poll to determine if the MGC is present on the network..  If the MGC-MG
interconnection needs to be monitored, then the MGC should poll, and the MG
can watch for the polls -- when it detects that there has been no messaging
for some (implementation-dependent) amount of time, it can go through
Failover procedures.  Having the MG poll will only congest the network with
more messaging -- messaging that will be useless a significant portion of
the time.

That being said, Christian has an excellent point -- if someone wants to put
together a polling package, then no one is going to stop them.  However, I
too see limited use in such a package.

Kevin

 -----Original Message-----
From: 	Christian Groves [mailto:[email-masked]] 
Sent:	Tuesday, July 31, 2001 9:58 PM
To:	Terry L Anderson
Cc:	[email-masked]
Subject:	Re: [Megaco] Re: Polls of MGC

G'Day Terry,

Cheers, Christian