Hi, Jaakko:
Pl see my reply enclosed below.
Best regards,
Radhika
> -----Original Message-----
> From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM]
> Sent: Thursday, November 04, 1999 8:48 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> 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.
[Roy, Radhika R] Please be happy to take your time. There is no
hurry. We have a great responsibility to have the best standard that people
can ever collectively think of. So, please provide your best thoughts even
if you think that you should need to take rest.
> 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.
>
> THE PLACEMENT OF HLF/VLF AND THE HOME/VISITED ZONE DISCUSSION
>
> 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.
[Roy, Radhika R] I agree on your first point. To associate HLF/VLF
with only a "single" GK is an implementation issue. It is NOT a protocol
issue. Here we are mixing between mobility protocol vs. implementation. Let
me explain. In H.323, the protocol is GK-centric. So, the mobility protocol
should be developed to abide by this fundamental principle. That is, the
mobility protocol characteristics should be such that it will not impose any
restriction to obtain a service per GK basis. In fact, what you are asking
is this: If the HLF/VLF function is associated with a "single" GK, what
happens to the mobility protocol. How does the H.323 mobility protocol allow
us to have this service. This is a valid question. How do we achieve this
goal? Let me answer your question: We will build the protocol in such a way
that will NOT restrict this particular implementation.
[Roy, Radhika R] To me (as well as to others as well I guess),
HLF/VLF is another function that resides behind a GK (similar to functions
address and other information). I do NOT see that there is a need to develop
a backend protocol between the GK and HLF/VLF right now. In the same token,
H.323 has not yet defined the backend protocol between the GK and the
directory server. If needed, it may be in the next stage of standardization.
However, contributions may be brought to drive this work anytime.
[Roy, Radhika R] In fact you might also see AT&T contributions
submitted during the development of inter-domain protocol (H.225.0 Annex G).
We have shown that the GK architecture can be distributive, centralized
(hierarchical), and/or hybrid. Your proposal to associate HLF/VLF with a
single GK will create a centralized (hierarchical) GK architectural model.
However, H.323 mobility protocol should be robust enough to take care-of all
GK architectural models: distributive, centralized (hierarchical), and/or
hybrid.
[Roy, Radhika R] I guess that I have answered your question.
> 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.
[Roy, Radhika R] As it mentioned that H.323 is GK-centric. A GK
control a zone. To track mobility problem, there should be a point of
reference. To make point of reference that is consistent with the H.323
existing architecture, we need to use it without breaking the fundamental
concept of H.323. We have to maintain the continuity of the existing H.323
architecture. If we can solve problems with the framework of existing H.323
architecture, why do we need to confuse by creating new terminolgies? I like
to see a complete proposal solving all mobility problems (as AT&T and
Motorola contributions) justifying the need for creation of new terminolgies
as you are proposing. Nokia's contribution proposes some ideas in a
high-level manner. What is needed, like AT&T and Motorola contributions,
provide a complete solution first. Then, we will compare all solutions
together. Otherwise, it is still hypothetical to accept you arguments.
> 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.
[Roy, Radhika R] Again, in H.323, a use has to register with a GK.
It is a MUST. However, a user can also choose some alternate GKs. It is an
OPTION. This is the fundamental architectural concept of H.323. We have to
start solving our mobility problems based on this foundation. Home GK/Zone
concept is based on this foundation to have a reference to start with in
order to solve mobility problems. If we can solve H.323 mobility problems
based on the basic foundation what already exists in H.323, why do need to
invent new terminologies? As I mentioned earlier, like any other functions
in H.323, HLF is also another function is obtained by users via the GK.
Please note very carefully as I also mentioned in my earlier email: Like
address information (e.g., alias, transport/network addresses, etc), HLF
function is also obtained via the GK. Now to track the mobility problem,
there needs to be a reference point in the context of H.323 architecture. To
solve this problem, it is found that it is a better choice to associate a
use with a "home" GK because a user, as H.323 requires, must register with a
GK. (Please note that there can also be a backend server behind the GK to
provide the HLF service. This is another level of standardization. As I
explained, similar to the directory service, H.323 also does not need to
define this backend protocol right now. However, contributions are welcomed
in this area as well.)
> 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).
[Roy, Radhika R] Again, we have to look into the existing H.323
standard. What does it say? Does it not require that a use must register
with a GK? However, there can also be alternate GKs. Using the same basic
foundation of H.323, it is logical that a user will register with a GK. To
track the mobility, it is a logical choice to have reference point. This GK
is designated with a GK known as the home GK. Per existing H.323 standard, a
user can also have alternate GKs as an order of priority. In the same token,
a user is also free to declare alternate home GKs as an order of priority.
AT&T contribution has provided a complete solution how extension of RAS
messages will take care-of this problem automatically. In this context, this
approach of mobility is perfectly consistent with exiting H.323 standard.
> 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.
[Roy, Radhika R] Not necessarily. HLF/VLF is one of the functions.
HLF/VLF may have user profiles in terms of personal IDs and other functions.
Personal IDs are nothing but some new alias addresses. So, an extension in
"H.323 alias address" will take care-of personal IDs. Similarly, other
functions of user profiles can be taken care of with similar extensions.
More importantly, home/foreign zone concept helps to solve H.323 mobility
problems when users move from one place to another in reference to the H.323
architectural entities (e.g., zones, transport address [TCPs/UDPs: call
control, media control, RAS signaling], network addresses [e.g., IP, ATM],
domains, etc.). No one should underestimate what the mobility in the context
of H.323 means. There are fundamental differences between the so called
traditional "plain Vanilla" mobility defining in HLF/VLF in the circuit
switching world and the H.323 mobility. Please see AT&T contribution how the
complex H.323 mobility problem has been solved simply through extension of
RAS messages and some new messages. Please all see Motorola's contribution
in this context.
> 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?
[Roy, Radhika R] Please see my above answer how this complex
mobility problems are solved very beautifully in terms of primary GK and
alternate GKs in the context of existing H.323 standards. We do NOT need to
invent any new terminologies (e.g., location area [LA] or others). Please
see AT&T contribution how the complete solution has been provided right
within the context of existing H.323 standard. In this context, Motorola's
contribution can also been seen.
> 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.
[Roy, Radhika R] Both AT&T and Motorola's contributions provide
solutions without inventing new terminologies. If needed, as pointed out
earlier, we like to see a complete contribution from Nokia that solves all
mobility problems using the new terminologies as it is done in AT&T and
Motorola's contribution. Otherwise, it is still a very high-level concept
such as home/foreign domains. My fear is that it may break the fundamental
architectural concept of the existing H.323 standard. So, far I have NOT
seen any reason to believe why the solution provided by AT&T complementing
the existing H.323 architecture should be modified. I also see that
Motorola's contribution is also providing the mobility solution within the
framework of existing H.323 architecture. Before, we deviate from the
fundamental concept of H.323 architecture, we like to see a complete
contribution from Nokia similar to AT&T's. Only then, we will be able to see
the merit of Nokia's proposed architectural concept.
> THE TWO-STEP APPROACH DISCUSSION
>
> 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
> rambling...
>
> THE LOCATION AREA DISCUSSION
>
> 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.
[Roy, Radhika R] The network point of attachment has been taken
care-of. As I told before, a complete contribution has to be provided how LA
concept will be useful to solve the mobility problem. AT&T has provided a
complete solution providing architecture, signaling messages, call control,
mobility management, and ASN.1 of RAS signaling messages. The contribution
has shown how mobility problem is solved in the context of existing H.323
architectural concept. Nokia has to do the same to understand the merit that
H.323 mobility problem cannot be solved as it is shown AT&T's contribution
without using LA, home/foreign domain concepts as proposed by Nokia.
Motorola's contribution can also be seen for this purpose.
> - 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.
> -------------------------------------------------------
