H323 mobility: Summary of discussion

Edgar Martinez [1] martinze at CIG.MOT.COM
Mon Nov 8 12:25:49 EST 1999


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.

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