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@NOKIA.COM [SMTP:jaakko.sundquist@NOKIA.COM] Sent: Tuesday, November 02, 1999 3:41 AM To: ITU-SG16@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. -------------------------------------------------------