[H.323 Mobility:] A new editor's draft H.323 Annex H

Jaakko Sundquist jaakko.sundquist at NOKIA.COM
Tue May 9 08:09:42 EDT 2000


Hi Radhika,

Find my comments embedded...

>
> I hope that you have been enjoying the ice-hockey....

Yes, it was most enjoyable. Finland won 7-4.

>
> I understand that the editor's draft is just a contribution
> for the upcoming
> tomorrow's conf call, not a draft for the Osaka meeting.

It is not yet the draft for the Osaka meeting. However, since the meeting is
already in next week, I will not make too many changes to it.

>
> I do not know which parts of your draft have been taken from the
> contributions that had been discussed and agreed. I have seen
> no reference
> to it. Or, have you made some educative guess from your side?

If you remember, we had a discussion about the way we will continue the
Annex H work in the last teleconference. Since we have achieved almost
nothing since the Geneva meeting I thought it would be a better idea if I
produced a draft of the annex including my thoughts (of course taking into
consideration the discussions that we have had) of how it should look like
and you as well as anyone else could make your contributions against that.
This idea also seemed to gain some support.

>
> Let me explain.
>
> You have two roles to play: First as an editor to reflect
> what has been
> agreed upon by the members based on contributions. Second, an
> individual
> from Nokia to agree or disagree.
>
> An editor must provide the draft that will reflect what has
> been agreed by
> the members based on contributions. However, as an individual
> from a company
> an editor may have differences. These differences can be
> reflected in the
> draft in two ways: 1. As an editor's note and 2. Even as an
> individual from
> Nokia (assuming that subsequent contributions will clarify this).

Quote from the first page of the draft: "NOTE:  None of the changes, that
are made to this document after the previous acceptance of changes (i.e. all
changes that are highlighted when the MS-Word highlight changes option is
on), are accepted by the members of the mobility ad hoc group."

As I said above, I'm hoping that this kind of working method of me producing
the draft annex and all of you making your contributions against that will
make our progress faster. Unfortunately I was not able to bring the draft
forward any earlier, which of course makes it harder (if not impossible) for
you to make your contributions for the Osaka meeting against the draft
directly. However, I do think that we can work in Osaka in a more systematic
manner and perhaps even have some results.

>
> Section 4:
>
> I guess that you have one contribution showing these figures
> 2 through 7
> (there is no reference - I see a similarity- am I correct?). We never
> discussed this contribution in any conference call. How come
> that you have
> included all figures from your contribution that has not been
> discussed and
> agreed?

These figures are the same as in my contribution MTD-011b, which was not
discussed in the teleconference because of lack of time. MTD-011b was based
on the earlier contribution MTD-011 and the discussions we had about it in
the first teleconference after the Geneva meeting. I thought that it is very
important that we clearly explain what is meant by a scenario and what kind
of scenarios we might consider in the H.323 mobility work.

>
> In fact, we discussed about your earlier contribution where
> we have agreed
> that we will start from all H.323 scenarios: First,
> intra-zone, inter-zone,
> and inter-domain scenarios.

This is exactly why the figures are there. They explain what is really meant
by the all-H.323 scenario (and of course the other scenarios as well). I
have also added a statement to the scope stating that we will initately
focus on the all-H.323 scdenario. Furthermore, the concept of the scenario
was (nor is) supposed to include any reference to Intra-zone, Inter-zone or
Inter-domain (this is actually the reason, why I thought that the MTD-011
needed to be re-written, it lead to a confusion about the meaning of
scenario), so I see that it really is necessary to clearly explain the
scenario concept in order to avoid this kind of misunderstandings.

>
> For inter-working between H.323 and non-mobile scenarios,
> there are many
> possible scenarios and we may not address in this document
> for now for the
> sake of time. So far I re-collect, this has been the
> decision. Section 4
> does NOT reflect this.

Again, see the scope.

>
> Section 7:
>
> I like to see that there should be an editor's note that
> "Figure 8 will be
> revisited based on the extensions that will be made in H.323
> to support
> mobility. This is just a place holder to provide references
> for the on-going
> discussion."
>

Of course the architecture figure can and probably will be refined as we
continue the work. (I believe that at least Intel is going to propose some
changes to it in Osaka). I do not think we need to put in any comments
saying that. Furthermore, could you explain what you mean by saying that the
figure is just a placeholder for the ongoing discussions? I regard this kind
of an architectural figure as an integral part of this kind of
specification.

