Re: Should we Break H.323 Model for Mobility?
Hi, Steve:
Excellent!
HLF/VLF:
Definitely, I agree that we need to clarify the roles of HLF, VLF, and GKs very clearly because this is the heart of the mobility solution. I guess that we have identified the functions of HLF and VLF. In my contributions, I have explained as follows:
1. Intra-domain: Populate the HLF database through registration [not statically, but dynamically] (although the HLF may not be needed to be used for mobility management). Call flows show how HLF is used.
I left the VLF function untouched. However, VLF can be used, if needed, for managing the change in network point of attachments.
2. Intra-Domain/Inter-Domain: Both HLF and VLF are needed. Some call flows are there to explain the role of these entities.
You are right that we may have to explain more about HLF and VLF.
Is it possible to explain more via short contributions or emails so that we all can agree with you arguments?
GK Discovery:
A note to Laurent Thiebaut/Nicolas Tran: I understand from the conference call, you might be another efficient mechanism to discover the GK using the DNS method (I hope that the process would be dynamic). Can you please send us a contribution related to this so that we can compare between H.323's GRQ/GCF/GRJ, proposed (mine) MGA, and your proposed DNS method?
I have provided explanation via contributions, emails, and conference call why MGA is better than GRQ/GCF/GRJ. We like to see your proposed method. Please note that we may make these three as a part of the H.323 standard. Let people implement whatever mechanism best for them.
Best regards, Radhika R. Roy AT&T
-----Original Message----- From: Stephen Terrill [SMTP:stephen.terrill@ericsson.com] Sent: Monday, April 17, 2000 1:01 PM To: Roy, Radhika R, ALARC Cc: ITU-SG16@mailbag.cps.intel.com Subject: Re: Should we Break H.323 Model for Mobility?
Hi Rardhika,
I agree that we need to register with the gatekeeper, however I extend that to say, the gatekeeper could be at home.
I think that we need to clarify the roles of the HLF, VLF, GKs etc before we can move further forward.
Regards,
..//steve
"Roy, Radhika R, ALARC" wrote:
Hi, Steve:
Your statement appears that you are agreeing with the registration with
the
GK that is the basic foundation of H.323. (However, your contribution
does
NOT clearly indicate this.) It is a very good news.
Contributions are there what roles to be performed by the VLF, HLF, and home/visiting/visited/target GK/zone/domain. We like to see where you
differ
and why, and your suggestions.
Please also see my subsequent emails what we need to be done to extend
our
model to be consistent with H.323 as well as how we can reconcile all contributions: AT&T, Alcatel, and Ericsson.
Best regards, Radhika R. Roy AT&T
-----Original Message----- From: Stephen Terrill [mailto:stephen.terrill@ericsson.com] Sent: Sunday, April 16, 2000 5:00 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Should we Break H.323 Model for Mobility?
Hi Roy,
I feel that this email places more assumptions into the role of the VLF, HLF, visited GK, and home GK than we have agreed upon. Certainly the
model
that we have proposed hasn´t stopped registration with the gatekeeper.
I think that we need to agree upon the roles of the particular entities befor embarking upon concluding that something breaks the H.323 model.
Regards,
..//steve
"Roy, Radhika R, ALARC" wrote:
Hi, Everyone:
H.323 has some definite architectural notion such as terminal, GK, GW,
MCU
and(MC, MP). One of the fundamental corner stones is the GK. The H.323 entities (e.g., terminals, GWs) register with the GK. A GK manages a
zone
with the information of all registered users along with other
functions
(e.g., bandwidth, resource management, etc).
The "registration" with the GK is the fundamental corner stone of
H.323
where an association is made by each user. That is, a GK becomes the
basic
source to have the information related to each user.
H.323 mobility protocol MUST also follow the same H.323 architectural concept. If this basic notion is not maintained, it breaks the basic foundation of H.323.
It appears that H.323 mobility likes to define additional databases
like
VLFs and HLFs that will store the information related to the mobile
users.
These databases are supposed to help the function of a GK in order to
manage
the mobility related information.
If people think that an H.323 will be able to register with a VLF
directly,
does it not mean we are by-passing the basic foundation of H.323
model?
Does
it not opening the entirely a new set of problems in H.323? It will
create
a
parallel architecture like GK in H.323 what is not needed at all
because
solutions have provided that are consistent with H.323 model and there
is
no
need to do this. We probably have to do all over again what we have
done
for
the GKs and BEs. We inviting unnecessary problems that are yet to
imagine
where we may end up with. Why do we need to do that if one can do this
using
the consistent H.323 model of GK?
In another situation, we have to go step-by-step. First intra-zone,
then
inter-zone, and last of all inter-domain. Contributions are there to
address
those problems.
The mobile users that move between cells, those cells are expected
primarily
remain the control of a given GK (in some cases it may be two GKs).
These
scenarios mostly seem to be intra-zone and inter-zone and may involve
a
single service provider. Of course, there will also be the calls
between
the
two adm domains of two service providers.
More importantly, solutions are inter-dependent. That is, we cannot
address
the problems of inter-zone without knowing the intra-zone. In the same token, we cannot address the inter-domain problems without knowing the inter-zone problem. Contributions are there. Let us proceed
accordingly.
Last of all, I am reminding the mess that we have made in Annex G. Now people are hungry to use the more powerful and efficient Annex G
messages
between the GKs. Contributions were brought to do this, but the
proposals
had been rejected by a very few. Who is suffering?
Best regards, Radhika R. Roy AT&T
participants (1)
-
Roy, Radhika R, ALARC