Re: H323 mobility: Summary of discussion

8 Nov 1999

      Hi, Ed:
Kindly see my reply.
Best regards,
Radhika
...
-----Original Message-----
From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM]
Sent: Monday, November 08, 1999 12:26 PM
To:   ITU-SG16@MAILBAG.INTEL.COM
Subject:      Re: H323 mobility: Summary of discussion
Hi Radhika,
"Roy, Radhika R, ALARC" wrote:
...
Hi, Ed and All:
I understand your point. As I explained that contributions with solution
have been provided based on "Home and Visited" solving the mobility
problems.
All members are welcomed to provide solutions based on their concepts.
If
...
the alternate solutions are provided based on contributions we will
definitely be able to see how solutions are provided based on alternate
ideas or terminologies. Then, we will have wonderful opportunities to
compare each idea or terminology without any confusion or ambiguity.
Definitely we are waiting to make compromises if we collectively see
that it
...
makes sense to do so when we see that there are better solutions
available
...
based on alternative approaches.
We are only in definition phase. These are the place holders. If the
architectural solution that we will be agreeing with does not support
those
...
definitions or terminologies we will definitely change these. There
should
...
not be any doubt about this. I do not see why we should hold-off our
discussions for these two terms.
...
As an Editor, I suggest that you can put a
note that "some members have some objection to agree on these two terms,
but
...
we will revisit these terms when we finalize our architectural
solution."
...
Noted
...
We will have an architectural discussion in the upcoming conference
call. We
...
have invited contributions with proposed solutions to have all ideas
clear
...
so that we can move forward.
...
Finally, Ed - what we are looking for is the solution of the problem
(not
...
adding or deleting some terminologies here and there).
We have plenty to solutions, but weak definitions.
[Roy, Radhika R]  If it is so, the logical step is to examine all
solutions to understand them better and let us come back to make the
definitions stronger once we agree on the solution.
[Roy, Radhika R]  The other alternative is to go on defining terms
that may consist of both "strong" and "weak" definitions and let us move on
to the solution area. Then we come back what we do about the "strong" and
"weak" definitions because our goal is the solution.
[Roy, Radhika R]  The bottom line is: Let us move on to find the
solution.
...
Thanks
...
Hope this email will clarify your concern.
Best regards,
Radhika
...
-----Original Message-----
From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM]
Sent: Friday, November 05, 1999 6:31 PM
To:   ITU-SG16@MAILBAG.INTEL.COM
Subject:      Re: H323 mobility: Summary of discussion
To the Mobile Ad-hoc Colleges:
What we have here is an opportunity to build a good
working relationship. But, it seems at this time,
we are in feeling out stage. Solutions and proposals
are being worked within companies and in
difference standards, which want to  find a
place in the work we are doing but, I think
compromise is in order.
The only thing I was suggesting in by email,
was that the word "Home and Visited" bother soon
of our colleges. So my suggestion was to persevere
the  functions and compromise on the naming of the functions.
By definition, whatever we put in the H.323 mobility
document will have to be in the
context of the H.323 framework baseline.
Lets keep an open mind as we move forward,
Y peace. We all may learn something and discover
new things. If possible lets start looking on compromise
solutions that satisfies all involved. Once we limit our
scope it limits us from progressing towards the future.
Best Regards,
Ed
"Roy, Radhika R, ALARC" wrote:
...
Hi, Ed and All:
I do not know whether you have seen my reply to Jaakko. I am
enclosing
...
...
it
...
again. Please respond to my reply to provided Jaakko to prove your
statement.
I completely disagree with Ed. Please also see Marc Roelands's
comments
...
...
on
...
LA.
AT&T contribution has shown how H.323 mobility problem can be solved
using
...
home/foreign GK (zone).
I like to see the complete H.323 mobility problem that has been
solved
...
...
using
...
the alternative approach as proposed by Nokia. I have NOT seen
Nokia's
...
...
...
solution yet. Unless a complete solution is provided like AT&T's, I
am
...
...
NOT
...
convinced how mobility problem can be solved in a better way.
I also see that there is a need for HLF/VLF. No one against the
HLF/VLF
...
...
...
function. AT&T proposal also has shown how HLF/VLF function is taken
care-of.
What I disagree with is this: A protocol should NOT be
implementation
...
...
...
specific. For example, we do have a luxury to build one protocol for
distributive GK (HLF/VLF) function, one protocol for centralized GK
(HLF/VLF) function or one protocol for hybrid GK (HLF/HLF) function.
It
...
...
is
...
against the fundamental concept of H.323. For example, the same
argument
...
...
can
...
also be applied for the directory function. Similar may the case for
other
...
functions as well. It is a complete break down of H.323 protocol and
architecture.
So, HLF/VLF is another function in H.323. HLF/VLF is NOT a "Holy
Grail"
...
...
for
...
which we have to create a complete "DISCONTINUITY" in existing H.323
protocol and architecture. I like see to Nokia's alternate solution
to
...
...
...
disprove this fear.
Nokia has to bring a complete contribution providing solution like
AT&T's to
...
prove their case. Otherwise, we cannot proceed with a concept that
has
...
...
not
...
proved with a solution.
The problem can be solved as follows:

Let Nokia provide a complete proposal solving the H.323 mobility

problem
...
using heir alternative approach. What Nokia has provided is a high
level
...
...
...
concept. They have NOT solved the problem yet. Let us see what the
complete
...
solution is. If a solution is provided, we can then compare Nokia's
solution
...
with that of AT&T's solution. Otherwise, their proposal is still
HYPOTHETICAL. It is a concept, NOT a solution.

How can we agree on a concept without seeing its solution that

has
...
...
the
...
potential to break down the fundamental architecture of existing
H.323
...
...
...
standard?

Let us solve H.323 mobility problem within the framework of

H.323.
...
...
...

Let us move on with contributions for the part that we can agree

on.
...
...
If
...
Nokia brings a complete solution, we will definitely re-consider
their
...
...
case.
...

I agree with you that we also need to work for interworking

between
...
...
H.323
...
(IP) mobility and cellular-PSTN/ISDN network.
Finally, Ed - you have made a statement, but it has to be proved
providing a
...
solution. An alternative concept is there, but we have not seen its
solution
...
yet. What is the problem to bring the alternate solution? Why do we
need
...
...
to
...
wait for a concept that has NOT been substantiated with a solution
yet?
...
...
...
Best regards,
Radhika
...
-----Original Message-----
From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM]
Sent: Thursday, November 04, 1999 9:47 AM
To:   ITU-SG16@MAILBAG.INTEL.COM
Subject:      Re: H323mobility: Summary of discussion
Importance:   High
I agreed with most of Jaakko comments and also
make vaild points, and will like to
add the following.
I believe that the (Home) in Home  Zone should be taken out.
What we are talking about is the User's Point of Attached in
any given Zone. The HLF is ready and  Data base
which has the User's profile and the current user's location.
We can get a new name to HLF and call it the Location Profile
Register (LPR) or Location Profile Function (LPF).
I also believe that the (Visited) in Visited Zone sould also
be taken out because again we are talking about
the Users current Point of Attachment in any given Zone.
The VLF has the means to update the
Location Profile Register (LPR) from
any given Zone. We can get a new name to VLF
call  it the  Location Update Register (LUR) or
Location Update Function (LUF).
Now we can also support concepts of Zone ID's
such as Current Zone ID and Previous Zone ID.
Finally,
And I strongly agree with looking at the interworking
in parallel with H.323 mobility. The time we spent
now looking at interworking will be compensated in the
long run. I sure does working on ISUP, IN  and Qsig, inetrworking
with H.323 would agree and we should learn from their experience.
And not leave it for a last minute add-on.
Lets take the contribution as they come, if one wants to put in
interworking fine. If one wants to put in contributions only H.323
mobility also fine. Both are in order and within our scope.
The general strategy should focus on ensuring that the H.323
Mobility and interworking options are enabled, rather than
spending
...
...
...
...
too much effort blocking alternative options (Our limited
resources
...
...
...
...
frankly don't allow this luxury). But there really is no
substitute
...
...
for
...
...
doing the work - preparing input papers and presenting them
to move things forward.
Best Regards,
Ed
[Roy, Radhika R]  Hi, Jaakko:
Pl. see my reply provided below.
Best regards,
Radhika
    -----Original Message-----
    From:   jaakko.sundquist@NOKIA.COM

[SMTP:jaakko.sundquist@NOKIA.COM]
...
    Sent:   Tuesday, November 02, 1999 11:13 AM
    To:     ITU-SG16@MAILBAG.INTEL.COM
    Subject:        Re: H323mobility: meeting

                    Once again, hi, Radhika, Ed + all

                    See my comments below...

                    Hi, Jaakko, Ed, and All:

                    I hope that Jaakko will get this mail while

he
...
...
is in
...
his
        office (Thanks
                        Jaakko - you have reminded us the time
difference)!
...
                    [Jaakko:] You caught me just in time.

                    Please note the following:

                    1. Zone and domain are well defined in

H.323.
...
...
...
                    [Jaakko:] Yes, they are defined.

                    2. We have to work for mobility solution in

a
...
...
way
...
that fits
        very well that
                        already exists in H.323.
                    [Jaakko:] Agreed.

                    3. We can invent many things if we need to

solve
...
...
...
mobility
        problems only when
                        we think that those functions are NOT
covered in
...
...
...
existing
        H.323 standard.
                    [Jaakko:] Yes.

                    4. If mobility problems can be solved using

the
...
...
...
concept of
        "zones" and
                        "domains," I would assume that it would be a
big
...
...
...
mile stone
        so far the
                        continuity of H.323 is concerned. That is,
as Ed
...
...
...
pointed
        out, H.323 mobility
                        problem is NOT a rocket science. We have to
remember
...
that we
        are working in
                        the framework of already existing H.323
standard
...
...
...
    architecture. We have to
                    relate our solution in the context of

existing
...
...
H.323
...
    standard. In other
                    words, we CANNOT change the fundamental

concept
...
...
of
...
existing
        H.323 standards
                        just because we are addressing mobility.
                    [Jaakko:] Yes, of course. I'm not arguing

against
...
that. I
        guess you are referring to the Location Area discussion
here.
...
...
The LA
...
concept
        is really merely a scaling issue, you could of course handle
paging
...
(I'm
        assuming that we will need the paging procedure) based on
zones,
...
...
...
i.e. page
        every NPoA in a zone when a call arrives, but this might be
quite
...
limiting
        in some cases (the zone may be needlessly big or very
small). I
...
...
do
...
not think
        that we need to change any fundamental concepts of H.323, if
we
...
...
...
introduce
        the LA concept.
        [Roy, Radhika R]  May be we can include LA when we see that
we
...
...
need
...
to optimize a zone further. We may revisit this in the second step.
                    5. I do not understand what benefits we are

gaining
...
adding
        more
                        "terminologies" like "AREA {home, foreign,
etc}"
...
...
...
while the
        "zone" and
                        "domain" are already well defined in H.323.
