H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6

[Jaakko Sundquist]

Mr. Roy & other parties interested in H.323 Annex H,

I found your posting addressing such general level issues that I think it is
better to write a whole new mail as a response instead of responding to your
claims and comments point by point...

First of all you question the mandate of Annex H and its relation to the
H.323 protocols. I find it very odd that you, without any real arguments to
support for it, restrict the H.323 recommendations and thus also Annex H to
handle ONLY the H.323 entities that have been defined prior to Annex H. The
first real work that we got done for Annex H was to identify the
functionalities that were (are) needed for Mobility Management and that were
missing from H.323. This is how we (in an ad hoc meeting in Red Bank, in
which you yourself was also present) came up with the four new H.323
(functional) entities: HLF, VLF, AuF and IWF. Thus we have defined NEW H.323
entities that were NOT present prior to Annex H. If it is illegal for us to
define new H.323 entities (as you seem to claim), I can't see how the Border
Element ever got defined, since it was not defined prior to the H.225 Annex
G.

Second, you seem to have defined the HLF, VLF and AuF as back-end services.
This is NOT how I see them. I see back-end services as services that are NOT
defined in the H.323 series recommendations, but that may be used by
gatekeepers. In other words, back-end services or the functionalities they
provide do NOT have any real definition in H.323, nor is it illegal to
define new entities to H.323 that provide same kind of functionalities that
could be achieved by using some back-end service. The back-end services that
are used in some implementations of the H.323 system can undoubtedly be used
for similar purposes as the new functional entities of Annex H are, but this
does not make the new entities back-end services. Furthermore, the whole
point (or mandate) of Annex H is to make recommendations that allow for
different manufacturer's equipment to be used in different parts of the
(mobility enhanced) H.323 system and still allow the users/terminals to move
around in the network. Thus, in my opinion, it is one of the most important
issues of Annex H to define, how the HLF, VLF and AuF communicate with each
other. By just stating that they are back-end services we would in essence
NOT define this, since back-end services are NOT defined in H.323.

Third, the protocol(s) that are used between the HLF, VLF and AuF are still
and open issue. The reason, why the H.225 Annex G protocol is used in the
present draft is that it is the only protocol that has been seriously
mentioned for this purpose. (Not only by the editor, but in various
contributions as well, although the editor takes full responsibility of the
current text in the draft.) It has been identified that the H.225 Annex H
protocol already has the functionality for locating a User with a certain
aliasAddress. Really roughly said, this functionality is "half" of the
functionality that is needed for Mobility Management, the other half being
the location updating procedures (which are not really addressed by the
protocol yet). This is why the protocol is being considered for the Annex H
usage. However, I would really like to see contributions suggesting other
(preferably existing) protocols as well. Intel's contribution APC-1902, was
the first one of this kind. These contributions should, however, state
clearly how the suggested protocols should be used, if there is any
ambiguity. I.e. just stating: "Use Mobile IP" is not enough (I'm not trying
to refer to the APC-1902 with this comment), but information flows for the
needed Mobility Management procedures should be presented (these include at
least the location updating procedures, call establishment procedures, call
termination procedures and unregistration procedures).

Fourth, the needed enhancements of the RAS, Q.931, etc. protocols will be
provided by finishing the information flows on chapter 10. I admit that not
much of this has yet been done, but on the other hand, at least so far I
have found that there is not too much that has to be done with respect to
these protocols. (There will probably be certain message fields that will be
mandatory for Mobile Terminals that are optional in H.323 normally, etc.,
but I don't see a need for too many new message fields or messages.)

Last, but not least, we a really in a hurry, if we want to get the Annex H
determined in November. This is why I suggest that the interested parties
provide the contributions describing the usage of other protocols as the
Mobility Management protocols of Annex H as soon as possible. Also it would
be very nice, if these contributions were made modeling the chapter 10 of
the current draft, so that incorporating them to the annex would be as fast
as possible.

I'm still a bit in the middle of the process of digesting the information I
have gotten about the Annex H work in Portland, but I'll try to send a mail
summarizing (what I think is) our current situation later this week
(probably on Friday). I will also make a "cleaner" version of the TD-42a as
the "starting point" for our interim work before Geneva (this new draft will
not contain any other than editorial changes compared to TD-42a).

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