H323 Robustness

[Roy, Radhika R, ALARC]

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 at att.com

 <<D-225.doc>>
> -----Original Message-----
> From: gmakkar at hss.hns.com [SMTP:gmakkar at 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D-225.doc
Type: application/msword
Size: 165376 bytes
Desc: not available
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/19991101/36c01793/attachment-0003.doc>