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

Kumar, Vineet vineet.kumar at INTEL.COM
Fri Apr 14 14:07:48 EDT 2000


Radhika,

I must admit that I am slow in understanding the concepts behind the user having an option to pick either the network address of the "home administrative domain" or the "visited administrative domain". Since we are working on the all IP scenario, I will restrict our discussion to that. Could you be talking about the static and dynamic IP addresses ?

vineet
-----Original Message-----
From: Roy, Radhika R, ALARC [mailto:rrroy at att.com]
Sent: Friday, April 14, 2000 9:55 AM
To: Kumar, Vineet
Cc: 'ITU-SG16 at MAILBAG.INTEL.COM'
Subject: RE: [H.323 Mobility:] questions on MTD-016


Hi, Vineet:

I guess that we are in agreement.

I have just elaborate the justification of keeping the "home network
address" (as opposed to "home network") in addition to the home
administrative domain.

Please see my answer below.

Best regards,
Radhika

-----Original Message-----
From: Kumar, Vineet [mailto:vineet.kumar at intel.com]
Sent: Thursday, April 13, 2000 7:58 PM
To: Roy, Radhika R, ALARC
Cc: 'ITU-SG16 at MAILBAG.INTEL.COM'
Subject: RE: [H.323 Mobility:] questions on MTD-016



Radhika,

I have two comments which are embedded in your email below.

vineet
-----Original Message-----
From: Roy, Radhika R, ALARC [mailto:rrroy at ATT.COM]
Sent: Thursday, April 13, 2000 2:03 PM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: [H.323 Mobility:] questions on MTD-016


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).

<vineet:begin> I would agree that there should not be any such assumption. I
don't believe anyone is making such an assumption.
<vineet:end>

<Radhika: begin> If it is, we are in full agreement. This will make the
protocol flexible. The protocol itself and the mobility management
information flows will reveal the fact whether we are complying with this
requirement or not. We will examine our contributions in the light of this
requirement.
<Radhika: end>

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.

<vineet:begin> Can you please elaborate on the above statement, especially
on "declare a network address as its home
network".
Also, I am not sure about the value of using a term like "home network"
instead of "home administrative domain". The term "home administrative
domain" is already defined in H.323 Annex H and is understood by all
participants ?
<vineet:end>

<Radhika: begin> As I explained in my earlier mail what the terms "network"
and "network address" mean in the context of H.323. An H.323 entity in a
network does NOT mean anything unless it is associated with a network
address.  So, the main idea behind this is: A user may have the OPTION to
choose to have its "home network address." A valid question is: Why does a
user want to do this? I would point to mobile IP. There can be a lot of
benefits from the mobile user's point of view. A mobile user may like to
keep the "foreign network address" "HIDE" while he/she moves from one place
to another. It is an OPTION, not mandatory.

If needed, people may like to implement the entire mobile IP solution at the
network layer while using the H.323 mobility solution in the application
layer. These two solutions will complement each other.

In addition, we like to use the term "home administrative domain."

Both "home network address" and "home administrative domain" are required.
<Radhika: end>



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



More information about the sg16-avd mailing list