[H.323 Mobility:] APC-1902 - contribution from Intel

[Reddy, Paul K]

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 at nokia.com]
Sent: Friday, August 18, 2000 8:53 AM
To: ITU-SG16 at 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 at nokia.com *
------------------------------------------------

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

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