Hi, Gaurav and All:
Further my earlier email, I am enclosing D.225.
In the last Red Bank meeting report (APC-1748 Version 2, October 29, 1999), it has been noted that D.225 from Chile is relevant in addition to other documents.
D.225 primarily focuses on reliable GK architectures because H.323 considers that it is the most important entity whose robustness needs to be considered first. The existing H.323 signaling scheme already provides a mechanism for one or more alternative GKs to increase reliability. Of course, the reliability of other H.323 entities should also be considered.
The alternate gatekeeper that has been used in H.323 should be the starting point for building the H.323 robustness model.
What do we mean robustness? D.225 provides a definition considering reliability, availability, serviceability, recoverability, scalability, context, and security.
What do we mean by failures? Failures have to be considered in the context of H.323. Failure detection and handling should include all scenarios (e.g., connection-oriented transport protocol [TCP], connectionless oriented transport protocol [UDP], etc.) for signaling. Failures of media streams and their recovery should also be addressed.
The system scope can be as follows: 1. intra-zone, 2. inter-zone (intra-domain), and 3. inter-domain. As shown in D.225, for case 1, an alternate GK can be located in the same zone; for case 2, an alternate GK can be located in the same zone of the primary GK or in a different zone other than the zone of the primary GK; similarly, case 3 may also have different options like case 2. The situation can be more complicated if there is more than one alternate GK as envisioned in H.323.
We will start with a simple scenario.
We may well discover that we need a sort of inter-GK protocol. Can we look into something that exists today similar to this problem?
I find that routers are doing something very similar to this for the last two decades. Failure detection and handling, database synchronization and re-synchronization, and many more. Can we use many those for our inter-GK protocol to take care-of H.323 robustness?
However, there are dissimilarities as well. GK is an application layer entity. If we can devise an intelligent scheme not to maintain all the databases (e.g., databases consisting with H.323 call states) of all GKs synchronized other than the respective primary and the alternate GK, we may simplify some of the problems. Moreover, GK needs not to be involved with the network level link states. Assuming that the GK will be able to abstract the GK-level connectivity with the help of the network layer entities like routers, we can simplify our problems further.
This is the initial input for our upcoming discussion.
As we go forward, we will learn more how to address the complex problem.
Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy@att.com
<<D-225.doc>>
-----Original Message----- From: gmakkar@hss.hns.com [SMTP:gmakkar@hss.hns.com] Sent: Monday, November 01, 1999 9:42 AM To: Roy, Radhika R, ALARC Subject: Re: H323mobility:meeting
Radhika, Could you share the D.225 doc being referred to in this mail. TD-28 refers to this too.
Thanks and Regards, Gaurav Makkar