FYI only
Edgar Martinez [1]
martinze at CIG.MOT.COM
Mon Nov 8 22:00:24 EST 1999
Hi, Ed:
Kindly see my reply.
Best regards,
Radhika
> -----Original Message-----
> From: Edgar Martinez [1] [SMTP:martinze at CIG.MOT.COM]
> Sent: Monday, November 08, 1999 12:26 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: H323 mobility: Summary of discussion
>
> Hi Radhika,
>
> "Roy, Radhika R, ALARC" wrote:
>
> > Hi, Ed and All:
> >
> > I understand your point. As I explained that contributions with solution
> > have been provided based on "Home and Visited" solving the mobility
> > problems.
> >
> > All members are welcomed to provide solutions based on their concepts.
> If
> > the alternate solutions are provided based on contributions we will
> > definitely be able to see how solutions are provided based on alternate
> > ideas or terminologies. Then, we will have wonderful opportunities to
> > compare each idea or terminology without any confusion or ambiguity.
> > Definitely we are waiting to make compromises if we collectively see
> that it
> > makes sense to do so when we see that there are better solutions
> available
> > based on alternative approaches.
> >
> > We are only in definition phase. These are the place holders. If the
> > architectural solution that we will be agreeing with does not support
> those
> > definitions or terminologies we will definitely change these. There
> should
> > not be any doubt about this. I do not see why we should hold-off our
> > discussions for these two terms.
>
> > As an Editor, I suggest that you can put a
> > note that "some members have some objection to agree on these two terms,
> but
> > we will revisit these terms when we finalize our architectural
> solution."
> >
>
> Noted
>
> >
> > We will have an architectural discussion in the upcoming conference
> call. We
> > have invited contributions with proposed solutions to have all ideas
> clear
> > so that we can move forward.
> >
>
> >
> > Finally, Ed - what we are looking for is the solution of the problem
> (not
> > adding or deleting some terminologies here and there).
>
> We have plenty to solutions, but weak definitions.
>
[Roy, Radhika R] If it is so, the logical step is to examine all
solutions to understand them better and let us come back to make the
definitions stronger once we agree on the solution.
[Roy, Radhika R] The other alternative is to go on defining terms
that may consist of both "strong" and "weak" definitions and let us move on
to the solution area. Then we come back what we do about the "strong" and
"weak" definitions because our goal is the solution.
[Roy, Radhika R] The bottom line is: Let us move on to find the
solution.
> Thanks
>
> >
> >
> > Hope this email will clarify your concern.
> >
> > Best regards,
> > Radhika
> >
> > > -----Original Message-----
> > > From: Edgar Martinez [1] [SMTP:martinze at CIG.MOT.COM]
> > > Sent: Friday, November 05, 1999 6:31 PM
> > > To: ITU-SG16 at MAILBAG.INTEL.COM
> > > Subject: Re: H323 mobility: Summary of discussion
> > >
> > > To the Mobile Ad-hoc Colleges:
> > >
> > > What we have here is an opportunity to build a good
> > > working relationship. But, it seems at this time,
> > > we are in feeling out stage. Solutions and proposals
> > > are being worked within companies and in
> > > difference standards, which want to find a
> > > place in the work we are doing but, I think
> > > compromise is in order.
> > >
> > > The only thing I was suggesting in by email,
> > > was that the word "Home and Visited" bother soon
> > > of our colleges. So my suggestion was to persevere
> > > the functions and compromise on the naming of the functions.
> > >
> > > By definition, whatever we put in the H.323 mobility
> > > document will have to be in the
> > > context of the H.323 framework baseline.
> > >
> > > Lets keep an open mind as we move forward,
> > > Y peace. We all may learn something and discover
> > > new things. If possible lets start looking on compromise
> > > solutions that satisfies all involved. Once we limit our
> > > scope it limits us from progressing towards the future.
> > >
> > > Best Regards,
> > > Ed
> > >
> > > "Roy, Radhika R, ALARC" wrote:
> > >
> > > > 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 to 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
> > > > [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/
> > >
> > > --
> > > 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/
>
> --
> 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