Mob ad hoc group progress (ignore the previous mail)

Roy, Radhika R, ALARC rrroy at ATT.COM
Thu Apr 6 14:27:01 EDT 2000


Hi, Everyone:

Contributions are there or are underway in explaining the things. I am not
sure whether the explanation provided by Jakko is clarifying all logical
steps that I have mentioned. Let us see the contributions in explaining the
things.

H.323 has building blocks: zone and domain (adm). A zone may have one or
many networks. A domain may have one or many zones.

A domain may be home or foreign (visiting/visited/target) from mobile user
point of view.

Similarly, a zone can be home of foreign (visiting/visited/target) from
mobile user point of view.

In the same token, a network can be home of foreign
(visiting/visited/target) from mobile user point of view.

With respect to VLF, it is an entity already defined. Its function is well
defined. Where can it be located? It is primarily an implementation issue
(not protocol issue). Let contributions explain this. If someone wants to
co-locate it with the GK, it is fine. If not, .... then what? Similar is the
case with HLF.

We will go from Figures 1, 2, 3, ... and so on of Nokia's contribution
MD-011.

Again, let us not mandate anything beforehand. let contributions explain
pros and cons and we will go from there. Let us not be afraid of explaining
the things in contributions.

Hope this will further clarify the things.

Best regards,
Radhika R. Roy
AT&T


> -----Original Message-----
> From: Jaakko Sundquist [SMTP:jaakko.sundquist at NOKIA.COM]
> Sent: Thursday, April 06, 2000 4:12 AM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      Re: Mob ad hoc group progress (ignore the previous mail)
>
> My comments did not show too clearly in the last mail due to the wonderful
> M$ Outlook settings, so I'm resending this...
>
>
> Hi all,
> Comments to Radhika's posting below...
> >
> > Hi, Everyone:
> >
> > We are again not in sink what is going on with respect to
> > progress of our
> > work. Let me try again.
>
> That is just what I was trying to say...
>
> >
> > We have talked about Nokia's contribution MD-011. We have
> > taught that this
> > provides a reference to start with. In that contribution, we
> > have Figure 1:
> > Intra-zone all H.323 scenario. We have decided that we will
> > go one step at a
> > time.
> First of all the scenario is called all-H.323 scenario. The
> figures just try to explain what kind of call models that scenario
> involves.
>
> What we have decided is to go one scenario at a time (not one "call model"
> at a time).
> Furthermore, it was evident in the last teleconference that the cases
> illustrated in the figures were not adequate and they need to
> be enhanced.
>
> >
> > Now what does this Figure 1 provides us? We are NOT sure
> > unless we explain
> > in detail what this scenario means to us. We cannot go to the
> > next step
> > unless we analyze what the scenario of Figure 1 provides us.
> > It may or may
> > not provide new insights from H.323 mobility point of view,
> > but it is our
> > starting point. We have to complete it first before we go for
> > the next step.
> > In this simple case, a mobile entity will move from its home
> > network to a
> > foreign network. This also requires mobility management:
> > Change in network
> > point of attachment and its possible impact in H.323 system.
> >
> This is just what I mean. What do you mean by the above text?
> First of all I don't know what you mean by home and foreign network. Are
> you
>
> saying that inside one zone there are multiple networks (so that moving
> from the home network to a visited network is possible while all the time
> being located inside the same zone)? You are right in saying that we need
> to
> analyze this
> call model also, but first we need to identify the different cases for the
> user's location, i.e. both users at home domain, user-A at home domain &
> user-B in a visited domain, etc.
> Related to the above, we have already defined the terms Home
> Administrative Domain, Visited Administrative Domain and Serving
> Administrative Domain in the draft H.323 Annex H. I think that these
> definitions are very good
> (thanks to Milo, you see that we do agree on some things once in a while
> ;-)
> and they clearly bind the subscription of a user (or a subscriber) to a
> Domain. My opinion is that this means that the Administrative Domains are
> the areas that divide the H.323 system into home and visited areas from
> the
> point of view of the user. In other words, I wouldn't necessarily even
> define terms, such as, Home Zone or Home Gatekeeper, because the above
> definitions already bind the home of a user to the whole domain, not a
> particular zone. If we want to define the term Home Zone, I think it
> should
> mean ANY zone inside the Home Administrative Domain,
> similarly a definition for the Home Gatekeeper could be made.
> Based on the above, we can assume that when a user is in his/her Home
> Administrative Domain, the HLF that contains his/her information is also
> inside that Domain and inter-domain communications are not needed for the
> Mobility Management of that user. Similarly, if the user is in a Visited
> Administrative Domain, inter-domain communications are needed for the
> Serving Administrative Domain to contact the user's HLF. This will also
> lead
> to different location management cases for e.g. the intra-zone all-H.323
> call model.
>
> >
> > Once we complete Figure 1, we will go for the next one:
> > Figure 2 Inter-Zone
> > all H.323 scenario. Of course, this is a complicated one to
> > provide better
> > scenario for mobility management: Change in network point attachment +
> > Change in zone (logical) point of attachment as well.
> >
> I think that this is a good way for an individual to work,
> but personally I would like to see contributions that address more of
> these
> call models at a time. We can, of course, deal with the contributions in
> the
> order that
> Radhika is proposing, I have nothing against that.
>
> > A side note: We have defined VLF and HLF. VLF may be assumed to be
> > co-located within the GK. But let people explain the
> > interactions including
> > VLF and HLF the way they prefer in their contributions. The
> > contributions
> > themselves will justify how VLF and HLF should perform their
> > functions. Let
> > us not mandate anything beforehand unless things are explained in the
> > contributions.
> >
> One thing I would like to ask the ad hoc group members, is
> that should we assume at this point that the VLF is co-located with the
> gatekeeper (as a "composite network element" illustrated in Figure 3 of
> the
> draft H.323 Annex H). I think this could be a good assumption in the first
> version of Annex H, because it seems that most of us are thinking that way
> already. It would only mean that we wouldn't have to specify anything for
> the
> reference point E, but leave it open in the first version of the annex,
> similarly as was done with reference point B in the H.225.0 Annex G. Other
> composite network elements could also be identified for the first version
> of
>
> the annex. I think that this kind of grouping could conciderably simplify
> our work for the first version by reducing the number of interfaces that
> we
> need to
> specify. We should probably encourage contributions proposing
> the composite network elements and perhaps discuss these contributions in
> a
> teleconference (maybe not the next, but the one after that).
>
> - Jaakko



More information about the sg16-avd mailing list