Hi, Jaakko and all:

Let me explain some fundamental aspects of H.323 protocol.

The way the H.323 protocol works is as follows:

1. Communications among the GKs (or BEs) for resolving addresses

If a terminal wants to place a call and it does not know the address of the called party, it simply sends the query to the GK. If the said GK does not have the answer, it simply contacts the other GK to resolve the address. When a GK knows the answer, it sends the answer back to the originating GK, and then the originating GK sends the reply back to the terminal.

Please note that H.323 does NOT answer the question how a GK will contact another GK for resolving the address of the called party. There is no standard mechanism how the GK-to-GK communications are made for resolving the problem.

The same is also true for the BE-to-BE communication for the inter-domain communications.

In the same token, we also defining the same process in mobile environment.

2. Efficiency of the LRQ messages

We know that LRQ messages are not very efficient. That is why we created H.225.0 Annex G (inter-domain) message sets that are more efficient than the LRQ.

One of the proposal has been to use those H.225.0 Annex G message sets for the intra-domain communications instead of LRQs. However, this proposal is yet to be accepted.

So, we can discuss what are the probable solutions can be: 1. Augment LRQs for intra-domain 2. Augment Annex G for inter domain (if needed this can also be used for intra-domain), and/or 3. Create new messages for intra/inter-domain.

3. VLF and HLF communications across the domain (i.e., inter-domain)

Yes, this violates the fundamental protocol architecture of H.225.0 Annex G. Please note that Annex G message sets basically provide the address resolution across the administrative domains if the address of the called party is not known in any given domain. The way this works as follows: If a terminal dos not know an address of the called party, it contacts its GK. The GK then contacts the BE (or another GK) if it thinks that answer is not known in this domain. The BE then contacts the another BE of another domain for resolving the address, and then the reply comes back following the reverse path.

Again, the H.323 standard does NOT specify how a GK or BE knows which GK or BE needs to be contacted for resolving the information. It simply defines the protocol, nothing else.

If the VLFs and HLFs are allowed to by-pass the BEs, then we do NOT need the H.225.0 Annex G BE-to-BE communications protocol at all. This VLF <-> HLF communication becomes another parallel protocol set that can do the same job what Annex G protocol is doing.

(By the way, an interesting thing is that if there are many VLFs and HLFs, we may have same problems: How does a VLF knows which HLF needs to contact unless one "hard-wired" in the protocol that there is only "one" HLF, or the address of the HLF is "priori" known?)

We have proposals how we can address the mobility problem using the H.225.0 Annex G protocol that uses only the BEs for the inter-domain communications.

3. New terminologies

We can talk about this. We may strike the balance in the context of the IP world. For example, 3GPP is using the mobile IP. In this context, home and foreign (visiting [serving]/visited) are used. "Visited" can be currently visited, previous visited, etc. (The terms like "old" and "new" in the classical world of cellular mobility and we may avoid this.)

In addition to the above, please also see my reply embedded below [RRR].

I appreciate your response. We will also talk more in the Portland conference. We will miss you.

Best regards, Radhika R. Roy AT&T

-----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Friday, August 18, 2000 8:53 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: [H.323 Mobility:] Comments on APC-1932

Hi Radhika & the rest of you mob people,

Since I'm not coming to Portland, I'll send you my comments on APC-1932 here. You can discuss these issues further with Mr. Rissanen in Portland.

** Comments on chapter 2 of APC-1932 **

The LRQ mechanism will, of course still work, but I think that for a true global mobile system, the mechanism is VERY inefficient and thus a better way of locating the called user must be standardized. I.e. generally a GK has no way of knowing under which GK (or set of GKs) the called user is located and thus in order for the LRQ mechanism to work, the LRQ must be sent to all GKs in a domain. The domains may include many GKs, thus the LRQs would create very much traffic also adding one GK to the domain would necessitate all the other GKs to be informed in order for the LRQ mechanism to work. Furthermore the originating GK does not even know whether the user is located in the same domain, thus the GK would have to wait an arbitrarily long time for an LCF and if the LCF does not arrive, inter-domain communications would be needed -> how long should this time be? [RRR] Please see my reply provided above in items 1 and 2. We will only define the protocol, and will NOT address the implementation issues.

