Subject: Re: MGC-Initiated Control

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 2 Jun 2000 10:58:25 -0400

I agree with the "potential security problem" -- that's why I said it would
have to be an authorized source.  In what you say below: how does the MG
know that connectivity has been restored?  The ServiceChange command is one
way of doing that.

> -----Original Message-----
> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Friday, June 02, 2000 10:48 AM
> To:   Taylor, Tom-PT [NORSE:B901:EXCH];
> [email-masked]
> Subject:      RE: MGC-Initiated Control
>
> It's a potential security problem, because any arbitrary MGC that
> stumbles across an otherwise unmarried MG can take it over.  In the
> present model the MGC has to be someone you are provisioned to trust,
> or someone one of the MGCs you trust told you to trust.
>
> Not a really big deal.  I think the circumstance is so rare as to be
> not worth worrying about.  I did think about a circumstance where
> the MG lost connectivity to all MGCs.  It went through its list in
> vain.  The real correct response, when connectivity is restored, is
> to restart the search, and not to have some MGC simply step up and
> take it.
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:[email-masked]]
> > Sent: Friday, June 02, 2000 9:45 AM
> > To: [email-masked]
> > Subject: MGC-Initiated Control
> >
> >
> > There are cases where an MG will not be able to initiate a
> > control session
> > (e.g. it has gone through its list of MGCs without success).
> > Can we agree
> > on principle that an MG that is not currently in a control
> > session will
> > respond to an MGC-sent ServiceChange command directing it to
> > initiate a
> > session at a given address?  If so, we could add this to the
> > Implementor's
> > Guide and our IETF equivalent.
> >
> > The exact text that would go into the Implementor's Guide would be as
> > follows:
> >
> >         If an MG is not currently in a control association
> > with an MGC and
> > it receives a ServiceChange command from an authorized source with
> > ServiceChangeMethod equal to Handoff, it will attempt to
> > initiate a control
> > association as directed by that command.  To make this
> > possible, an MG not
> > currently in a control session shall listen for incoming
> > commands at the
> > default transport address corresponding to its supported transport and
> > encoding (e.g. UDP port 2944 for text-encoded UDP/ALF).
> >
> > Tom Taylor
> > Phone and FAX: +1 613 736 0961
> > E-mail: [email-masked]
> >

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 2 Jun 2000 11:48:18 -0400

I don't know what "authorized source" would be, unless it was one of the
provisioned MGCs
it had already tried.

It does occur to me that you could add a reason which equated to "start
looking again"
Then any MGC could trigger the MG to start again, if it was in the state you
are positing.

Again, I don't really think this is very important, and I don't feel
strongly negative about your
proposal.

In my connectivity lost scenario, I would have the MG wait and then start
again after some delay,
and I would make the delay backoff exponentially.

Brian

        -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Friday, June 02, 2000 10:48 AM
To:     Taylor, Tom-PT [NORSE:B901:EXCH];

        Brian

