Report of the Cannes meeting

Roy, Radhika R, ALTEC rrroy at ATT.COM
Wed Jul 1 16:16:55 EDT 1998


Dear Mr. Cordell:

I fully agree with you. This is what heard in the Cannes meeting.

I would have been somewhat happier if I would see this viewpoint that has
been expressed in your email would have been included in the Cannes meeting
report (APC-1425).

My question is:

Will Mr. OKUBO be pleased to include at least this viewpoint in the final
Cannes report?

Sincerely,

Radhika R. Roy
AT&T
USA
Tel: + 1 732 949 8657
email: rrroy at .att.com

> ----------
> From:         Pete Cordell[SMTP:pete.cordell at BT-SYS.BT.CO.UK]
> Reply To:     Mailing list for parties associated with ITU-T Study Group
> 16
> Sent:         Wednesday, July 01, 1998 12:20 PM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      Re: Report of the Cannes meeting
>
> 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