I heartily agree with Offer's recommendations, and particularly think that the only distinction to be made is between the registration process and the call related functionality.
Ami
-----Original Message----- From: Offer Pazy [mailto:Offer_Pazy@EUR.3COM.COM] Sent: 15 December, 1999 14:21 To: ITU-SG16@MAILBAG.INTEL.COM Subject: [Robustness] A couple comments on D.225
Hello,
I hope that this is the right forum, procedure and timing for commenting on the D.225 document. If not, please use moderate flames only....
In general, I like the models presented and I think they serve a useful starting point. I would like to offer two simplifications:
1. Distributed Vs hierarchical architectures:
I don't see the value of having a special hierarchical case. As suggested in D.225, we must avoid single point of failures. The node at the top of the diagram (figure 7) is such a point unless we introduce redundancy for it as well. When we do so, we go back to the general distributed case where each node has a primary GK of a zone plus zero or more backup GKs for other zones. My view is that describing the model in this way is simpler than having two distinct cases,
2. D.225 proposes that the three internal "components" of a GK should be exposed and that redundancy mechanisms should be defined for them. I wonder if we should not keep this as an implementation issue. After all, GKs are defined in H.323 as containing all these three components and there was no intention (I believe) to force end-points to distinguish between a failed GK and the failure of one of its subcomponents. To formalize such granularity would require us to answer questions such as: What happens if the Q.931 component of GK A fails but its H.245 component is running OK, and the backup of the Q.931 of GK A resides with GK B whose RAS component has failed? Or, what happens when an endpoint is registered with GK A but uses GK B (GK-routed) as the originating GK when the Q.931 component of A has failed? etc. etc. Clearly this is a complex problem to solve.
Instead I believe we should concentrate on treating the GK as a monolithic entity which 1) has fail-stop semantics and 2) a backup entity is backing up the GK as a whole as opposed to having a backup for each subcomponent. From the standard and protocols stand-point this will suffice. Clearly, implementors will have to invest efforts in designing their GK architectures in the most fault tolerant manner (and may use some of the ideas presented in D.225), but this should really be out of scope for the standard as long as the semantics of a failed GK are clearly defined.
A slightly different way to look at the proposal in D.225 is to reduce the number of GK subcomponents from three (RAS, Q.931, H.245) to two: Registration issues and "a particular call"-related issues. As can be noticed, this idea does not just decrease the granularity (which by itself simplifies things), but also shifts the focus of the model from that of an implementation view to a more behavioral view. It can be argued that H.323 endpoints already have to distinguish between the registration process and failures and the process of call establishment and control.
Offer