Subject: RE: about Inter-gatekeeper operation

From: Guocai Deng <[email-masked]>
Date: Fri, 25 Sep 1998 16:23:05 +0800

Jonathan Rosenberg wrote:
	> The location server is a logical element. In general, it will be
coresident with the gatekeeper.

	Why Location Server generally coresident with the Gatekeeper ? As i
know, there are many vendors empoly gatekeeper call-routed model. so there
may be too many calls to process for a gatekeeper so that it will not have
enough power to support a database and exchange info with other location
server. sure gateway and pc users are register them to gatekeeper, but it is
not mean that gatekeeper must to maintain the database itself. and if we
want to provide a backup or loadshare gatekeeper for the gatekeeper, another
location server need to coresident the backup gatekeeper again, and we
introduce overhead to sync the two location server. if the coresident of
Location Server and Gatekeeper does not make special value, why we don't
discussion seperately the action of  Gatekeeper and  Location Server, and
leave the consider if location server coresident with gatekeeper to
implementor case by case ?

	> > (2)A call may be not completed by two gatekeepers, so we need
some middle
	> > gatekeepers, otherwise, location server will store too much info
so commits
	> > bad performance, or location server may ask too many other
location server
	> > to got the target gatekeeper info. but gatekeeper can use static
or default
	> > route to gatekeeper to rapidly call.

	> The model we agreed upon at the last IETF does not restrict the
number
	> of location servers (again, generally co-resident with gk) to 2;
they
	> can be linked together in whatever means is desired by the
providers,
	> akin to how routers are linked in BGP. Also, in the model we
discussed,
	> the location server does not "ask" other location servers for
gateway
	> information at call setup. This information is propagated ahead of
time,
	> so that call setup is not delayed.

	Thanks for you clearing the issue. but, again i think that location
server is some way like router server, and  gatekeeper is some way like
switch. Who exchange or caculate route info about call do not must route
call. something especially for gatekeeper is that gatekeeper in charge of
process the registration request of  endpoints.  

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 25 Sep 1998 09:07:52 -0400

> implementor case by case ?

Sure, the decision can always be made to not have it co-resident. In
that case, you'll need some kind of protocol to communicate the database
back to the gatekeeper (which is not something we are currently
chartered to do). You avoid this by having them co-resident.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen
---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Douglas Clowes <[email-masked]>
Date: Mon, 28 Sep 1998 09:22:09 +1000

>chartered to do). You avoid this by having them co-resident.

You can avoid a lot more by keying your destination IP address in hex, but
that isn't necessarily productive :-)

I had thought that we (even you) had been discussing the Location Server as
a logically separate entity, with protocol(s) for Client and inter-Server
access. That approach does not preclude Location Servers being made
co-resident with gatekeepers (or gateways) at implementation, or even
having back-door connectivity within the (logical) box.

I don't think that we should embark with the presumption that they will be
co-resident. Therefore we do need a client protocol, for the location
server, that may be used by the gatekeeper.

The other, major issue that I see, is the presumption that you seem to
have, that we will have to "communicate the database back to the
gatekeeper", which I reject. I expect that a gatekeeper (or any other
SIP/H.323 entity) will simply be a client of the Location Server.

There is no reason why a gateway and gatekeeper cannot be co-resident, or
that these co-resident entities cannot use mechanisms or protocols outside
of H.323. But the presumption is that they will not be co-resident and
therefore there are protocols that may be used for communication between
them. This parallels the work being done to break up the logical gateway
and devise protocols that operate between the constituent parts.

I expect that there will be many gateways per gatekeeper, and many
gatekeepers per Location Server. The reason that I see multiple
gatekeepers, is that I expect gatekeepers being fully loaded just handling
gatekeeper functions, and many will be needed to carry the load of the many
gateways/endpoints that each controls. These heavily burdened gatekeepers
will not be able to also carry the load of being a Location Server as well.

While a Location Server *may* be co-resident with *a* gatekeeper, there
will be many gatekeepers which are *not* co-resident with any Location
Server. They will use the client access protocol on a per call basis,
rather than endeavouring to download the "database".

Indeed, the Location Server Client Access Protocol should be encapsulated
wrt how a Location Server does its job - i.e. whether it *has* the required
information, has to go and get it, ior just invents it as it goes along. It
should be independent, as far as possible, from whether the client is a PC,
black IP phone, gateway or gatekeeper (although SIP/H.323 independence
might be more of a problem).

To put it differently, I see the Location Server being co-resident with a
Back-End-Server that (logically) provides other services, such as
authentication, authorisation, usage-recording and call-accounting. Your
view may differ.

Regards,

Douglas

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 27 Sep 1998 23:54:01 -0400

Douglas Clowes wrote:

> having back-door connectivity within the (logical) box.

I'm not disagreeing. My statement was simply that I expected people to
implement them as co-resident, as this avoids the extra protocol. If
thats not what people end up doing, thats fine.

> server, that may be used by the gatekeeper.

Its not clear to me whether this is the same, or different, as the
protocol between an end user and a location server, the so called "front
end" we have discussed. I tend to think its different. In any case,
we're not currently chartered to do either. Lets get the main spec out
and then we can discuss if there is sufficient need for a protocol to
access the location server's information from a gatekeeper or other
element.

> might be more of a problem).

As I mentioned, its not clear its the same problem, but we should have
this discussion later. One thing at a time..

-Jonathan R.