Report of the Cannes meeting
Pete Cordell
pete.cordell at BT-SYS.BT.CO.UK
Wed Jul 1 13:20:14 EDT 1998
My understanding of the meeting was that APC-1422 was considered as good
a place as any to start with a development, but there was acceptance
that the final result may differ radically from what is in APC-1422, and
we didn't want to preclude any other solution that we might find that
was either already written, so somehow fitted our needs better than the
framework that was out lined in APC-1422. It's my recollection that it
was the view of the Intel delegates that this was a satisfactory
situation.
Regards,
Pete
=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell at bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================
>----------
>From: Jim Toga[SMTP:jim.toga at INTEL.COM]
>Sent: 29 June 1998 21:51
>To: ITU-SG16 at MAILBAG.INTEL.COM
>Subject: Re: Report of the Cannes meeting
>
>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