Subject: RE: Polls of MGC

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 24 May 2001 10:16:56 -0400

Security implications.  
"Hello, I'm your new master. Don't worry, everything will be all right"

Brian

> -----Original Message-----
> From: Troy Cauble [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 9:57 AM
> To: Terry L Anderson
> Cc: [email-masked]
> Subject: Re: Polls of MGC
> 
> 
> Terry L Anderson wrote:
> > 
> > (resending since my original seems not to have made it to the list)
> > 
> > MGC/MG relationship is indeed master/slave but 
> registrations are only
> > initiated
> > from the MG end, so MGC being aware of loss of connectivity or an
> > alternate MGC
> > being aware that the primary is down does not allow 
> reconnection to the
> > alternate - only the MG can take action to register with 
> the alternate
> > (as in
> > 11.5).  
> 
> Again, it seems much cleaner to fix this problem by changing
> "registrations are only initiated from the MG end" statement.  
> Why are MGC initiated regstrations considered so evil?
> 
> -troy
> 
> > So it seems to me most important that MG detect failures (as it
> > is the
> > only one that can take action).  Its the MGC that can do 
> little when it
> > detects
> > a failure.
> > MGC perhaps should make the decision as to whether failures 
> should be
> > detected
> > and frequency of polling but it seems to me that MG should do the
> > polling.
> > 
> > For failures of a TCP link or MGC failure and recovery 
> without loss of
> > state,
> > MGC may reestablish communications with a re-registration, 
> but I don't
> > understand how an alternate MGC can take over after a 
> primary failure
> > without MG
> > 
> > detecting the failure.
> > 
> > I did not think that an MG normally sent Add, Move, 
> Subtract.  I believe
> > that
> > the only MG initiated transactions commonly used are Notify and
> > ServiceChange.
> > Thus during a quiet period (edge GW with SS7/ISUP 
> signaling, no active
> > calls),
> > there would be no active events and so no reason to send 
> either Notify
> > or
> > ServiceChange and so GW would be unaware that:
> > 1. MGC has gone down
> > 2. network has lost connectivity to MGC
> > 
> > In either case, without polling, MG would be unaware.  Yet 
> registering
> > with
> > alternateMGC might allow it to handle calls.
> > 
> > I thought that the previously discussed methods for MGC and for MG
> > polling were
> > adequate but if we want to add a new mechanism, one could 
> allow complete
> > control
> > 
> > from MGC end by adding a "timer" event through a package.  MGC could
> > activate
> > the timer event on say root termination and this would 
> cause a notify
> > after the
> > MGC specified period.  MGC would detect failure by lack of 
> this notify.
> > MG
> > would detect failure when the Notify received no reply.  MGC thus
> > decides
> > whether polling should occur, what period to use and there is only
> > polling
> > traffic in one direction but both ends detect failure.  It would be
> > improved if
> > the package specified that the timer was automatically reset by any
> > messages, so
> > 
> > it would fire only when no messages had been exchanged for 
> the specified
> > time
> > (MGC would still detect failure by absense of any message 
> for greater
> > than the
> > timer period, MG detect by failed reply).
> > 
> > Christian Groves wrote:
> > 
> > > G'Day Troy et all,
> > >
> > > Sorry for the late support of No Polling. I still have not seen a
> > > definitive reason that the MG needs to poll the MGC. We 
> have defined a
> > 
> > > master slave protocol with the MGC as the master. The MGC 
> should be in
> > 
> > > control of error situations.
> > >
> > > I believe that it's enough that the MG can detect that the MGC has
> > gone
> > > down when it try to signal using any appropriate H.248 
> Commands ie.
> > > Add, Move, sub replies, Notify request, Service Change 
> etc. Lack of
> > > timely response will indicate failure. The MG can then re-register
> > based
> > > on this.
> > >
> > > If you look at the common MG use cases:
> > > 1. The MG is a trunking gateway. In this scenario enough 
> traffic will
> > be
> > > generated to maintain a reasonable flow of signalling to 
> minimise the
> > > time to detect errors. For a proper Telco solution you should also
> > have
> > > enough management systems/redundency to know what MGC to 
> hand over to.
> > 
> > >
> > > 2. The MG is a residential gateway. Signalling traffic is not that
> > great
> > > but interaction is only needed with the MGC when the end-user does
> > > something. Therefore the MG will find out about the 
> failure at this
> > > time. Why generate unessary signalling across limited BW links?
> > There's
> > > the avalanche problems mentioned earlier but more 
> importantly someone
> > > will have to pay for bandwidth this signalling takes 
> which basically
> > > serves no purpose.
> > > Again in this scenario the MGC will hopefully be owned by 
> someone who
> > > wants to offer a decent service and has the necessary management
> > > systems/reduncy. I do not envisage MG registration will 
> take very long
> > 
> > > on a small residential gateway. Its a ServiceChange 
> request/response
> > > round trip.
> > >
> > > What ever the proposed package, service change 
> reason/method, protocol
> > 
> > > update polling is unecessary.
> > >
> > > Cheers, Christian
> > >
> > > Troy Cauble wrote:
> > > >
> > > > Dave Sclarsky wrote:
> > > > >
> > > > > Troy,
> > > > >
> > > > > It doesn't matter what the new (or restarted) MGC 
> knows or doesn't
> > know.
> > > > > Megaco defines that the control association between 
> MG and MGC is
> > ALWAYS
> > > > > initiated by the MG.
> > > >
> > > > Then this definition is the problem and should be revisited.
> > > >
> > > > Polling is bad.
> > > >
> > > > -troy
> > > >
> > > > > Given that definition, Johnny's Dad's MG won't be
> > > > > reachable by a new (or a restarted) MGC until the his 
> MG notices
> > the
> > > > > failure.  We must define a way for it to know ASAP!
> > 
> > --
> > -------------------------------------------------------
> > Terry L Anderson, DMTS                   [email-masked]
> > Lucent Technologies /INS/ Voice over IP Access Networks
> > Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
> > Voice:908 582-7013  FAX:908 582-6729
> > http://its.lucent.com/~tla  (Lucent internal)
> > http://www.gti.net/tla
> > -------------------------------------------------------
>

---

From: Troy Cauble <[email-masked]>
Date: Thu, 24 May 2001 10:38:16 -0400

Brian,

How would an MG find a secure alternative to talk to?
By using it's pre-provisioned list, right?

If an MG accepts "I'm your new master" messages only
from MGCs on the same pre-provisioned list, the 
level of security is EXACTLY THE SAME.

-troy

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Thu, 24 May 2001 10:52:56 -0400

Hi Brian/all,
A Novice doubt. If the MG can say to MGC that "I'm your slave...please
control me", why not the MGC can say "I'm your new master". I think both MG
and MGC will know each other by pre-provisioning. Else any MG can register
to any MGC and any MGC can control any MG.

Regards
Madhubabu

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Rosen, Brian
Sent: Thursday, May 24, 2001 10:17 AM
To: 'Troy Cauble'; Terry L Anderson
Cc: [email-masked]
Subject: RE: Polls of MGC

Security implications.

Brian