Subject: Re: MGC-MG Control Relationship

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 21 Oct 1999 07:51:56 -0500

As I told you privately, your protests were a source of ironic amusement to
me given that people with whom you work chastised me severely last year for
insisting on a close relationship between an MG and a single MGC.  I've
attached a copy of one of the notes this list received on the subject.  With
a little more digging I can find my acceptance of this position.

 <<Re: Scaling (was Re: FW: Message Coding)>>

> -----Original Message-----
> From: Hong Liu [SMTP:[email-masked]]
> Sent: Thursday, October 21, 1999 1:01 AM
> To:   [email-masked]
> Subject:      MGC-MG Control Relationship
>
> Hi, all,
>
> I have been involved in MEGACO/H.248 from the very beginning. I have
> been always under the impression that at least for version 1 of the
> protocol, at any instance of time, a single MG (physical or virtual) is
> under the control of EXACTLY ONE MGC. However, in the MEGACO/H.248
> discussion this afternoon (10/20), I was told that this is not true. In
> other words, multiple MGCs can control the same MG at the same time. I
> may be totally out of touch, this is a big surprise to me. Maybe someone
> on the list can remind me when this decision was made.
>
> While there may be situations where multiple MGCs controlling a single
> MG is desirable, there is a lot of issues to be resolved for sharing the
> same set of terminations. This is certainly an area that requires
> further study. I just don't think it is a good idea to include this
> feature in the current protocol.
>
> --Hong

Subject: Re: Scaling (was Re: FW: Message Coding)
From: [email-masked]
To: Paul Sijben <[email-masked]>
Cc: Christian Huitema <[email-masked]>, Matt Holdrege <[email-masked]>, "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904-I]" <[email-masked]>, [email-masked]
Date: Wed, 16 Dec 1998 14:00:24 -0500

Paul,

Sorry about the late reply.

My comment is on your statement:
A MG performs functionality with strict
timing requirements. The controller therefore must have a fairly tight
control over the MG to meet these requirements.

I addressed this same point in my earlier, pre navdec meeting, response.
I could tell by your reply to that that you didn't get my point ... which
was ..
there MUST be an ability for multiple (i.e., not a single) relationship
between
many MGCs and one given MC.

To restate what I said earlier, a given call agent functionality (call it
what you
might ... a MGC call agent entity) might support a particular service
provider need well (let say something dumb like CENTREX). A service
provider might purchase CA/MGC#1 for this feature. But the same service
provider may want to use CA/MGC#2 because a large customer
it desires to support uses it instead (because of the different service
provider features it supplies). It will happily deploy many CA/MGC entities
to be used with its present composition of MGs. Thus, there can be
a multiplicity of "CA/MGC controllers" to a given MC.

We do not know why the "timing relationships" between the MG elements
involved with one "call/session" and it's associated CA/MGC (for that
call/session)
is unworkable (as you seem to imply). I'd be interested in your comment ...
as I can't
think of a case where one is inherently different.

As per the rationale why such a multiplicity of CA/MGC types are required,
I
will again repeat from my earlier posting:
******BEGIN EARLIER POSTING**********
ON THE ISSUE OF MULTIPLE CA/MGC ..... the MDCP proposal
ties the MGC to the MG in a way that is totally unacceptable from a
SERVICE PROVIDER perspective. Service providers desire a
multiplicity of CA/MGC for a wide range of reasons, some of these
include:

* Quick deployment of a new feature (use a CA/MGC that supports
it, instead of waiting for that feature to be implemented in a given
MG to MGC pair from a particular manufacturer). LECs do not
desire a situation similar to Class5 switch software generic updates.
They have been there and done that ... and do not desire it to happen
again.

* Progressive "rollover" to CA/MCG of different manufactures without
disrupting the network (read without causing pain to the individual MGs).

These are only two reasons, but they illustrate the point that you do not
want to tie the MG to a particular MGC.
***END EARLIER POSTING******

