Report of the Cannes meeting

Roy, Radhika R, ALTEC rrroy at ATT.COM
Tue Jun 30 08:04:58 EDT 1998


Dear Mr. Toga:

Yes, I agreed to bring more concrete proposals along the line that I stated.
A good amount of work is needed in this area.

Sincerely,

Radhika R. Roy
AT&T

> ----------
> From:         Jim Toga[SMTP:jim.toga at INTEL.COM]
> Reply To:     Mailing list for parties associated with ITU-T Study Group
> 16
> Sent:         Monday, June 29, 1998 3:51 PM
> 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