H323mobility: meeting

Roy, Radhika R, ALARC rrroy at ATT.COM
Tue Nov 2 09:55:05 EST 1999


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)!

Please note the following:

1. Zone and domain are well defined in H.323.

2. We have to work for mobility solution in a way that fits very well that
already exists in H.323.

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.

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.

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

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.

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.

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.

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

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.

Hope that this email will clarify the things better.

Best regards,
Radhika

> -----Original Message-----
> From: jaakko.sundquist at NOKIA.COM [SMTP:jaakko.sundquist at NOKIA.COM]
> Sent: Tuesday, November 02, 1999 3:41 AM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      Re: H323mobility:meeting
>
> Hi again Ed, Radhika et al
>
> As you had quite a bit of conversation during my out-of-office hours, I'll
> try to include all my comments on the discussion in this one mail.
>
> First of all, I do not understand Ed's comment about the HomeZone ID &
> VisitedZone ID not clashing with the meaning of zone. Surely these are
> meant
> to be some identifiers for certain zones. I did not, btw. propose the
> concepts Home Area and Visited Area, these terms are in my opinion not
> good
> terms and I just tried to illustrate my point with using them in the
> earlier
> mail. Thus I propose that we do not use them. What I was trying to say in
> the earlier mail is this: we have not agreed where the HLF and VLF (or AuF
> for that matter) should be placed in the architecture. The concept of
> HomeZone implies that each User has one zone which is his/her/its home,
> thus
> also implying that the HLF must be associated with the GK of that zone and
> no other GK (of course other GKs could have their own HLFs). Similarly
> each
> GK would have their own VLFs. When I introduced the concepts of Home
> Domain
> and Visited Domain, I was thinking about the HLF and VLF being
> functionalities that are used by all the GKs in the Domain, thus I would
> rather associate them with e.g. the BE than the GK. The point is that we
> have not defined or even really discussed the architecture yet, so let's
> not
> define terms that already point to a certain direction in the
> architectural
> decision.
>
> As for the Location Area (LA) concept, my contribution (APC-1659) did not
> actually present it as a subset of a zone. I tried to define it in such a
> way that I would not restrict the possible Network Points of Attachment
> that
> can belong to a LA. The result in the end was, I agree, quite complicated,
> allowing the LA to be either a subset, a superset (one LA includes NPoAs
> in
> many zones) or equal to a zone (LA = zone). I think we have to discuss
> further how the LA should be defined (complexity vs. scalability), but I
> do
> think that the concept is a valuable one and should be adopted.
>
> I also think that the two-step approach of first defining the
> functionalities for "pure" H.323 Mobility and only after that the
> functions
> needed for PLMN interworking may not be the best approach. I think that we
> need to consider the interworking case also when defining the pure H.323
> case. This way we can take both cases into account, thus reducing
> unnecessary work in the second phase, i.e. the interworking phase. I'm not
> saying that we should define the interworking as a whole simultaneously
> with
> the pure H.323 mobility, but I would like to always consider the effects
> of
> our decisions to the interworking issue, when we are defining the pure
> H.323
> case.
>
> Lastly, I read Ed's draft for Annex H and I just have one small comment.
> In
> the scope it says something about the fact that the NPoA can change. I
> think
> we agreed that it should have stated that the NPoA can change also during
> a
> call, thus allowing handovers. I would like to see this in there just to
> avoid having the same discussions again. I'm sorry that I didn't catch
> this
> one already in Red Bank.
>
> - Jaakko Sundquist
> -------------------------------------------------------
>      In a hole in the ground there lived a hobbit.
>  Not a nasty, dirty, wet hole, filled with the ends of
>      worms and an oozy smell, nor yet a dry, bare,
> sandy hole with nothing in it to sit down on or to eat:
>      it was a hobbit-hole, and that means comfort.
> -------------------------------------------------------



More information about the sg16-avd mailing list