H323mobility: meeting

Roy, Radhika R, ALARC rrroy at ATT.COM
Tue Nov 2 13:01:47 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