Subject: Re: H323 Robustness Dear All,

I would think that Sigtran could be used to provide the GK "switch over" to a hot standby GK from the IP layer point of view.

Ed

"Roy, Radhika R, ALARC" wrote:

...

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

...

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

Network layer support for robustness is great where available, and hopefully it works transparently, as Qiaobing states. Agreed, we may want to assure that the interfaces to lower layer robustness mechanisms are well defined, however our focus here is enhancing the application level, which grants a network independent solution. Boaz http://people.itu.int/~michaely Qiaobing Xie <xieqb@CIG.MOT.COM> on 02/11/99 01:11:38 AM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16@mailbag.cps.intel.com> To: ITU-SG16@mailbag.cps.intel.com cc: (bcc: Boaz Michaely) Subject: Re: H323 Robustness Actually, the SCTP transport protocol defined by Sigtran is specifically designed to address the path level robustness. It is designed to support multiple NIC cards (a.k.a. multi-homed nodes) and provide transparent interface and path failure detection and recovery. -Qiaobing On Nov 1, 1:22pm, Edgar Martinez [1] wrote: like 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

...

Name: D-225.doc D-225.doc Type: Winword File (application/msword) Encoding: base64

-- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ -- End of excerpt from Edgar Martinez [1]