H.225.0 Annex G conference call

[Roy, Radhika R, ALTEC]

Dear Mr. Toga:

I am glad to see that you agree with the concepts that I have provided in my
email. This is exactly what needs to be addressed in the ITU-T SG16 with
respect to H.323 inter-GK communications.

AT&T contribution is expected to be provided to the US State Dept as a part
of that process for the upcoming ITU-T SG16 Geneva meeting. I guess that you
would be almost certain what is going on from AT&T side.

For further clarifications, please see the email that I sent in response to
Mr Purvis comments. I hope that it will clarify.

Please make a note that we need to address the right solutions in the
context of the large H.323 network. Any short sighted solutions that do not
provide the right solutions will create confusions in the market. Let us
avoid this as far as practicable.

If you think that you can provide the solution for a very limited
environment "Non-hierarchical Inter-Gatekeeper Communications Between
(Administrative) Domains", my proposal does not limit that. You are
absolutely welcomed to do that. I doubt whether any progress has yet been
made by anyone to solve the problems for this  environment as well (not to
speak about other models. Does anyone believe that the Non-hierarchical
model described so far is going to be solved right now?). People are only
providing some high-level stuffs with some figures that define some
boundaries. Is there any solution in sight for this hierarchical model?

Again, I request that Annex G should be addressed from the global
perspective as outlined in my email.

We will decide what problems can be addressed in a timely manner and whether
it makes any sense to release a subset of those models as a part of the
standard once we see how far progress has been made in all those areas as
described in my email.

I hope that this email will clarify all issues that you have raised in your
email.

Sincerely,

Radhika R. Roy
AT&T, USA
Tel: (732) 949 8657

