[H.323 Mobility:] questions on MTD-016

[Roy, Radhika R, ALARC]

Hi, Steve:

I guess that you did not get my point exactly. It is NOT exactly where the
"service" to be executed. It is user's choice whether certain things to
could be perfumed as their choices (for example not to reveal addresses
while NOT moving - for example mobile IP permits) etc.

Now where the service to be permitted, we may have another debate. There
should be flexibility: Home Domain vs Foreign Domain and other criteria.

As I explained earlier, what is meant by network in H.323. Please see the
email sent in response to Jaakko's.

I would be pleases to explain in terms of home/foreign
(visiting/visited/target) domain/zone/network address.

For the role of the GK in H.323 is clear. There is no ambiguity. Please see
my email that will be sent very shortly.

Please also see email that will be shortly how we can reconcile all
contributions together describing the role of GKs, HLFs, and VLFs: AT&T,
Alcatel and yours (Ericsson).

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Stephen Terrill [mailto:stephen.terrill at ericsson.com]
Sent: Sunday, April 16, 2000 5:11 AM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: [H.323 Mobility:] questions on MTD-016


Hi Roy,

I still don´t understand why it is a "users" choice where the "services" are
executed - I would have thought that this would be networks choice - and the
means for doing that is what we are now discussing.  Can you please clarify
why a user "MAY" which to decieded this.

One thing that is now clear is that there are different expectations of the
roles of the gatekeepers, VLFs, HLFs etc expressed amongst the participants
of the list - and this has to be clarified.

Regards,

..//steve

"Roy, Radhika R, ALARC" wrote:

