Report of the Cannes meeting
Jim Toga
jim.toga at INTEL.COM
Mon Jun 29 16:51:40 EDT 1998
Dear Mr Roy,
Although I was unable to attend the meeting in Cannes, I have read all the
previous reports and have spoken to a number of people that attended.
There were many discussions during the meeting, which are summarized in
the meeting report without re-hashing every detail. My understanding is
that there were no objections from _anyone_ else at the meeting to
progressing the work that has been started in APC-1422. The intent will be
to have both telephone and email exchanges to further develop this work.
I would look forward to having your constructive input as we move forward.
In the spirit of this, I would like to elicit your input here.
I would like to point out a couple of misconceptions you might have based
upon the text below and ask you for some concrete proposals in areas where
you feel they're needed...
Best Regards,
jimt.
[SNIP]
>
>Section 5.5.4 H.225.0 V3 Annex G (GK to GK Communications)
>
>APC-1385 [AT&T] "Framework for H.323 Inter-Gatekeeper Communications"
>
>Mr. Roy also pointed out the following:
If these points were raised in the APC document and covered during the
meeting why do they need to be called out explicitly in the meeting report?
The list of contributed documents is part of the meeting.
>
> * H.323 signaling schemes that were developed for
>H.323v1 in view of the LAN-based single GK model
Both v1 and v2 have never limited GK deployment to one entity (on the LAN
or any other topology) The defined signalling for address resolution
allows for N gatekeepers.
>(signaling schemes in
>H.323v2 also remain almost the same so far the inter-GK communication is
>concerned) may not be good enough to satisfy all needs when it is applied in
>the context of multiple gatekeeper environment with different inter-GK
>architectures: Distributive, Centralized, and Hybrid (Distributive +
>Centralized).
(I think you mean 'Distributed' above) In any case, these different modes
of operation define models with respect to _media_ distribution, not
control. In this case they would (and do) affect the operation of an MCU.
(this is not to say that the MCU can't be co-located with the GK).
V1 and V2 (and certainly the intent with V3) allow for many different GK
topologies with hierarchical being one of the more general ones. Flat
peer-peer models may be accomplished by having a degenerative 'hiearchy'
with a depth of 1.
> * Each inter-GK architecture may need different
>signaling schemes in order to optimize the use of communication resources
>especially in the context large networks for both connectionless and
>connection oriented networks.
Can you eloborate on this? Are you simply saying that we need to allow
both UDP and TCP signalling (which is in fact specified in section 4 of
APC-1422).
>
>APC-1422 [Intel] "Proposal and General Comments for Inter-Gatekeeper
>Communications"
>
>During the discussion of Intel's contribution, Mr. Roy also pointed out that
>this proposal appears to have the following limitations:
>
> * The relationship between the zone (or internal) and
>the border (or domain) gatekeeper is not defined: is it hierarchical or
>what?
As described in section 2 of APC-1422 the only difference (in terms of
protocol interactions) between a GK acting as 'border GK' and an
'internal' GK is that fact that the border GKs may communicate with border
GKs from other administrative domains. There are no specific models of
deployment within an admistrative domain. Some organizaitons will choose
to develop a hierachical model, others may choose to have a star topology,
or perhaps a flat domain. It makes no difference to the signalling between
administrative domains and the current signalling can facilitate all of
these models. Can you offer any specific topologies that you believe will
not work and cannot exploit this signalling?
> * Does it mandates the use of proprietary protocols
>between the zone (or internal) and domain (or border) gatekeeper?
It certainly does not _disallow_ proprietary protocols, but the intent
would be to support standard messages internal to an adminstrative domain
(which may be made up of a number of zones BTW...) as well as using these
standard messages between administrative domains.
> * The relationship between the multiple domain
>gatekeepers has not been defined: how communications occur in view of the
>multiple domain gatekeepers?
The definition of 'relationship' is multi-faceted. Many of the aspects of
a 'relationship' may in fact be business related, and outside this realm.
One of the points of annex G is to provide some signalling which will allow
administrative domains (again an organizational term, not a formal H.323
topology term) to exchange information so that they can define the
"relationship between the multiple domain..."
> * As if it mandates a specific implementation scheme
>that may limit its scalability once one starts to use the gatekeeper
>discovery, address translation, admission control, and/or bandwidth/QOS
>control signaling messages for this particular architecture while a large
>network that may use highly distributive, centralized, and hybrid inter-GK
>architecture.
I'm really not sure what you asking/saying here...can you clarify this?
>
>Therefore, Mr. Roy has the following view:
>
> * It requires a fundamental understanding of the
>logical relationships for inter-GK communications in view of the
>distributive, centralized, and hybrid inter-GK architecture that might be
>scaleable in view of large networks for both connectionless and connection
>oriented networking environment.
I think you mixing a number of things here (some of which have no
relevance). Can you break this up unto a number simple points - so that a
simple person such as I can understand? :-)
> * AT&T's contribution (APC-1382) has been the first
>step in that direction.
You may note that a number of the definitions and clarificaitons from
Yokuska to Cannes were a direct result of APC-1382 - thank you.
>
>----------------------------------------------------------------------------
>----------------------------------------------------------------------------
>---
>
>I would appreciate a prompt action from your end.
>
>Sincerely,
>
>Radhika R. Roy
>AT&T
>Room 1K-330
>101 Crawfords Corner Road
>Holmdel, NJ 07733
>Tel: +1 732 949 8657
>Fax: + 1 732 949 8569
>e-mail: rrroy at att.com
>
>
>> ----------
>> From: Sakae OKUBO[SMTP:okubo at GITI.OR.JP]
>> Reply To: Mailing list for parties associated with ITU-T Study Group
>> 16
>> Sent: Thursday, June 25, 1998 11:49 PM
>> To: ITU-SG16 at MAILBAG.INTEL.COM
>> Subject: Report of the Cannes meeting
>>
>> Dear Q.12-14/16 experts,
>>
>> I have uploaded draft report of the Cannes meeting (APC-1425) at the
>> /Incoming directory.
>>
>> ftp://standard.pictel.com/avc-site/Incoming/APC-1425_w97.zip
>> /APC-1425_w95.zip
>>
>> w97 is original, editing TD-20 (Q.12), TD-21 (Q.13) and TD-22 (Q.14)
>> with Word 97. w95 is a version converted into Word 6/95; there are
>> obvious errors in section numbering and figures.
>>
>> Please review it in a week time, and give me any comments. I will then
>> complete it, uploade it at /9806_Can directory and send its copies to
>> the SG16 management.
>>
>> Best regards,
>>
>> Sakae OKUBO (Mr.)
>> ***********************************************************
>> Waseda Research Center
>> Telecommunications Advancement Organization of Japan (TAO)
>> 5th Floor, Nishi-Waseda Bldg.
>> 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo
>> 169-0051 Japan
>> Tel: +81 3 5286 3830
>> Fax: +81 3 5287 7287
>> e-mail: okubo at giti.or.jp
>> ***********************************************************
>>
>
>
*****************************************************
*** +1-503-264-8816(voice) Intel - Hillsboro, OR.
***
*** mailto:jim.toga at intel.com mailto:james.toga at itu.ch ***
*** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 ***
*****************************************************
More information about the sg16-avd
mailing list