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(a)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(a)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(a)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(a)att.com
> ----------
> From: Glen Freundlich[SMTP:ggf@lucent.com]
> Reply To: ggf(a)lucent.com
> Sent: Tuesday, August 04, 1998 1:53 PM
> To: ITU-SG16(a)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(a)lucent.com
> Lucent Technologies office: +1 303 538 2899
> 11900 N. Pecos fax: +1 303 538 3907
> Westminster, Colorado 80234 USA
>
