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@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@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.
- 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.
- 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.
- 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:
The modified title of Annex G is very restrictive, and is NOTacceptable. 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.
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.
Section 1.1 (Scope). It has been mentioned that "It should alsobe
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:
The title of Annex G should remain as it was before: "Annex G -Gatekeeper-to-Gatekeeper Communications."
Agreed.
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'
A domain has to be defined further. For example, a domain mayconsist 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?
Inter-gatekeeper communications between the multiple zones of agiven 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.
A single administrator will also be able to create multipledomains
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.
If a domain belongs to a single administrator, and communicationsbetween 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.
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:
Definitions for "H.323 network", "zone" and "domain" should alsobe
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:
The title of this section should be changed to "HierarchicalInter-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:
These sections are general enough to be used in the context of azone. 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:
- 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@att.com
*** +1-503-264-8816(voice) Intel - Hillsboro, OR. *** *** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 ***