My
...
...
...
personal view
        is that we
                        should FIRST try to solve H.323 mobility
problems
...
within the
        context of
                        "zone" and "domain" as far as practicable. I
would
...
argue
        that zone and
                        domain are good enough to serve this purpose
for
...
...
...
now. (Pl.
        also see AT&T's
                        and Motorola's contributions.)
                    [Jaakko:] As I already said, I did not

intent to
...
...
...
define the
        terms: home area and visited area. I was just trying to
illustrate
...
the point
        I was making about not having the Home/visited zone terms
defined
...
yet.
        [Roy, Radhika R]  It is good point. Let us define these.
AT&T
...
...
...
contributions have the detail definition for each term.
                    6. With respect to your comments that it

appears
...
...
...
that every
        GK will have HLF
                        and VLF function, I would say that every GK
will
...
...
...
have the
        access to the HLF
                        and VLF function. This capability for each
GK
...
...
has to
...
be
        provided because of
                        the fact that H.323 architecture is
GK-centric.
...
...
We
...
do not
        have any choice
                        because we are restricted by the H.323
architecture.
...
                    [Jaakko:] I did not argue against this. The

point is
...
that if
        we identify a concept called the Home Zone, this already
implies
...
...
...
that each
        User has only one zone, in which he/she/it is not a
"visiting
...
...
user".
...
I think
        this would be really restricting.
        [Roy, Radhika R]  As I mentioned that H.323 is the
GK-centric. A
...
...
...
user may change his/her network point of point attachment, but it is
still
...
the same (Home) GK. So, a given (home) GK, there has to be another
level
...
...
of
...
granularity to address mobility in terms of network point of
attachment.
...
...
...
Please see AT&T contribution how home and foreign network concept
have
...
...
...
solved the problem. Similar is the case with Motorola's
contribution.
...
...
The
...
bottom line is that home/foreign GK concept does NOT imply any
restriction
...
to solve H.323 mobility.
                    6.1 With respect to your question whether

HLF/VLF
...
can be
        distributive or
                        centralized, having said (in item 5) that
every
...
...
GK
...
should
        have access to HLF
                        and VLF function, it is up to implementation
whether
...
HLF and
        VLF function
                        can be centralized or distributive. Please
see
...
...
AT&T
...
    contributions submitted
                    in Red Bank how we can implement these

functions
...
...
in
...
both
        distributive and
                        centralized environment.
                    [Jaakko:] This is actually quite much the

point
...
...
I
...
was
        making. By defining the Home Zone we would in my mind
actually
...
...
be
...
pointing
        to the centralized model.
        [Roy, Radhika R]  By definition, there can as many GKs as
one
...
...
wish
...
have in an H.323 system. So, by definition, the GK-centric H.323
architecture is distributive. By defining home/foreign GK, H.323
mobility
...
also becomes distributive up to the point that a basic H.323 system
allows
...
us. So, we do not see any limitations.
                    6.2 In an analogy of this HLF/VLF function,

I
...
...
can
...
bring
        another function -
                        Directory services. For example, H.323
assumes
...
...
that
...
all the
        address (e.g.,
                        alias, transport, network) are kept by each
GK.
...
...
...
H.323 does
        not answer how
                        the address information is maintained by
each
...
...
GK.
...
People are
        using LDAP
                        directory server. The question is: whether
that
...
...
...
directory
        service is
                        distributive or centralized? I guess that it
can
...
...
be
...
done in
        both ways
                        depending on implementation.
                    [Jaakko:] My point exactly. I would like

that
...
...
all
...
GKs inside
        the same Administrative Domain would be able to access the
same
...
...
...
HLF/VLF
        functionality.
        [Roy, Radhika R]  As I pointed out, this an implementation
issue. I
...
would argue that we should allow both options and let an implementor
choose
...
as it is necessary. Please also see AT&T contributions how both
options
...
...
can
...
be addressed.
                    6.3 In AT&T contribution, it is shown that

it
...
...
better
...
to make
        VLF
                        distributive (per GK) although HLF function
can
...
...
be
...
made both
        distributive
                        and centralized. Again, this is a matter of
implementation.
        As mentioned in
                        AT&T contribution, we also need to define a
kind
...
...
of
...
backend
        protocol for VLF
                        and HLF (something like similar to Siemens,
Nokia
...
and
        Intel's contribution -
                        TD-39: Security Services for Backend
Services
...
...
and
...
Mobility
        in H.323).
                    [Jaakko:] I would assume that you can

distribute
...
...
the
...
HLF/VLF
        functionalities inside the Administrative Domain as you
like,
...
...
but
...
    distributing them between the Domains would be difficult.

Actually I
...
think
        that the concept of Administrative Domain was introduced in
H.323
...
for this
        kind of reasons.
        [Roy, Radhika R]  Again, H.323 system is GK-centric in a
given
...
...
...
domain. For inter-domain, it is BE-centric. In a given domain, H.323
architecture has to be GK-centric. Once we solve intra-zone and
inter-zone
...
(intra-domain) mobility, we can extend our experience for
inter-domain
...
...
...
problem as well. Please also see AT&T contribution how these
problems
...
...
have
...
been addressed. My replies to 6.1 and 6.2 are also good for this
case.
...
...
...
                    7. Again, I, personally, do not rule our to

re-examine the
        benfit of "AREA"
                        (e.g. location area [LA]) vs. "ZONE/DOMAIN"
concept.
...
May be
        it is in the
                        second step.
                    [Jaakko:] I am just a bit afraid that if we

leave
...
this kind
        of a major mobility related concept out of the first phase
thinking
...
process,
        we will find it much more difficult to include the concept
in
...
...
the
...
second
        phase (where I think we will need it). Furthermore, I'm not
convinced that
        the LA concept would not be useful in the pure H.323
approach
...
...
...
either.
        [Roy, Radhika R]  I think that it can be place holder for
now. I
...
...
...
would request to bring more detail contributions proposing solutions
like
...
AT&T and Motorola to prove the case better. Then, we can compare
both
...
...
...
solutions. In AT&T contribution, I feel that the LA can be
accommodated
...
...
to
...
optimize the zone further. So, I do not see that it is a problem to
accommodate the LA concept if needed. I personally prefer that we
can
...
...
better
...
address this in the second phase once we solve the problem for the
basic
...
...
...
architecture.
                    Hope that this email will clarify the things

better.
...
                    [Jaakko:] I think the main thing is that we

got
...
...
the
...
    discussion going on again. I'm kind of tired already, and I

hope
...
...
...
that I
        didn't mess things up too much in this mail.
        [Roy, Radhika R]  Definitely, I also like that discussions
must
...
...
go
...
on. We must be convinced that we have the best solution because it
has
...
...
the
...
severe implications for all on-going mobility standard works
throughout
...
...
the
...
world once we standardize H.323 mobility in SG16.
                    Best regards,
                    Radhika

                    Same to you,
                    Jaakko

...
--
Edgar Martinez - Principal Staff Engineer
Email mailto:martinze@cig.mot.com
FAX 1-847-632-3145 - - Voice 1-847-632-5278
1501 West Shure Drive, Arlington Hgts. IL 60004
Public: TIPHON & Other Stds - http://people.itu.int/~emartine/
Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/
--
Edgar Martinez - Principal Staff Engineer
Email mailto:martinze@cig.mot.com
FAX 1-847-632-3145 - - Voice 1-847-632-5278
1501 West Shure Drive, Arlington Hgts. IL 60004
Public: TIPHON & Other Stds - http://people.itu.int/~emartine/
Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/
--
Edgar Martinez - Principal Staff Engineer
Email mailto:martinze@cig.mot.com
FAX 1-847-632-3145 - - Voice 1-847-632-5278
1501 West Shure Drive, Arlington Hgts. IL 60004
Public: TIPHON & Other Stds - http://people.itu.int/~emartine/
Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

Roy, Radhika R, ALARC

tags (0)

participants (1)