This point was discussed at length at the mecago meeting and the
requirement of a multiplicity of MGC connecting to one given MC
was agreed to in the meeting (see Matt Holdrege's meeting notes).

Lastly, to reiterate a comment Christian made recently ... we are not
as far away from each other as the many comments on the reflector
might indicate to an outside observer. The "control channel", "failover
cases/methodology" and "timing issues" (which I don't yet get your
point) seem to be some significant differences to be worked out.

Hope to see you at TIPHON,

Michael Ramalho

Paul Sijben <[email-masked]> on 12/11/98 05:40:14 AM

To:   Christian Huitema <[email-masked]>
cc:   Matt Holdrege <[email-masked]>, "Taylor, Tom-PT [SKY:B318-I:EXCH]"
      <[email-masked]>, [email-masked] (bcc: Michael A.
      Ramalho/Bellcore)
Subject:  Scaling (was Re: FW: Message Coding)

Christian,

you write:
>If you look at SGCP and MGCP, you will see
>that there is for example no explicit "control session" between the
>MG and the MGC -- the control is strictly relegated to the security
>layer, and the MG is suppose to blindly execute all the commands that
>have been proven to come from an authorized MGC.  This simple feature
>allows to spread the end points of an MG onto an arbitrary number
>of MGC, and is in fact a guarantee of scalability.

I find your comment interesting and puzzling. You state that because every
authenticated controller can connect through the MG MGCP is well scalable.
I don't think I understand that. I am curious how you can guarantee timing
constraints and resource availability using such a loose control model.

We have taken a different approach. A MG performs functionality with strict
timing requirements. The controller therefore must have a fairly tight
control over the MG to meet these requirements. Our registration session is
used to establish the credentials of controllers (security), set timing
constraints and to allow graceful and quick switchover (because the backup
controllers are known in advance) and is needed only _once_ as long as the
boxes remain on-line.

We do understand the desirability that other controllers will use resources
in MGs not under their direct control. For that we have the PEER
registration, this registration will allow more flexibility but (maybe)
worse timing guarantees. We believe that because the requirements on these
boxes are so strict, more thought needs to be devoted to the implications
ofpeer registration, that is the reason why we have flagged it for further
study.

On the subject of number of exchanged messages, we are currently working on
an update of the document with some call flows in it that show that MDCP
can use the minimum number of messages possible to setup a connection (one
of the gateway receives a call and two if it initiates it. I believe MGCP
can do that as well, right?

Paul
--
Paul Sijben              Telno:+ 31 35 687 4774 Fax:+31 35 687 5954
Lucent Technologies      Home telno: +31 33 4557522
Forward Looking Work      e-mail: [email-masked]
Huizen, The Netherlands  http://hzsgp68.nl.lucent.com/

---

From: [email-masked]
Date: Fri, 22 Oct 1999 11:14:20 -0400

I can even envisage multiple MGCs controlling a single physical MG (split into
multiple logical MGs), so long as the physical circuits in the MG were
statically distributed over the MGCs, and were only allowed to be controlled by
one MGC at any one time (with an exception for pooled resources such as
annoucement trunks). For ISUP trunks, this implies that the SG would need a
mapping table that allows it to distribute the SS7 ISUP traffic to the correct
MGC based on the CIC of incoming messages. I think this mechanism allows us to
>>disrupting the network (read without causing pain to the individual MGs).

However, I do not think that we can achieve the other objective from Michael
Ramalho:
>>MG to MGC pair from a particular manufacturer).

because to me, this would imply that the SG would need to broadcast the incoming
SS7 ISUP traffic to more than one MGC, and then the ISUP stacks running in the
MGC would need to cooperate with each other to say "I dont know how to service
this feature, why dont you service it". Even worse, if a feature request happens
mid call how does one ISUP stack and MGC relinquish control to another ISUP
stack/MGC.
Instead, this objective needs to be addressed by separating feature logic out of
the MGC, into some kind of service layer such as IN/AIN, JAIN/Parlay, scripting
etc.

Steve Carr
Unisphere Solutions Inc.

