[H.323 Mobility:] Comments on APC-1932

Jaakko Sundquist jaakko.sundquist at NOKIA.COM
Fri Aug 18 08:53:05 EDT 2000


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?

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

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.

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

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.

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



More information about the sg16-avd mailing list