> Section 8:
>
> Which contributions your are referring here that we have
> agreed? I would
> request that people MUST bring contributions to define
> virtual home and
> service execution environment before an editor put any texts in it.

I do not think that chapter 8 is even nearly complete, but since we have had
quite a lot of discussion going on around the concept of Virtual Home
Environment (especially with Ericsson), I wanted to add something that would
explain the difference between these two distinct concepts. I would really
appreciate, if someone would bring in contributions to refine this chapter.

>
> Did you submit an outline of your draft to be approved?

No, for the reasons stated in the beginning of this message. Furthermore, I
do not think that I have changed very much of the outline that has been
agreed. You can, of course, suggest a different kind of outline.

>
> Section 9:
>
> Which contributions you are referring to?

I have tried to gather the issues that I think we have more or less agreed
on in our discussions with regards to this chapter. I have made some new
names for certain concepts and for some parts I have made my own suggestions
(mainly the information flows). I have not taken any of the contributions as
a basis for this chapter, because we haven't agreed on very large parts of
any contribution.

>
> Did you have any outlines for this section that need to be approved?
>
> My understanding has been that we agreed that the mobility
> management will
> include: A. Intra-Zone, B. Inter-Zone, and C. Inter-Domain.
>
> In each case it will have the following:
>
> 1.      GK discovery
> 2.      Registration
> 3.      Location update
> 4.      Call establishment

