[H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H & a question about BEs

[Roy, Radhika R, ALCOO]

Hi, Jaakko:

I am glad that you have clarified most of the points. Let me add a little
more in this area from Annex G point of view as follows:

1. GK and BE are assumed to be co-located (that is, no protocol has been
defined yet between the GK and the BE).
2. We will be within the framework of H.225.0 Annex G and base H.323
protocol if our H.323 mobile architecture and protocol follow the simple
logic considering VLF, HLF, and AuF are the H.323 backend services where
H.323 functional entities like GKs and BEs need to communicate:

GK <-> VLF; GK <-> HLF; GK <-> AuF; GK <-> any other new entities;
BE <-> VLF; BE <-> HLF; BE <-> AuF; BE <-> any other new entities;

3. The protocols/architecture that are NOT within the jurisdiction of base
H.323 or H.225.0 Annex G spec are as follows:

HLF <-> VLF; AuF <-> VLF; or HLF <-> AuF

So, we need to focus only on item 2 for now as long as we consider that we
are working within the framework of H.323 protocol and architecture because
it extends the H.323 protocol to support "mobility."

For item 3, it is completely outside the scope of H.323 and we are NOT
authorized to do this. A new question may be opened to address this area
because it is nothing do with H.323 protocol. This area is not only true for
mobility, but this is also true for security, QOS, billing, directory,
management and others as well. These are NEW protocols, not the extension of
H.323 protocol.

Definitely, we may have to address how we define home/foreign
(visiting/serving, visited, target) GKs/Zones/Domains.

Similarly, we may have to define home/foreign (visiting/serving, visited,
target) BEs.

The only comment that I have for the "home" BE is: How do we define the
"home" BE element uniquely assuming that a domain may have more then one BE.
Please note that this is not the case in defining the "home" GK because a
use can directly register with the GK (this is not the case with the BE).

Let us have more discussion on this topic.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Jaakko Sundquist [mailto:jaakko.sundquist at NOKIA.COM]
Sent: Thursday, July 27, 2000 3:56 AM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H &
a question about BEs


Hi Radhika et al,

As I said, this issue has been brought up several times in the past. Your
contribution APC-1770 is a good example of that. Also Mr. Kumar's APC-1780
included the idea of using Annex G, Lucent had a contribution talking about
Home and Visited BEs in Geneva (February) and so on (I remember doing a
contribution for the Red Bank meeting along similar lines). So the idea has
been around and I'm certainly taking your contribution into account when I'm
doing my proposal about the Annex G protocol usage.

You're also right in saying that the current Annex H architectural model
breaks the H.323 model by allowing communications between VLFs and HLFs in
different domains without going through the BE functionality. The H.225
Annex G clearly states that all Inter-domain communications should go
through the BEs.

Now, I have a bit of a philosophical question about the nature of the BE
functionality. H.225 Annex G defines a protocol for the usage in
communications between the BEs. So, is the BE functionality defined as being
the (only) functionality that is capable of understanding the Annex G
protocol? If that is so and we want to use this protocol in the
communications between the Mobility functional elements (e.g. VLF, HLF), it
would actually mean that the Mobility functional elements would have to be
BEs as was suggested by the Lucent contribution in Geneva.

On the other hand I remember a discussion in Osaka about allowing the usage
of the Annex G protocol also between GKs inside one domain, which would
indicate that the BE is not defined as being the functionality that knows
the Annex G protocol, but rather, as its name states, just the edge point of
a domain. If this assumption is true, I would suggest that we should be able
to use the Annex G protocol between the Mobility functional elements inside
a domain (and also between a GK and a VLF, for example) and convey all
Inter-domain communications through the BE, thus getting rid of the
interface between the VLF and HLF across the domain boundaries.

Anyway, I think that the statement about only using the BEs in the
Inter-domain communications is intended to rather say: "Inter-domain
communications are only allowed by using the Annex G protocol". Since we are
talking about BE functionality which, at the moment, can not even exist on
its own in a network element, it is trivial to just glue the BE
functionality to each functionality that we wish to be using the Annex G
protocol (thus forming "composite" network elements, such as VLF/BE and
HLF/BE). If we still want to keep the statement about the BEs being the only
connection points between domains and still wish to use the Annex G protocol
for communications between the Mobility functional elements, that is what we
need to do.

-Jaakko

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com