I really do not see, how the VLF <-> HLF communications across domain boundaries BREAKS the H.323 model. The H.225 Annex G states that "all inter-domain communications are executed via border elements" (not an exact quotation), but we can either change that statement into "all inter-domain communications must be executed by using the H.225 Annex G protocol" and use the protocol between VLFs and HLFs or we can say that the VLF and the HLF must always be co-located with a BE (to create elements HLF/BE and VLF/BE). [RRR] Please see my reply provided above items 1 and 2. No, we do not need to perform inter-domain VLF and HLF communications. Proposals are there how we can use only the BEs for the inter-domain communications for solving the mobility problems as specified in H.225.0 Annex G. (By the way, those who know why Annex G has been developed using the BEs as the ONLY legitimate entities for the inter-domain communications, they will not raise this issue at all.)

As for the question about the "distributed" vs. "hierarchical" model. Again, the VLF, HLF and AuF are just FUNCTIONALITIES, i.e. you can co-locate them with each other or with a GK or a BE. Thus, if you want your GK to be able to directly communicate with a HLF, you can add the VLF functionality to that network element thus creating a GK/VLF (or perhaps a GK/VLF/BE), which can communicate with the HLF. Thus the current H.323 Annex H architectural model does not stop you from utilizing either the "distributed" or the "hierarchical" model. [RRR] No, picture clearly shows that VLF and HLF and other communications scenarios. As I told before, we are NOT considering the VLF and HLF communications per se because there are NOT considered as a part of H.323 protocol. This is called the backend server to the backend server protocol. We will only concentrate for the GK/BE <-> VLF, GK/BE <-> HLF, and GK/BE <-> AuF protocol from the H.323 point of view. (By the way, there are many candidate protocols for the VLF <-> HLF and HLF <-> HLF protocol, and other questions and SGs may also be involved for this.)

These comments apply on some parts of the chapter 3 also.

** Section 2.1 **

I do not understand this at all. We are producing an enhanchement to the H.323 protocols and in doing this, we have identified new functional elements that are not present in the H.323 standards beforehand. So, the interfaces may not have been a part of the H.323 standards before, but after Annex H is done they will be. As for the specific interfaces, I don't think we need to specify the HLF-HLF interface (in fact, the interface is not even present in the architecture diagram) and my opinion is that we can leave the AuF-HLF and especially the AuF-VLF interface unspecified in the first version of the annex (thus assuming that the AuF is co-located with the HLF). [RRR] Please see my answers for Section 2 as stated above. If there are more than one HLFs, as agreed, then HLF <-> HLF also needs to be defined because we NOT considering that our protocol only the centralized architecture. So, We will only concentrate for the GK/BE <-> VLF, GK/BE <-> HLF, and GK/BE <-> AuF protocol from the H.323 point of view.

I have proposed to use the H.225 Annex G protocol in these interfaces, but there can, of course, be other options as well and I would really love to see contributions utilizing other mechanisms, such as the IETF's AAA, etc. My opinion is, however, that we must select and standardize the use of some specific protocol to really enable interworking between different manufacturer's products. [RRR] No, we do not need to do so. Please see my replies above.

These comments apply on some parts of the chapter 3 also.

** Section 2.2 **

I think we have a linguistic misunderstanding here. I would like, if some native English speaker would comment this, but I understand the terms in the following way:

- Visited Domain, etc. should be read: "the domain currently being visited by the user". I think that this kind of interpretation is commonly used in technical language (or am I totally wrong?). - Visiting Domain would sound to me like: "the domain is visiting somewhere". - Serving Domain is OK, and is already used in Annex H. - Target Domain is OK. In the present draft I have used "new Domain" instead of "target Domain". Target and source are words that are commonly used for the new and old domain, etc. (E.g. in GSM handovers, the terms "source BTS" and "target BTS" are used. If using the words "new" and "old" is confusing or misleading, I ahve nothing against using target and source. [RRR] We may need to work together. Please see my suggestions provided in item 3.

These comments apply on some parts of the chapter 3 also.

** Chapter 3 **

Most of my comments on this chapter are already captured in the above comments for chapter 2.

A few short notes on the other issues: - You're right, the security check for unregistration is definitely needed. - Also Connection Termination needs to be handled, although I imagine that there is nothing really special about it compared to the "normal" H.323 system (that is why it isn't included in the present draft), unless supplementary services (and perhaps some billing issues) are taken into account.

Those are my comments, I will discuss the issues with Mr. Rissanen so that you can have a meaningful discussion about them in Portland. Have a nice meeting everyone!

***

Finally, just to annoy the editor of H.323 Annex K: Ice-hockey isn't enough for us Finns anymore, now we are beating you in football (socker) also... Finland - Norway 3-1!!!!

------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist@nokia.com * ------------------------------------------------

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com