H323 Robustness

Qiaobing Xie xieqb at CIG.MOT.COM
Mon Nov 1 18:11:38 EST 1999


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:
> 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 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
> > >
> >
> >   ------------------------------------------------------------------------
> >                 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/
>-- End of excerpt from Edgar Martinez [1]



More information about the sg16-avd mailing list