H323 mobility: Summary of discussion
Roy, Radhika R, ALARC
rrroy at ATT.COM
Fri Nov 5 09:19:59 EST 1999
> -----Original Message-----
> From: Roy, Radhika R, ALARC
> Sent: Friday, November 05, 1999 9:12 AM
> To: 'Mailing list for parties associated with ITU-T Study Group 16'
> Subject: RE: H323 mobility: Summary of discussion
>
> Hi, Ed and All:
>
> I do not know whether you have seen my reply to Jaakko. I am enclosing it
> again. Please respond to my reply provided Jaakko to prove your statement.
>
> I completely disagree with Ed. Please also see Marc Roelands's comments on
> LA.
>
> AT&T contribution has shown how H.323 mobility problem can be solved using
> home/foreign GK (zone).
>
> I like to see the complete H.323 mobility problem that has been solved
> using the alternative approach as proposed by Nokia. I have NOT seen
> Nokia's solution yet. Unless a complete solution is provided like AT&T's,
> I am NOT convinced how mobility problem can be solved in a better way.
>
> I also see that there is a need for HLF/VLF. No one against the HLF/VLF
> function. AT&T proposal also has shown how HLF/VLF function is taken
> care-of.
>
> What I disagree with is this: A protocol should NOT be implementation
> specific. For example, we do have a luxury to build one protocol for
> distributive GK (HLF/VLF) function, one protocol for centralized GK
> (HLF/VLF) function or one protocol for hybrid GK (HLF/HLF) function. It is
> against the fundamental concept of H.323. For example, the same argument
> can also be applied for the directory function. Similar may the case for
> other functions as well. It is a complete break down of H.323 protocol and
> architecture.
>
> So, HLF/VLF is another function in H.323. HLF/VLF is NOT a "Holy Grail"
> for which we have to create a complete "DISCONTINUITY" in existing H.323
> protocol and architecture. I like see to Nokia's alternate solution to
> disprove this fear.
>
> Nokia has to bring a complete contribution providing solution like AT&T's
> to prove their case. Otherwise, we cannot proceed with a concept that has
> not proved with a solution.
>
> The problem can be solved as follows:
>
> 1. Let Nokia provide a complete proposal solving the H.323 mobility
> problem using heir alternative approach. What Nokia has provided is a high
> level concept. They have NOT solved the problem yet. Let us see what the
> complete solution is. If a solution is provided, we can then compare
> Nokia's solution with that of AT&T's solution. Otherwise, their proposal
> is still HYPOTHETICAL. It is a concept, NOT a solution.
>
> 2. How can we agree on a concept without seeing its solution that has the
> potential to break down the fundamental architecture of existing H.323
> standard?
>
> 3. Let us solve H.323 mobility problem within the framework of H.323.
>
> 4. Let us move on with contributions for the part that we can agree on. If
> Nokia brings a complete solution, we will definitely re-consider their
> case.
>
> 5. I agree with you that we also need to work for interworking between
> H.323 (IP) mobility and cellular-PSTN/ISDN network.
>
> Finally, Ed - you have made a statement, but it has to be proved providing
> a solution. An alternative concept is there, but we have not seen its
> solution yet. What is the problem to bring the alternate solution? Why do
> we need to wait for a concept that has NOT been substantiated with a
> solution yet?
>
> Best regards,
> Radhika
>
> -----Original Message-----
> From: Edgar Martinez [1] [SMTP:martinze at CIG.MOT.COM]
> Sent: Thursday, November 04, 1999 9:47 AM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: H323mobility: Summary of discussion
> Importance: High
>
> I agreed with most of Jaakko comments and also
> make vaild points, and will like to
> add the following.
>
> I believe that the (Home) in Home Zone should be taken out.
> What we are talking about is the User's Point of Attached in
> any given Zone. The HLF is ready and Data base
> which has the User's profile and the current user's location.
> We can get a new name to HLF and call it the Location Profile
> Register (LPR) or Location Profile Function (LPF).
>
> I also believe that the (Visited) in Visited Zone sould also
> be taken out because again we are talking about
> the Users current Point of Attachment in any given Zone.
> The VLF has the means to update the
> Location Profile Register (LPR) from
> any given Zone. We can get a new name to VLF
> call it the Location Update Register (LUR) or
> Location Update Function (LUF).
>
> Now we can also support concepts of Zone ID's
> such as Current Zone ID and Previous Zone ID.
>
> Finally,
>
> And I strongly agree with looking at the interworking
> in parallel with H.323 mobility. The time we spent
> now looking at interworking will be compensated in the
> long run. I sure does working on ISUP, IN and Qsig, inetrworking
> with H.323 would agree and we should learn from their experience.
> And not leave it for a last minute add-on.
>
> Lets take the contribution as they come, if one wants to put in
> interworking fine. If one wants to put in contributions only H.323
> mobility also fine. Both are in order and within our scope.
>
> The general strategy should focus on ensuring that the H.323
> Mobility and interworking options are enabled, rather than spending
> too much effort blocking alternative options (Our limited resources
> frankly don't allow this luxury). But there really is no substitute
> for
> doing the work - preparing input papers and presenting them
> to move things forward.
>
> Best Regards,
>
> Ed
>
Hi, Jaakko:
Pl see my reply enclosed below.
Best regards,
Radhika
-----Original Message-----
From: Jaakko Sundquist [SMTP:jaakko.sundquist at NOKIA.COM]
Sent: Thursday, November 04, 1999 8:48 AM
To: ITU-SG16 at 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.
-------------------------------------------------------
>
> [Roy, Radhika R] 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
> --
> Edgar Martinez - Principal Staff Engineer
> Email mailto:martinze at cig.mot.com
> FAX 1-847-632-3145 - - Voice 1-847-632-5278
> 1501 West Shure Drive, Arlington Hgts. IL 60004
> Public: TIPHON & Other Stds - http://people.itu.int/~emartine/
> Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/
More information about the sg16-avd
mailing list