Edgar Martinez 
martinze at CIG.MOT.COM
Mon Nov 1 13:22:44 EST 1999
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.
"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
> 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
> +1 732 420 1580
> rrroy at att.com
> > -----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
> Name: D-225.doc
> D-225.doc Type: Winword File (application/msword)
> Encoding: base64
Edgar Martinez - Principal Staff Engineer
Email mailto:martinze at 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/
More information about the sg16-avd