H323 mobility: Summary of discussion

Roy, Radhika R, ALARC rrroy at ATT.COM
Fri Nov 5 09:11:36 EST 1999


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:

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

2. 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?

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

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

5. 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 at CIG.MOT.COM]
> Sent: Thursday, November 04, 1999 9:47 AM
> To:   ITU-SG16 at 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 at NOKIA.COM [SMTP:jaakko.sundquist at NOKIA.COM]
        Sent:   Tuesday, November 02, 1999 11:13 AM
        To:     ITU-SG16 at 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 at 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/



More information about the sg16-avd mailing list