> From: Tom-PT Taylor [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 2 Jun 2000 14:29:59 -0400

As the protocol is documented now, it is true that an MG could not
establish an association with an MGC not on it's pre-provisioned
list.

Tom's suggestion undoes this restriction, but it would only take
effect if none of the preprovisioned MGCs would accept the MG
for service.

Brian

> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Friday, June 02, 2000 1:55 PM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: Re: MGC-Initiated Control
>
>
>
>
> "Rosen, Brian" wrote:
>
> Are you saying that the protocol does not allow an MG to talk
> to an MGC
> that's not part of a pre-provisioned list of MGCs, or are you simply
> referring to proper security credentials being presented ?
>
> -- Flemming
>
>
>
> >
> >
> --
> Flemming Andreasen                Phone: +1 732 452 1667
> Cisco Systems                     Fax:   +1 240 359 5839
>
>

---

From: Bharat Kaul <[email-masked]>
Date: Fri, 2 Jun 2000 11:29:16 -0700

I was under the impression till now that, in principle, it will always be an
MG initiating a conversation with the MGC.

In TCP world it implied MG establishes connection with the MGC and sent a
ServiceChange command (and thereby negating the need to have a listening
server in MG).....Right ?

In UDP world, life was simpler but still MG initiates the conversation with
the MGC by sending a ServiceChange.

If my understanding is wrong, I would appreciate clarifications.

Assuming my understanding is wrong, then with the approach suggested there
are a couple of issues listed below

1. In principle, MGC are not supposed to knowing unmarried MG's. If so, then
how does MGC sending the ServiceChange figure out that the MG is unmarried ?
The only option seems network management. And then it can be argued that
network management can also intervene on MG side and make MG initiate
conversation with a new MGC.

2. Additionally, it enforces that MGC contacting the MG should now know the
encoding schemes supported at the MG ..how does MGC figure that out ?

3. Also, do people on here expect MG's to be using both TCP and UDP
simulataneously for communication to MGC. I would think that an MG will
choose either one. If that is true, then how will the contacting MGC in
suggested approach pick transport type.

Thanks
Bharat

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Friday, June 02, 2000 8:48 AM
To: [email-masked]
Subject: Re: MGC-Initiated Control

Brian

        -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Friday, June 02, 2000 10:48 AM
To:     Taylor, Tom-PT [NORSE:B901:EXCH];

        Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Sun, 11 Jun 2000 18:09:27 -0400

Comments below

Brian

-----Original Message-----
From: Amy Pendleton [mailto:[email-masked]]
Sent: Tuesday, June 06, 2000 3:16 PM
To: [email-masked]
Subject: Re: MGC-Initiated Control

Hi,

I would like to present some more justification for the proposal of which
Tom Taylor spoke.

(1) The MGC is the central point of control within the network.  All call
services run through the MGC and only it knows when it is ready to receive
calls and to establish connections.

<br> These are distributed systems.  While the MGC is the "Controller" (the
C in MGC), no calls can be handled until all the components are ready.  The
design of the protocol permits the MGC to control when calls are accepted.

(2) MGC failover strategy is exposed to MG's by allowing the MG to attempt
to "rehouse" itself when it detects an MGC instance has failed.  The MGC
maintains a fault tolerance system between its instances and should remain
in complete control of which instance is active at a given time.  It has
always looked to me like by allowing the MG's to hunt for their serving MGC,
the  specification is suggesting that the MG should have some part in the
failover of an MGC. In the case where an MG is isolated from its serving MGC
but the MGC is in fact working fine with the rest of the network, what is
achieved by having the MG try the next MGC instance in its list.

<br> There are many failover strategies.  Some require the MG detect
failure, some require the standby MGC to detect failure, some have
mechanisms that are not even visible to the MGs.  Skewing the protocol for
one of these doesn't seem appropriate.  I'll grant that you would ideally
like to have the protocol neutral to all.

(3) MGC's ability to provide call services will be delayed by waiting for
the gateways to establish communication with it both on initialization and
failover.

<br> I don't really understand this.  At best, it's true in one direction
only (call from some gateway that is initialized towards a gateway that is
not).  Having MGs get control associations with the randomization Christian
suggested has to result in better average response if both directions are
considered.  I think the whole subject is not worth worrying about.

I recognize that the random spreading of (re)connection from the MG to the
MGC may work but note that MGC-initiated control does not require this to
scale -- the MGC will establish connectivity based on it own ability to
handle call or network traffic.

<br> in general, I suspect you are not thinking about the really interesting
cases of mostly residential gateways.  If there are only trunk or other
large scale access gateways, there are few enough of them that these issues
don't matter at all.  The real issue is that it's the MG that is the one
that will go up and down, and the MGC will be relatively stable.  In that
circumstance, you want the MG to contact the MGC when it comes back up.  You
don't want the MGC polling all the non-responding MGs periodically.  Failure
of the MGC has to work pretty well, but randomized backoff does work pretty
well.

Finally, the protocol is pretty fixed now.  Anything that changes behavior
has to be considered a CS2 kind of thing.  It's fine to start a list of
these issues, but I think we have to shelve any that are not real
show-stoppers.  This just isn't such an issue.

Thanks,
Amy

        -----Original Message-----
From:   Brian F. G. Bidulock [SMTP:[email-masked]]
Sent:   Tuesday, June 06, 2000 1:15 PM
To:     [email-masked]
Subject:        Re: MGC-Initiated Control

        Christian,

        Thanks for the tips.  Are you referring to your v5 draft of MGCP?
Does it
include recommended time intervals and priorities?

        Also, I am confused as to which timers do not need to be maintained
doing
it "from the MG".

        On Tue, 06 Jun 2000, Christian Huitema wrote:

        >
> > I understand that you have considerable experience in this
> > area.  How did
> > you intend to handle the recovery situation where the network
> > between MGC
> > and MG is interrupted and all MGs attempt to reconnect as soon as the
> > network is re-established?
>
> This is discussed at length in the MGCP documentation (ask the Cable
Labs).
> Basically, you use a random spreading of the [re]connection attempts over
an
> appropriate time interval, and you skew the spreading so that MG's that
> actually need to speak, because they have some change of state to report,
> become more impatient than those with nothing special to say. Note that
this
> second part, providing priority to the MG's that need it most, would be
> impossible in an MGC-driven reconnection. Also, doing it "from the MG"
> reduces the load at the MGC, which does not need to maintain timers, etc.

        --
Brian F. G. Bidulock