H323mobility: Summary of discussion

sgkim sgk at KT.CO.KR
Fri Nov 5 06:17:18 EST 1999

안녕하세요. 김상길입니다.
수정할 내용은 없습니다.
'구룹' -> '그룹'으로 변경하였습니다.

-----원본 메시지-----
보낸 사람: Roelands Marc <Marc.Roelands at SIEMENS.ATEA.BE>
받는 사람: ITU-SG16 at mailbag.cps.intel.com <ITU-SG16 at mailbag.cps.intel.com>
날짜: 1999년 11월 5일 금요일 오후 7:48
제목: Re: H323mobility: Summary of discussion

>Hi Jaakko,
>Just a small remark on your location area argumentation:
>"what a LA is for: it is a grouping of NPoAs that are geographically located
>close to each other" assumes that NPoAs  are restricted to a single
>geographical point of attachment, which, as I understood it, was not the
>definition we aggreed on.  The NPoA in practice will be the IP address,
>which cannot a priori be restricted to a single geographical area (remember
>the Mobile IP discussion...).
>-----Original Message-----
>From: Jaakko Sundquist [mailto:jaakko.sundquist at NOKIA.COM]
>Sent: Thursday, November 04, 1999 14:48
>Subject: H323mobility: Summary of discussion
>Hi, Radhika et al,
>It seems that I did not make all my points so clear in my last message (as I
>said I was pretty tired when I wrote it). Also the discussion between me and
>Radhika (& Ed) seems to be getting out of hand. Thus I'll try to summarize
>the points in the discussion and include my views in this message.
>As I see it, we have been discussing about three basic issues:
>- The architectural placement of the HLF and VLF functionalities. The
>discussion also has included (or actually it started from) the question
>whether the terms: Home Zone and Visited Zone, with respective identifiers
>should be defined or not.
>- The two-step approach of first specifying the pure H.323 Mobility and as a
>second step the issues related to PLMN interworking. The discussion has been
>on whether (at least some of the) PLMN interworking issues should be
>considered while working on the pure H.323 Mobility.
>- The concept of the Location Area (LA). Whether we need that concept or not
>and if we need it, should it be considered already in the first step (see
>the above point).
>I'll address all these points below.
>I think we both/all agree on one thing:
>The HLF and the VLF must be defined in the standard in such a way that it is
>possible for multiple GKs to access the same HLF/VLF. This allows for an
>approach in which the HLF/VLF is distributed among many GKs while
>simultaneously allowing the HLF/VLF to be associated with only a single GK,
>if this kind of a centralized design is desired.
>The thing that we disagree on is: I do NOT want to define the terms Home
>Zone and Visited Zone (or similar) yet. I did not seem to make that clear in
>my last message. The reasons why I do not want to define this kind of terms,
>at least yet, are as follows.
>The term Home Zone leads in my mind to a definition in which every User is
>associated with one and only one zone as the User's "Home". I.e. the HLF
>containing the permanent information about the User can be accessed through
>the GK of the Home Zone and no other GK. Now, I do not think, Radhika, that
>this is what you intended, but if we talk about a Home Zone, this is the
>kind of thing that first comes to my mind.
>I currently have the idea that you meant that each User may have multiple
>Home Zones, is that right, Radhika? If that is the case, I do not fully
>understand why we would need the concept of the Home Zone at all (but maybe
>I'm just missing something).
>The important thing in all these Home/Visited concepts is: how to identify
>and access the HLF of a certain User and by accessing the HLF, update all
>the relevant information in the HLF and in the VLFs. If there are multiple
>Home Zones for a User, all the GKs of these zones can be used to access the
>HLF of the User, i.e. the HLF is identified by the Home Zone identifier (if
>this is not the case, what is the purpose of the Home Zone). Now, how is it
>determined, which GK should be Used in this case? The User must always give
>some "pointer" with which the HLF can be identified when the User enters a
>zone (or LA, if we use them). In this case the Home Zone ID would be that
>identifier. If always one of these Home Zones is given as the access point
>to the HLF, this leads to a highly centralized model with this one single
>zone and its GK as the central point. If, on the other hand, any of these
>zones can be given, how is this zone picked, randomly? Furthermore, how does
>a GK of a User's Home Zone know that it is in fact a "Home GK" for that
>User, if the User gives some other Home Zone ID than the one of the Home
>Zone where he is located?
>All the above reasons, in my opinion, lead to the fact that the HLF must be
>identified with an identifier that is NOT related to any single zone or GK.
>This is why I proposed the concept of Home Domain (I use the concept of an
>Administrative Domain because, as Radhika mentioned, it is already defined
>in H.323) in my contribution to the Red Bank meeting (APC-1659). In this
>case the Home Domain would identify the HLF of a User and thus the GKs in
>the Home Domain could identify that they are in fact a part of the Home
>Domain and the HLF to which they have access, is the HLF of the User. If the
>User would be located in some other (Visited) Domain, his HLF could be
>identified by the Home Domain (thus this model would be BE centric.
>The Administrative Domain is, of course, not the only alternative to group
>the zones, which form the "Home" of a User together, I just used it, because
>it is already defined. We could also define a HLF Identifier which is not
>related to a Domain, but the GKs of the zones forming the User's "Home"
>would recognize if the HLF to which they have access is the correct HLF
>based on this identifier.
>The two-step approach, as I understand it, means that we will first work on
>a pure end-to-end H.323 Mobility solution and after that has been done we
>will define the interworking with legacy (and future) mobile networks.
>Although I do agree that in general this is a good order to do these two
>things, I would like to see some general interworking aspects taken into
>consideration in the first phase. One example of these may be the Location
>Area concept. I do not want to go into details of the interworking issues in
>the first step, but I'm afraid that if we do not think about the
>interworking at all in the first step, we will end up defining some
>functionalities in two different ways, one being the result of the first
>step and the other an addition to this as the result of the second step when
>the solution of the first step is not capable of handling some general
>interworking procedure, for example.
>I hope, I made my point clear despite the above text being somewhat
>This is actually an example of the problem I have with the "strict" two-step
>approach. Radhika is proposing that we try to solve the mobility in the
>first step without the LA concept. I think it would be very beneficial, if
>we at least consider it already in the first step. Furthermore, I am quite
>sure we will need the concept in the second step, or else we will end up
>with a very badly scalable system.
>As I said in my earlier message, the LA concept will help to make the H.323
>mobile systems more easily scalable, the price for this is, of course, the
>increased complexity that the LAs bring to the system. To express shortly,
>what a LA is for: it is a grouping of NPoAs that are geographically located
>close to each other. A zone also consists of NPoAs, but these NPoAs can
>actually be geographically far from each other. In other words, a zone is a
>set of NPoAs that are grouped together for administrative purposes, not
>because they are close to each other (which they need not be). When we are
>dealing with wireless mobile terminals, this grouping based on the
>geographical location becomes important and thus my opinion is that we
>should consider the LA concept already in the first phase.
>- 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Q&a.hwd
Type: application/octet-stream
Size: 12281 bytes
Desc: not available
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/19991105/a4b18ad0/attachment-0004.obj>

More information about the sg16-avd mailing list