H.225.0 Annex G conference call

Roy, Radhika R, ALTEC rrroy at ATT.COM
Wed Aug 5 13:35:12 EDT 1998

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
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

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

Specific comments related to Sections 1.5, 1.5.1, 1.5.2,

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.


Radhika R. Roy
Holmdel, NJ 07733, USA
Tel: (732) 949 8657
Fax: (732) 949 8569
Rrroy at att.com

        From:   Santo Wiryaman[SMTP:swiryaman at 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 at MAILBAG.INTEL.COM
        Subject:        H.225 Annex G hierarchies

        Dear Colleagues:

        I completely agree with Mr. Roy that we should include a discussion
        Annex G on how zones within an Administrative domain can be arranged
        is described in APC-1385.

        However, my version of APC-1375 titles Annex G as "Communication
        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
        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
        Goal #2 as stated in Annex G.

        Santo Wiryaman
        Videoserver Inc.
        swiryaman at videoserver.com
        +1.781.505.2101 (fax)

        From:  Mailing list for parties associated with ITU-T Study Group 16
        [SMTP:ITU-SG16 at 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
        is known as "hierarchical (or centralized)" model. A hierarchical
        both advantages and disadvantages (we had many discussions on this

        However, Annex G does not impose any restriction how the system
        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)
        the basic building block. A domain may consist of multiple zones.
        possible logical organizational relationship for communications
        multiple zones can be "distributive", "centralized", or "hybrid" as
        in APC 1385. The fundamental questions are as follows:

        *       Can we define the inter-GK communications protocol (IGCP)
        satisfies the requirements in "distributive", "centralized", and
        system organizational environment?
        *       Can we use the same RAS protocol that will provide the
        solution for both connection oriented and connectionless networking
        environment considering the large-scale H.323 network? Or do we need
        extension of this RAS protocol?

        Therefore, it is strongly suggested that the above points that are
        suggested in APC 1385 should also be included in the work scope of

        Thanks and regards,

        Radhika R. Roy
        Tel: (732) 949 8657
        Fax: (732) 949 8569
        Email: rrroy at att.com

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

More information about the sg16-avd mailing list