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). 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). 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.
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." 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. 3. A domain has to be defined further. For example, a domain may consist of multiple zones. 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). 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". 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". 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.
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").
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@att.com
---------- From: Santo Wiryaman[SMTP:swiryaman@VIDEOSERVER.COM] Reply To: Mailing list for parties associated with ITU-T Study Group 16 Sent: Thursday, July 23, 1998 10:37 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: H.225 Annex G hierarchies
Dear Colleagues:
I completely agree with Mr. Roy that we should include a discussion in Annex G on how zones within an Administrative domain can be arranged as is described in APC-1385.
However, my version of APC-1375 titles Annex G as "Communication Between Administrative Domains". As currently defined in Annex G, an Administrative Domains includes a "Border Element" and there is an implied hierarchy structure between a border element and regular gatekeepers (granted that this could be a degenerate form of hierarchy, i.e. flat).
The proposal we brought to the table is how we could arrange these Administrative Domains in a manner that would be scalable consistent with Goal #2 as stated in Annex G.
Santo Wiryaman Videoserver Inc. swiryaman@videoserver.com +1.781.505.2348 +1.781.505.2101 (fax)
---------- From: Mailing list for parties associated with ITU-T Study Group 16 [SMTP:ITU-SG16@mailbag.jf.INTEL.COM] Sent: Thursday, July 23, 1998 8:50 AM To: ITU-SG16 Subject: Re: H.225 Annex G topics
Hi Everyone:
This proposal of Videoserver suggests a specific implementation scheme that is known as "hierarchical (or centralized)" model. A hierarchical model has both advantages and disadvantages (we had many discussions on this before).
However, Annex G does not impose any restriction how the system organization will look like. Consequently, the system organization can be "non-hierarchical (or distributive)", "hierarchical (or centralized)", or "hybrid (distributive + centralized)" as proposed in APC 1385, and can be chosen depending what is best from an implementation point of view.
The important point is that a "zone" having a single gatekeeper (GK) remains the basic building block. A domain may consist of multiple zones. The possible logical organizational relationship for communications between the multiple zones can be "distributive", "centralized", or "hybrid" as proposed in APC 1385. The fundamental questions are as follows:
* Can we define the inter-GK communications protocol (IGCP) that satisfies the requirements in "distributive", "centralized", and "hybrid" system organizational environment? * Can we use the same RAS protocol that will provide the scalable solution for both connection oriented and connectionless networking environment considering the large-scale H.323 network? Or do we need the extension of this RAS protocol?
Therefore, it is strongly suggested that the above points that are being suggested in APC 1385 should also be included in the work scope of Annex G.
Thanks and regards,
Radhika R. Roy AT&T Tel: (732) 949 8657 Fax: (732) 949 8569 Email: rrroy@att.com
From: Glen Freundlich[SMTP:ggf@lucent.com] Reply To: ggf@lucent.com Sent: Tuesday, August 04, 1998 1:53 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: H.225.0 Annex G conference call
<<File: annexg.zip>> There will be another conference call to discuss H.225.0 Annex G: date: 6 August (Thursday) time: 9:00am Mountain Time (8:00 Pacific, 11:00 Eastern, etc) bridge number: +1 630-713-3333 code: 840059 duration: 1 hour
Tentative agenda: - next call on 19 August (Wednesday)? - readout on issues from last call: - security issues (Senthil Sengodan) - see email - Diameter update (Nancy Greene) - telephone network addressing hierarchy (Hal Purdy) - review of current Annex G text (see attached document) - review requirements coverage
Notes from last call: There was more discussion about architecture, with reference to APC-1385 and an email submission from Santo Wiryamen. Annex G should not impose any architectural model, and should allow any model (hierarchical, distributed, hybrid) to exist. Nothing currently proposed seems to require, or favor, one model over any other, but text and figures should give equal time to other models. Also, both currently defined call models (gatekeeper routed and direct endpoint) should be allowed, and the protocols are probably not different depending on call model.
There could be some value in looking at numbering and architecture in the telephone network, although numbering and architecture are probably orthogonal issues. Hal Purdy will investigate the telephone network's implementation and report back.
Nancy Greene gave a quick readout on Diameter. There is a framework that can carry various extensions, where the Annex G work could fit into one (or more) extensions. The framework and some extensions are current IETF drafts. Nancy will provide more details.
There are security concerns that will need to be addressed. Senthil Sengodan will begin to look at this and report back.
For those who were on the last call, please correct me if I've missed something.
Glen
-- Glen Freundlich ggf@lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA