Hi, Vineet:

I hope that you are right.

The fundamental issue is: Does that HLF of the home administrative domain is priori known to the visiting/visited administrative domain?

If it is priori known, then people can directly access to it and no mechanism would be placed in the protocol to find that HLF. We call it static mode.

If it is not known, the mechanism in the protocol would be there to find that HLF dynamically. We call it dynamic mode.

It is very critical to understand how a simple assumption changes the protocol fundamentally.

Hope this will clarify.

Best regards, Radhika

-----Original Message----- From: Kumar, Vineet [mailto:vineet.kumar@INTEL.COM] Sent: Friday, April 14, 2000 2:23 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] questions on MTD-016

Seems to me that we are saying the same thing but in a different way: There may be one or more HLF entities in the Home Administrative Domain but from the Visited Administrative Domain's point-of-view there is one HLF entity.

We have beaten this horse to death, so, I hope, we can move on to other issues.

vineet

-----Original Message----- From: Gösta Linder (LME) [mailto:Gosta.Linder@LME.ERICSSON.SE] Sent: Friday, April 14, 2000 12:02 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] questions on MTD-016

Hi, comment on single or multiple HLFs; To be able to define protocol relates HLF we have to have a common understanding of the HLF role versus served/visited networks.

In H323 Annex H we have the following related definitions; - on HLF; "This functional entity is a database in charge of the management of mobile subscribers. A H.323 Domain may contain one or several HLFs: it depends on the number of mobile subscribers, on the capacity of the equipment and on the organisation of the network." - on VLF; "The VLF contains also the information needed to handle the calls initiated or received by the H.323 MTs registered in its data base (for some supplementary services the VLF may have to obtain additional information from the HLF) the following elements are included: ...."

I would then add that principles for adding HLF entities at the Home admin domain (for capacity or redundancy or any other reason) should be totally transparent to the served/visited domains and subject for Home Domain to reorganise his network according his own needs without reflecting any needs to reconfigure served/visited domain behaviour nor any data of the external domains.

This means that seen from served/visited domains there is just one HLF entity (clustered or not) to communicate with.

I would welcome a discussion to have a common understanding of the principles to be used according to above, to be able to understand needed call flows and related messages.

Reagards /Gösta Linder

-----Original Message----- From: Kumar, Vineet [mailto:vineet.kumar@INTEL.COM] Sent: den 14 april 2000 01:58 To: ITU-SG16@mailbag.cps.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@ATT.COM] Sent: Thursday, April 13, 2000 2:03 PM To: ITU-SG16@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

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

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@INTEL.COM] Sent: Thursday, April 13, 2000 4:34 PM To: ITU-SG16@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@ERICSSON.COM] Sent: Thursday, April 13, 2000 4:42 AM To: ITU-SG16@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