Hong Liu <[email-masked]> on 10/22/99 10:16:26 AM

Please respond to Hong Liu <[email-masked]>

To:   [email-masked]
cc:    (bcc: Steve Carr/Internet/ICN)
Subject:  Re: MGC-MG Control Relationship

Raja,

If this is what we mean by multiple MGCs controlling a single MG, I have no
problem with that at all. However, when I raised the question on the list, I
was under the impression that multiple MGCs are ACTIVELY controlling one MG
simultaneously. In other words, they are of equal roles in terms of control.
This raises questions as how share resources are managed, such as deadlock.

--Hong

"Neogi, Raja" wrote:

> Right from the beginning there was understanding
> that multiple MGCs may control an MG but not at
> the same time. There is only one primary MGC and
> multiple secondary MGCs. Look at the Fault management
> section of the latest draft.
>
> This enables "fault tolerance".
>
> raja neogi
> Intel
>
> From: Hong Liu [mailto:[email-masked]]
> Sent: Wednesday, October 20, 1999 10:01 PM
> To: [email-masked]

---

From: "Neogi, Raja" <[email-masked]>
Date: Fri, 22 Oct 1999 10:05:48 -0700

Yes, different logical MGs may have different MGCs controlling,
but allowing multiple MGCs to simultaneously control same instance
of logical MG will open up a host of conflicting issues.

Tracking the followup mails, looks like there is general agreement
on this subject

raja neogi
Intel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 22, 1999 8:14 AM
To: [email-masked]
Subject: Re: MGC-MG Control Relationship

I can even envisage multiple MGCs controlling a single physical MG (split
into
multiple logical MGs), so long as the physical circuits in the MG were
statically distributed over the MGCs, and were only allowed to be controlled
by
one MGC at any one time (with an exception for pooled resources such as
annoucement trunks). For ISUP trunks, this implies that the SG would need a
mapping table that allows it to distribute the SS7 ISUP traffic to the
correct
MGC based on the CIC of incoming messages. I think this mechanism allows us
to

>>MG to MGC pair from a particular manufacturer).

because to me, this would imply that the SG would need to broadcast the
incoming
SS7 ISUP traffic to more than one MGC, and then the ISUP stacks running in
the
MGC would need to cooperate with each other to say "I dont know how to
service
this feature, why dont you service it". Even worse, if a feature request
happens
mid call how does one ISUP stack and MGC relinquish control to another ISUP
stack/MGC.
Instead, this objective needs to be addressed by separating feature logic
out of
the MGC, into some kind of service layer such as IN/AIN, JAIN/Parlay,
scripting
etc.

Steve Carr
Unisphere Solutions Inc.

Raja,

--Hong

---

From: Brian Rosen <[email-masked]>
Date: Sun, 24 Oct 1999 16:05:19 -0400

At Red Bank, it was pointed out that it seems possible to implement a scheme
where an MG had multiple MGCs controlling it using techniques described in
the Virtual MG concept which is explicitly supported.  Such a system would
require some proprietary messaging between the MGCs.  The request was made
that
the protocol text not PRECLUDE such behavior.  We agreed it should be silent
on the matter.

Brian

> From: Danny Levin [mailto:[email-masked]]
> Sent: Thursday, October 21, 1999 6:08 PM
> To: [email-masked]
> See MEGACO requirement :
> 8.1.  MG-MGC Association Requirements
>
> The Protocol must:
>
> a.   Support the establishment of a control relationship
> between an MGC
>      and an MG.
>
> b.   Allow multiple MGCs to send control messages to an MG. Thus, the
>      protocol must allow control messages from multiple signalling
>      addresses to a single MG.
>
> Fault tolerance is not the only issue.
> What about sharing resources : one announcement player that
> serves multiple
> announcement controllers.
>
> Danny
>
>
> From:   Media Gateway Control (megaco)
> [mailto:[email-masked]] On Behalf Of Neogi, Raja
> Sent:   Thursday, October 21, 1999 1:38 PM