H.323 Mobility Ad Hoc Group Conference Call information
Reddy, Paul K
paul.k.reddy at INTEL.COM
Tue Nov 2 13:46:40 EST 1999
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
More information about the sg16-avd
mailing list