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

7 Sep 2000

      Hi Radhika,
We as ITU-T SG16 Q13/Q14 group agreed on the H.323 Annex H Terms of
Reference, which includes scope of H.323 Annex H. Now, you are proposing a
different scope for H.323 Annex H on this reflector.
I propose that we plan to have H.323 Mobility Adhoc group conference call
discussion on your proposal instead of exchanging emails on this open
reflector and come to some consensus on your proposal and then take a
contribution to SG16 Q13/Q14 Rapporteurs meeting in Geneva. We as H.323
Mobility Adhoc group choose Mr. Markku Korpi as Chairman of the Adhoc group,
I request  Mr. Korpi to setup a conference call to discuss your proposal.
I am willing to sponsor the Conference Call Bridge, I propose that we can
have conference call on Monday September 11, 2000 from 7:00 AM to 9:00 AM
(Pacific Standard Time). Please let me know your availability all other
members who wants to participate, so that I can make the Conference call
bridge arrangements.
regards,
Paul
Paul K. Reddy
Intel Corporation
Office Phone# +1 (503)-264-9896
Mobile Phone# +1 (503)-807-9564
Email: paul.k.reddy@intel.com
-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com]
Sent: Thursday, September 07, 2000 7:38 AM
To: ITU-SG16@mailbag.cps.intel.com
Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of
Q. 13/1 6
Hi, Everyone (including all Rapporteurs and WP2 Chairman):
Again, it speaks for itself as it has been mentioned earlier.
As if, few folks want to create their own charter, push the boundaries of
each question so that they are the ONLY people who can decide what need to
be addressed in each question no matter what happens to other questions in a
given WP or SG or across the whole ITU-T.
They are the people who are afraid of seeing the BIG picture of the ITU-T
how one question relates to others to achieve a very narrow goal. Some of
these people even participated in the joint meeting of SG16 and SG11 to see
how SG11 is addressing the HLF, VLF, AuF, etc. for mobility so that no
duplicate work is done elsewhere. Now they are turning their back. Why?
Is the norm of the ITU process?
It appears that some people do not need address any technical points, as if,
they create their own mandate.
It may create a good discussion in the upcoming SG16 meeting in the plenary
and general session.
Again, the proposal for H.323 Annex H has been repeated as follows:
1. First, finish the extension of the existing H.323 base specs, and H.225.0
(RAS, Q.931, Annex G)to support mobility among the H.323 entities:
Terminals, GKs, BEs, and GWs. (see the contributions that are being made so
far).
2. Second, develop a clear mandate whether the backend protocols like VLF
<-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of Q.13/16 only, or
these protocols need to be worked with other SGs. (see the contributions
that are being made so far).
3. Third, any protocols that re being used between VLF <-> HLF, VLF <-> AuF,
HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or its extension
because these are separate protocols and serve completely different purposes
although may useful properties (e.g., hopcount, etc.) of the Annex G
protocol can be used for these protocols.
Let us focus on the charter and mandate of Q.13/16: This is item 1 only.
Hope that the WP2 Chairman will have time to review the whole thing with
true satisfaction in the light of all questions of all SGs within the ITU.
Best regards,
Radhika R. Roy
AT&T
rrroy@att.com
+1 732 420 1580
-----Original Message-----
From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com]
Sent: Thursday, September 07, 2000 5:11 AM
To: ITU-SG16@MAILBAG.INTEL.COM
Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of
Q. 13/1 6
I guess you mean that you agree with all 4 points, not just the fourth
point, right (i.e. I guess there's a typo)?
-Jaakko
p.s. I didn't want to send this to the list...
...
-----Original Message-----
From: EXT Reddy, Paul K [mailto:paul.k.reddy@INTEL.COM]
Sent: 07. September 2000 1:41
To: ITU-SG16@mailbag.cps.intel.com
Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier -
Mandate of
Q. 13/1 6
Hi Everyone,
I agree with Mr. Jaakko Sundquist, Editor of H.323 Annex H,
who made 4 point in this email.
regards,
Paul Reddy
Editor of H.246 Annex E.1, Annex E.2
Paul K. Reddy
Roaming Services Capability Manager
Mobile Data Services Area of Opportunity
Applications and Services Lab
Intel's Architecture Labs
Intel Corporation
Office Phone# +1 (503)-264-9896
Mobile Phone# +1 (503)-807-9564
Email: paul.k.reddy@intel.com
-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM]
Sent: Wednesday, September 06, 2000 9:33 AM
To: ITU-SG16@MAILBAG.INTEL.COM
Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier -
Mandate of
Q. 13/1 6
Hi, Everyone (including all Rapporteurs and WP 2 Chairman):
Again, it is interesting to see how a very narrow view can
create serious
problems not only for a simple Annex, but also for the whole
question, for
the whole study group, and for all other study groups of the ITU-T.
Time and again, it has been said that let us work within the
mandate of
Q.13/16 first and contributions had been made to clarify those points.
Everything has been ignored just because few folks want to do
something
almost working like a close group without seeing the BIG
picture of all
questions of all SGs of the ITU-T. In fact, some joint
meetings were also
initiated between SG16 and SG11 to see how the HLFs, VLFs,
and AuFs related
protocols are being addressed elsewhere.
Still, they are pushing the same thing just because few folks
brought some
contributions. Objections were put via contributions, emails,
and verbal
discussions. Even there is not a single editorial note in the document
related to those things.
A simple example will reveal the fact. We have discussed that
there are
serious problems to use GRQ messages to discover the GKs in mobile
environment. Many contributions, emails, and verbal
explanations have been
provided. If you look into the present H.323 Annex H
write-up, you will see
that, as if, GRQ is the "Nirvana" for discovering the GK in mobile
environment. Not a single word has been used even as an editorial note
whether some members have raised the questions that there are
problems need
to be addressed for GRQs. The way the GRQ section has been
written, it is a
generic one and is nothing do with mobility. Rather, it suits
to be added in
the base H.323 spec. Many more examples can be given for each
technical
issue.
This Annex has NOT done its first important task how to
extend the H.323
signaling messages (RAS, Q.931, Annex G) to solve the
mobility problems for
the H.323 entities (Terminals, GKs, BEs, GWs). In fact, it is
the mandate of
Q.13/16. Contributions are there, but everything has been ignored.
Rather, Annex H has focused in some areas for which it has NOT got the
mandate: Communications between VLFs <-> HLFs, VLFs <-> AuFs,
HLF <-> AuFs,
etc. These work items are not the charter of Q.13./16 alone.
These are the
areas for the joint work with all other questions of all SGs
that deal with
mobility. (In another example, even if H.320, H.321, or H.324
wants to be
used by mobile users, they can also use HLFs, VLFs, AuFs,
etc. Similarly,
all other mobile applications of all other SGs can also use
these HLFs,
VLFs, AuFs, etc. Take the case of AuF, it can also be used by
the fixed
user. There is nothing fency about this.)
(More importantly, these additional entities have raised
serious concerns:
How does a GK/BE play a role in the overall process while
"wild" suggestions
have been made to use the Annex G protocol as well? It has created a
"dangerous" mechanism to "by-pass" the very need of GKs/BEs.
In fact, some
members have boasted that they even do not see any need to go
via GKs or BEs
anymore so far mobility is concerned. As if, a "bomb " is
about to be placed
to break the very foundation of H.323 in the name of
extending of H.323 for
mobility.)
More can be written for each technical issue, if needed. If
one likes to see
some of those points, please see the contributions that were
submitted in
the last Q.13/16 Portland meeting.
Again, I am repeating the proposal for H.323 Annex H:

First, finish the extension of the existing H.323 base

specs, and H.225.0
(RAS, Q.931, Annex G)to support mobility among the H.323 entities:
Terminals, GKs, BEs, and GWs. (see the contributions that are
being made so
far).

Second, develop a clear mandate whether the backend

protocols like VLF
<-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of
Q.13/16 only, or
these protocols need to be worked with other SGs. (see the
contributions
that are being made so far).

Third, any protocols that re being used between VLF <->

HLF, VLF <-> AuF,
HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or
its extension
because these are separate protocols and serve completely
different purposes
although may useful properties (e.g., hopcount, etc.) of the Annex G
protocol can be used for these protocols.
It is very important to note that only item 1 is within the charter of
Q.13/16 (H.323). All other items need to be addressed in the
light of all
mobility works of all questions of all SGs of the ITU by the
working party
chair and others.
(My personal view is this: Let H.323 Annex H be scoped for
item 1 only for
now as a first step. It will also take a good amount of time
to finish it.
People are waiting to see that this happens first.
To include other items, it may take a long time to have
stable texts working
with all SGs. This will then constitue the second step.)
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM]
Sent: Wednesday, September 06, 2000 8:08 AM
To: ITU-SG16@MAILBAG.INTEL.COM
Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier -
Mandate of
Q. 13/1 6
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@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
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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

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

Reddy, Paul K

Markku Korpi

tags (0)

participants (2)