I think this is exactly what I have done. The problem with the terms
Intra-zone, Inter-zone and Inter-domain is that I do not know what you
exactly mean by them. In the previous H.323 standards the division has been
easy, because there is always a call involved and the division is made based
on the relative locations of the participants of the call. In Annex H,
however, it is often needed to contact e.g. different domains even though
the call might actually be an Intra-zone call. I have introduced the ideas
of Location updating procedures and related to that the
Intra/Inter-zone/domain location changes as well as Call related MM
procedures that can be divided into Intra(Inter-zone/domain call cases to
clarify the categorization.
>
> AT&T and Alctel contributions are there and these contributions were
> discussed. The outlines should follow these procedures to
> follow the text
> consistently.

These contributions were discussed, but I do not remember having an
agreement on almost anything in those contributions. The only thing we
almost agreed on in the AT&T contribution was the figure illustrating the
zone, its relation to the funtional entities and the NPoAs. This figure has
been used as a "model" for the figures 10 - 13 in the draft annex.

> Section 9.1.1:
>
> Like home domain, AT&T contribution has provided the detail
> description of
> home GK/zone from a user point. Accordingly, home network
> address (network
> point attachment) has been explained. In a given zone, a
> mobile may move
> from one NpoA to another. Like foreign (or
> visited/visiting/target) domain,
> AT&T contribution has also explained the foreign (or
> visited/visiting/target) network address (or NpoA). The
> subsequent emails
> have also been sent explaining the things.

With regards to the home GK, I am considering that it may be a good concept
to introduce for some purposes (mainly because of GK discovery issues and
the Virtual Home Environment concept), but I have not yet introduced in the
draft, because I want to have a clearer picture of how the concept would be
used. I certainly do not like the idea of always having to contact the home
GK in order to be able to use the H.323 services, nor do I like having to
contact the HLF through the (home) GK. In other words I am willing to add
the concept as soon as we have agreed on the semantics of it. I still do not
see the merit of the home NPoA concept, I do not think it adds anything that
could not be achieved by using e.g. mobile IP.

>
> I would expect, like visiting/visited domain, the concept of
> visiting/visited/target network address should be taken as a
> part of it.
> Without this, the mobility management will almost be
> MEANINGLESS because the
> trivial mobility management keeping some addresses in a database like
> VLFs/HLFs do not help the service providers and the mobility
> management
> through re-registration is already there in H.323, and no new
> standard work
> is needed for extending the so called VLFs and HLFs databases.

I do not think it is meaningless to define an organized way of keeping track
of the Users' location in the network. That in my opinion is NOT present in
H.323. It does not mean that these mobility management features have to be
overly complicated, in fact I would prefer as simple (or trivial) solution
as possible. If and when we get this trivial issue settled we can perhaps
add more features to the Mobility Management.

>
> Figure 11 shows that the inter-zone mobility management is
> maintained using
> the single HLF. Which contributions you are referring to? Did
> we agree on
> this concept? AT&T contribution shows that it is an
> unacceptable proposition
> if we consider that there is a single HLF (as the protocol is
> "hard-wired"
> for a centralized HLF configuration)?

As I have stated in some earlier emails to the list, I do think that it is
necessary to regard that only one logical HLF holds the location information
of a particular User. This database could be distributed in some way unknown
to the H.323 system and we could even define a method for enabling the HLF
to have multiple network addresses (i.e. multiple "locations" in the network
where it could be accessed), but I do not think that we should try to define
a way to distribute the HLF database in the network (and that I think is
what you are suggesting by having multple alternative HLFs for a User).

>
> Figure 12 shows that a single VLF is communicating with
> multiple HLFs. Which
> contributions do you refer to?

I have always assumed this as a possibility, but you are right, it has not
been exactly stated in any contribution before, so I guess I am contributing
it now. It is of course possible to have the VLF only be in contact with one
HLF, if that is what we want.

>
> Figure 13 shows that HLFs are communicating between the
> domains? Did you not
> see that we are NOT in sink with this approach because the
> questions have
> been raised that this approach might be "breaking" the H.323
> standard? AT&T
> has also provided contributions regarding this (I guess that Alcatel's
> contribution also agrees with AT&T's contribution in this regard).

When the Hinter reference point was added to the architecture figure, I
thought that we made the assumption that Inter-domain communications between
the VLFs and HLFs are possible. If we want to remove that possibility, I'm
more than happy to agree. In fact I remember even making a contribution
(sometime in the autumn) suggesting that BEs are used in the Inter-domain
communications.

>
> Are you "pushing" for some something (or am I missing
> something)? If it is
> so, please bring contributions, we will be pleased to discuss.

As stated earlier, I'm just trying to make some progress.

>
> Section 9.2:
>
> Use of GRQ messages for the GK discovery is NOT new in H.323.
> It is already
> a standard. A reference to the existing H.323 standard is enough.

Section 9.2 does include more than just saying that GRQs are used.

>
> However, the fundamental question has been that GRQ messages are NOT
> efficient for the GK discovery in the cellular environment. AT&T
> contributions have provided an alternative solution using the
> MGA message
> for the GK discovery.
>
> So, the use of GRQ messages are INEFFICIENT for the GK
> discovery. So, it is
> NOT acceptable in the highly mobile environment.

Actually, personally I quite like your idea of the MGA message (or something
similar), but it seemed to create quite a lot of opposition, when we
discussed it over the phone (I think there were claims that in fact the MGA
would NOT be a more efficient method), so I did not add it. This is
something that I think we need to discuss in Osaka.

>
> Section 9.5:
>
> Again, I like to know which contributions you are referring to?
>
> Figures 15, 16, 17, 18, and 19 show that, as if, the protocol is
> "hard-wired" for the centralized HLF configuration. AT&T
> contributions do
> not assume this. We have NOT accepted this notion.

I admit that these information flows are based on my own thoughts and I am
not assuming that the whole group agrees to those without any discussion.
So, you should make your contributions against the ones I have added (which
you have already done, but we haven't yet had enough time to discuss them).

>
> So, the basic question: Why do you want to include the
> material where there
> are no contributions and no agreement?

As said, to fasten our work...

>
> There are fundamental flows the way you have shown all
> information flows.
> Let me cite few examples:
>
> You have shown that LRQ messages are sent from the GK to the
> VLF and/or HLF.
> Why do you think so? Did you not see that we have NOT even
> agreed with this
> in the last conference call and via emails? AT&T
> contributions have used NEW
> mobility management messages.

I really did not assume that the "Location_req" imaginary message would be
confused with the LRQ, but apparently I need to make that more clear. In
other words the Location_req is not the same as LRQ.

> Considering the comments provided above, all texts provided in your
> contribution need a COMPLETE re-writing of the document.

I'm sure there is a lot to be done, but at least now we have some clearer
ground for our discussions in Osaka.

>
> I understand the difficulty with the job as an editor. I
> appreciate your
> efforts. However, there are some norms that an editor has to follow:
> Contributions and Agreement made. If editors have their
> opinions, they can
> bring separate company contributions (NOT as Rapporteur
> contributions).

I think I understand what the job of the editor is. I'm just trying to
direct our work so that in some reasonable amount of time we might actually
achieve something. If you ask me, we (as the unofficial mobility ad hoc
group) have not agreed on ANYTHING since the Geneva that could be put to the
annex. I also have received some feedback from other members of the group
suggesting this kind of a work method and I thought it might be a better way
to go forward than the way we have previously worked.

>
> Hope to discuss the same in tomorrow's conf call.
>
> I am also curious to know which the team won the ice-hockey.....
The Hentunen-Kapanen-Lind attacking line was quite superb...


- Jaakko

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