> Hi, Steve:
>
> In H.323, GKs are the communication entities thorough which registration
and
> other services are obtained by users while VLFs and HLFs are used ad
> databases to store the information that are appropriate related to the
> mobility management.
>
> In H.323, a user is always associated with a GK through registration, and
a
> GK manages a zone where all its H.323 registered users reside. In
addition,
> a GK also manages resources of the zone.
>
> Please also see the mobility management information flows in AT&T
> contributions MD-017 and MD-018 how the GK is involved to resolve
> information via VLF and HLF.
>
> A mobile user MAY like to differentiate between a home GK and a foreign GK
> (security and many other reasons). It is an OPTION, not mandatory.
>
> Hope this clarifies your questions.
>
> Best regards,
> Radhika
>
> -----Original Message-----
> From: Stephen Terrill [mailto:stephen.terrill at ERICSSON.COM]
> Sent: Friday, April 14, 2000 8:02 AM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: [H.323 Mobility:] questions on MTD-016
>
> Hi Roy,
>
> Can you please clarify why the gatekeeper selected for the services is a
> "user" issue?
>
> Regards,
>
> ..//steve
>
> "Roy, Radhika R, ALARC" wrote:
>
> > Hi, Vineet and Steve:
> >
> > I like to add couple of points with respects to your emails as follows:
> >
> > HLF:
> >
> > It is interesting to note that there appears to be an "implicit"
> assumption
> > that there is only one HLF in a domain (no matter what happens in the
> > future).
> >
> > Let us NOT make our protocol "hard-wired" like this.
> >
> > The protocol should be flexible enough to accommodate one or multiple
HLFs
> > in a domain.
> >
> > If one wants to choose one HLF per domain, it MUST be left as an
> > implementation issue, NOT a protocol issue.
> >
> > Home GK:
> >
> > In the same token, if one wants to declare a GK as its home GK, this
> option
> > MUST be provided to a user. It is a choice that MUST be given to a user.
> If
> > anyone does NOT like this option, they MAY not use it.
> >
> > Home Network/Network Address:
> >
> > In the same token, if anyone wants to declare a network address as its
> home
> > network, this option MUST also be provided.
> >
> > GK Discovery:
> >
> > The "old" inefficient GRQ discovery mechanisms may not be the only
OPTION
> to
> > discover the GK. in a highly mobile cellular environment. An alternative
> > mechanism, like MGA message can be listened to discover the GK as well.
> >
> > Best regards,
> > Radhika R. Roy
> >
> > > -----Original Message-----
> > > From: Kumar, Vineet [SMTP:vineet.kumar at INTEL.COM]
> > > Sent: Thursday, April 13, 2000 4:34 PM
> > > To:   ITU-SG16 at MAILBAG.INTEL.COM
> > > Subject:      Re: [H.323 Mobility:] questions on MTD-016
> > >
> > > Steve,
> > >
> > > Thanks for your reply. My comments are embedded in the email below.
> > >
> > > vineet
> > >
> > > -----Original Message-----
> > > From: Stephen Terrill [mailto:stephen.terrill at ERICSSON.COM]
> > > Sent: Thursday, April 13, 2000 4:42 AM
> > > To: ITU-SG16 at MAILBAG.INTEL.COM
> > > Subject: Re: [H.323 Mobility:] questions on MTD-016
> > >
> > >
> > > Hi,
> > >
> > > I shall try to answer some of these questions below.
> > >
> > > Regards,
> > >
> > > ..//steve
> > >
> > >
> > >
> > > "Kumar, Vineet" wrote:
> > >
> > > > Stephen,
> > > >
> > > > I have a couple of questions on your contribution MTD-016. These
are:
> > > >
> > > > 1. H.323 already has mechanisms for discovering the gatekeeper. Are
> you
> > > suggesting in your contribution that the terminal should discover the
> VLF
> > > instead of the visiting gatekeeper ? Or, are you assuming that the VLF
> is
> > > integrated in the visiting gatekeeper ?
> > >
> > > This can be discussed - I was of the opionion that we should discover
> the
> > > VLF and send the registration to the home environment after that.
> > > However,
> > > we haven´t agreed on the role of the VLF, and visited gatekeeper, home
> > > gatekeerp and HLF - when we come to agree on what these are, my
proposal
> > > may
> > > change.
> > >
> > > <vineet:begin> Yes, this could be discussed in the conference call. My
> > > suggestion is to reinvent as less as possible. Since we are adding
> > > Mobility
> > > to H.323, we should just fill in the gaps that are missing.
> > > <vineet:end>
> > > >
> > > >
> > > > 2. In H.323, authentication of the terminal and the gatekeeper is
done
> > > at
> > > the time of discovery. In fact, in H.323 all messages between the
> terminal
> > > and the gatekeeper can be authenticated and the message integrity
> > > preserved.
> > > In your contribution, authentication is done at the time of
> registration.
> > > Why is this preferable to what is already in H.323 ?
> > >
> > > I would be interested to understand which gatekeeper you were
> considering
> > > should do the authentication.  I would assume that the real
> authentication
> > > would have to be done at home - as such it would be necessary to find
> the
> > > visited network services, and then register/authenticate at home.
> > >
> > > <vineet:begin> I agree with your model but my preference is to
preserve
> > > the
> > > way H.323 works today in that the authentication of both the user (not
> > > terminal) and the gatekeeper (doesn't matter whether the gk is
visisted
> or
> > > home) can be done at the time of discovery. The protocol between the
> > > terminal and the gk does not change regardless of whether it is the
home
> > > gk
> > > or the visited gk. The terminal sends its hashed password or
certificate
> > > in
> > > the cryptotoken field of the GRQ message. The visisted gk tunnels the
> > > entire
> > > message to the terminal's Home Administrative Domain for
authentication
> > > and
> > > authorization. There may be an Authentication Function in the Home
> > > Administrative Domain that authenticates its users. If the user is
> > > successfully authenticated by the Home Administrative Domain then a
new
> > > temporary password is assigned by the Home Administrative Domain to
the
> > > terminal and the visited gk in GCF for use during that session. This
> > > exchange is explained in detail in the contribution I made for the
last
> > > conference call. I can't find the MD #. Does anyone know the MD # ?
> > > <vineet:end>
> > > >
> > > >
> > > > 3. What is the reason for the information flow from the HLF to the
> home
> > > gatekeeper, and from the home gatekeeperr to the HLF ? I don't think
we
> > > can
> > > assume that there is only one home gatekeeper that the terminal may be
> > > using. In fact, the home gatekeeper may not have any information about
> the
> > > user.
> > >
> > > I certainly don´t assume that there is only one home gatekeeper.  I
> assume
> > > that there will be a number of home gatekeepers, but perhaps only one
> (or
> > > few) HLFs.  In this case, we need an function to select the gatekeeper
> > > that
> > > the user is going to camp on - and this may depend on load, subscriber
> > > profile, policy - or a lot of things.
> > >
> > > <vineet:begin> I guess I will have to understand the model that you
have
> > > in
> > > mind regarding the use of a home gk on which the terminal camps on. In
> my
> > > model the HLF will send all pertinent information about its user to
the
> > > VLF.
> > > The home gk is not needed.
> > > <vineet:end>
> > > >
> > > >
> > > > Regards,
> > > > vineet