> ----------
> From:         Roy, Radhika R, ALTEC
> Sent:         Thursday, August 06, 1998 8:20 AM
> To:   'Mailing list for parties associated with ITU-T Study Group 16'
> Subject:      RE: Zones and administrative domains
>
> Dear Mr. Purvis:
>
> It is little difficult to explain all the details why we like to define
> communications within a given zone. We had many discussions on this
> subject.
>
> If one has to build a large H.323 network (a H.323 network may consist of
> IP, ATM, FR, LAN, and/or other transport networks - in any possible
> combinations), it will require many gatekeepers consisting of many zones.
> The present H.323v2 signaling scheme is inadequate (even non-existence) to
> provide inter-gatekeeper communications between the zones (I am not even
> raising the issues whether any solutions are scalable or not).
>
> Considering this very fundamental problem, AT&T is bringing contribution
> in the ITU-T SG16 September'98 Geneva meeting (the contribution is under
> internal review of AT&T) to solve that problem. This contribution is
> supposed to provide solution that is known as "non-hierarchical"
> inter-gatekeeper communications model. The proposed solution is expected
> to provide inter-gatekeeper communications protocol (IGCP) that will try
> to reuse of the existing H.323v2 signaling with extensions (that is, not
> to create a complete new sets of signaling schemes).
>
> As I mentioned earlier that there can be other solutions as well. For
> example, "hierarchical" and "hybrid (non-hierarchical + hierarchical)".
>
> Once the inter-gatekeeper communications between the zones are addressed,
> then next question comes what happens if the domain is created that
> includes multiple zones. A communication protocol is needed for
> inter-domain communications as well. It is expected that a little
> extension of the IGCP that is used for the inter-zone communications can
> also be applicable for inter-domain communications.
>
> To customize the above schemes in an "administrative domain" environment
> does not require too much work once the fundamental problems are solved.
>
> With respect to my comments on Section 1.5, I need to clarify. I mention
> that AT&T conurbation that is expected to be submitted will use the zone
> message sets. This message set is only one of them. However, there are
> many other message sets that need to be used for IGCP. AT&T's
> contributions will address each one of them, and it will be seen how
> powerful the solution is irrespective of the fact there can "many zones"
> across a large H.323 network.
>
> You are absolutely right (at least from our experience) it is the same
> message set that can be used. The important point is to create the right
> message sets that solve the problems for all situations. AT&T's expected
> contribution will provide all those message sets (hopefully to reuse the
> exiting H.323v2 message sets with extensions) considering
> "NON-HIERARCHICAL" inter-gatekeeper communications model.
>
> I also hope that this response will address many of the questions raised
> by Mr. J. Toga.
>
> The entire H.323 team of ITU-T SG16 is working very hard to provide right
> solutions of this very complex problem. Hopefully, we are near to solve
> this problem (at least I am personally very hopeful to have solutions for
> all models as I described - the upcoming AT&T's contribution will be a
> step in that direction).
>
> Thank you for providing an opportunity to clarify many of the points.
>
> Sincerely,
>
> Radhika R. Roy
> AT&T, USA
> Tel: 732 949 8657
>
>
>
> ----------
> From:         Jim Toga[SMTP:jim.toga at INTEL.COM]
> Reply To:     Mailing list for parties associated with ITU-T Study Group
> 16
> Sent:         Wednesday, August 05, 1998 6:16 PM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      Re: H.225.0 Annex G conference call
>
> Dear Mr. Roy,
>
> I would like to respectively respond to a number of your points but before
> I do, I'd like to make a few general comments.
>
> 1) In general, I agree with many of the concepts and directions that you
> endorse - I see these has helping the long-term market as a whole.
> Although  I have to admit I'm somewhat perplexed at your logic and
> explanations in other points.
>
> 2) There is a clear, immediate, and pressing market need for a standards
> based solution to allow Gatekeepers to communicate between each other in
> standard fashion.  If this work is not completed in the ITU-T in a timely
> manner - it might be completed either by vendors independently, thus
> fragmenting the market, or as a defacto-standard set by a group of
> vendors.
>  My personal preference is to have an open and contributory ITU-T based
> process, for the solution.
>
> 3) I fail to understand the methodology by which you contribute to this
> work.  You have on occasion, offered critizisms and vague alternatives to
> the ongoing work without any tangible technical issues.  Vague statements
> about "contributions from AT&T to be released...in the September ITU-T
> meeting" do not progress this work in a timely or cooperative  fashion.
> For example, I would be interested to hear what specific aspects of
> Diameter you see as appropriate or inappropriate to the issues at hand.
>
> I have made interspersed comments to support and question your text below.
>
> Best Regards,
> jimt.
>
>
> at At 01:35 PM 8/5/98 -0400, you wrote:
> >Hi Everyone:
> >
> >We are in receipt of the revised Annex-G sent by Glenn Freundlich via
> email.
> >It appears that the present Annex G write-up and email are yet to reflect
> >the true essence that had been discussed in the conference calls as well
> as
> >communicated via emails (copies of the emails including Santo Wiryamen's
> are
> >also enclosed). The specific points are mentioned below:
> >
> >1.      The modified title of Annex G is very restrictive, and is NOT
> >acceptable. The title of the Annex G should remain as it was before -
> >"Gatekeeper-to-Gatekeeper Communications". (The communication between
> >administrative domain will only be one of the customized scenarios for
> >communications between the gatekeepers. It is a complete surprise to see
> >such a major change has been made all on a sudden).
>
> Although I disagree that it is "very restrictive", I do agree that the
> Annex should remain titled as it formally was.  My undstanding that this
> change was agreed to in Cannes but simply hadn't been completed by the
> editor (GlenF).
>
> This is separate from the point that the _first issue_ being solved is
> 'Communications _between_ Administrative Domains'.  Perhaps we can all
> wait
> for the upcoming contribution from ATT on 'Communications _within_
> Administrative Domains' and until that time it is for further study.
>
>
> >2.      Section 1.1 (Scope). The scope of Annex G should be
> >"Inter-gatekeeper communications that will include inter-gatekeeper
> >communications within a given domain as well as communications between
> the
> >(administrative) domains". (So, the present objective that restricts for
> >dealing communications between the administrative domains only is NOT
> >acceptable).
>
> We have had numerous (lengthy, repetitive) discussions on this
> terminology.
>  The intent was  to not overlap or otherwise confuse IP 'Domains' with the
> terms here; they are different. (although a specific implementation may
> choose to make the them equivilent).  Inter-gatekeeper communications is
> just that - communications that occurs between gatekeepers.  There are no
> implications as to the applicability of any protocol in one environment
> over another.  This is not to say that specific protocol elements won't be
> enhanced over time, as deficiencies are discovered with practical
> experience.
>
> The point behind your (Roy) last issue (limiting it to
> inter-administrative
> domains) was that the annex would not _start out_ by mandating what
> protocol a vendor/service supplier/administrator uses in the privacy of
> their own network.  This is not to say that they can't use the standard
> protocol.
>
> >3.      Section 1.1 (Scope). It has been mentioned that "It should also
> be
> >understood that Annex G does not mandate a specific system architecture
> >within an administrative domain". This should NOT be a mandatory in the
> >standard. Rather, we can keep this as an option depending on the choice
> of
> >the implementation schemes. That is, the standard MUST provide all the
> >options to reveal about the protocols, organization or architecture
> within a
> >given administrative domain leaving no room for proprietary
> implementations
> >schemes.
>
> I really don't understand what you're saying here.  Are you stating that
> we
> must mandate a particular architecture within an administrative domain
> (enterprise)? Or are you saying that we provide an exhaustive list of all
> the possible architecutures.  Are vendors supposed going to be in
> violation
> of the _protocol_ if they don't arrange their internal network to match
> one
> of the pictures?
>
> I will reiterate from the Cannes meeting report (APC-1425)
>
> " Mr. Roy's position is that the architecture inside the domain should be
> known outside the domain.  He was encouraged to bring in a contribution
> explaining how the lack of knowledge of the intra-domain architecture
> would
> affect services or other technical matters."
>
> I believe you were the only one that held this position.
>
>
> >In view of the above limitations of the present Annex G write-up (Title
> and
> >Section 1.1), the following have been proposed:
> >
> >1.      The title of Annex G should remain as it was before: "Annex G -
> >Gatekeeper-to-Gatekeeper Communications."
>
> Agreed.
>
> >2.      Scope of Annex G should be divided into two parts: A.
> >Inter-Gatekeeper Communications Within a Domain, and B. Inter-Gatekeeper
> >Communications Between Domains.
>
> Agreed, as long as we change 'Domain' to 'Administrative Domain'
>
> >3.      A domain has to be defined further. For example, a domain may
> >consist of multiple zones.
>
> There are currently a number of  zones running within Intel's
> _administrative_ domain (sec 1.2 in Annex G) . Can you explain why this
> needs to be defined further?
>
> >4.      Inter-gatekeeper communications between the multiple zones of a
> >given domain has to be standardized as it has been outlined in Santo
> >Wiryamen's email and APC-1385 (more contributions from AT&T [to be
> released
> >after internal review in the Spetember'98 ITU-T SG 16 meeting] for
> >inter-gatekeeper communications in a given domain that will use
> >non-hierarchical model will be submitted. All other companies are also
> >encouraged to submit contributions in this area. Annex G will be expanded
> as
> >soon as those contributions are received).
>
> There have been a number of contributions in this area (APCs 1382, 1385,
> 1402, 1407, 1414, 1422, TD-14 and many emails on this list) by many
> interested participants.  These have all been with the goal of reaching
> stable text for September.
>
> >5.      A single administrator will also be able to create multiple
> domains
> >for its own internal communications for scalability or other purposes for
> >the large H.323 network. Then, this communication between such domains is
> >known as "Inter-Gatekeeper Communications Between Domains".
>
> We have not defined an 'internal' domain (other than one that completely
> overlaps with the same characteristics in the IP world) so I don't know
> that this is.  I certainly agree that administrators will want to (under
> some cases) carve up and distribute communications/operations within their
> network. We should facilitate that with a protocol - but I fail to see how
> anything that has been proposed/discussed precludes this.  As an example,
> the fact that NAT firewalls exist doesn't mean that everyone _must_ use
> private addressing within their corporation.  Nor does it mean that they
> _must_ use public addressing.  In either case it does not affect
> communications or functionality between corporations.
>
>
> >6.      If a domain belongs to a single administrator, and communications
> >between such administrative domains need to happen, then the
> communication
> >between such administrative domains is termed as "Inter-Gatekeeper
> >Communications Between Administrative Domains".
>
> Yes, and this is the first and most pressing issue to solve.
>
> >7.      The inter-gatekeeper communications between (administrative)
> domains
> >can also be non-hierarchical, hierarchical, and hybrid (non-hierarchical
> +
> >hierarchical). However, present contributions have been provided only for
> >hierarchical models, and non-hierarchical and hybrid models will be
> >addressed as soon as contributions will be received in these areas.
>
> You have stated this before, and it has been refuted (both on email and on
> the phone calls). Please present a specific example in which the message
> information cannot be exchange to cover this model.
> I maybe dense, but I don't understand what a 'hybrid' gatekeeper
> communications is.  I would hope that the communications are the same; the
> difference is that the flow is either lateral (peer-peer, non-hierachical)
> or vertical (parent-child, hierachical) at any particular point.
>
> >
> >Specific comments related to Section 1.2:
> >
> >1.      Definitions for "H.323 network", "zone" and "domain" should also
> be
> >included (in addition to "Administrative Domain" and "Border Element").
>
> 'H.323 network' -  is not used anywhere.... (IP network?)
> Zone - is defined in the H.323 document
> Domain - see above comments ( your comments to sec 1.2)
>
> >
> >
> >Specific comments related to Section 1.3:
> >
> >1.      The title of this section should be changed to "Hierarchical
> >Inter-Gatekeeper Communications Between Administrative Domains". The
> >write-up should be modified to take into account all the comments given
> >above.
> >
> >Specific comments related to Sections 1.5, 1.5.1, 1.5.2, 1.5.2.1-1.5.2.7:
> >
> >1.      These sections are general enough to be used in the context of a
> >zone. In fact, it is a very good one. These items are very useful for
> >communications between the zones within a given domain. AT&T contribution
> >that is expected be submitted (yet to obtain clearance) may also propose
> to
> >use these message sets for inter-zone communications in a given domain.
> >
> >In view of the above comments, it is proposed that the outline of Annex G
> >should be modified as follows:
> >
> >1. Annex G - Gatekeeper-to-Gatekeeper Communications
> >1.1     Scope
> >1.2     Definitions
> >1.3     Inter-Gatekeeper Communications Within a Given Domains
> >1.3.1 Requirements
> >1.3.1   Non-Hierarchical (Distributive)
> >1.3.2   Hierarchical (Centralized)
> >1.3.3   Hybrid (Non-Hierarchical + Hierarchical)
> >1.4     Inter-Gatekeeper Communications Between (Administrative) Domains
> >1.4.1 Requirements
> >1.4.1   Non-Hierarchical
> >1.4.2   Hierarchical*
> >1.4.3   Hybrid (Non-Hierarchical + Hierarchical)
> >1.5     References
> >1.6     Protocols
> >
> >(* The present write-up addresses this model only. The other models will
> be
> >addressed as soon as contributions will be brought in those areas).
> >
> >If anyone has any questions, please let me know.
> >
> >Sincerely,
> >
> >Radhika R. Roy
> >AT&T
> >Holmdel, NJ 07733, USA
> >Tel: (732) 949 8657
> >Fax: (732) 949 8569
> >Rrroy at att.com
> >
>
>
> *****************************************************
> ***  +1-503-264-8816(voice)              Intel - Hillsboro, OR.
>     ***
> ***  mailto:jim.toga at intel.com         mailto:james.toga at ties.itu.int ***
> ***  PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41 ***
> *****************************************************
>