RAS terminal and gateway discovery/registration messages
M.Mustafa at SDXPLC.COM
Tue Nov 2 06:37:51 EST 1999
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.
Qiaobing Xie <xieqb at 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 at mailbag.cps.intel.com>
To: ITU-SG16 at 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.
On Nov 1, 1:22pm, Edgar Martinez  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.
> "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,
> > it has been noted that D.225 from Chile is relevant in addition to
> > documents.
> > D.225 primarily focuses on reliable GK architectures because H.323
> > that it is the most important entity whose robustness needs to be
> > first. The existing H.323 signaling scheme already provides a mechanism
> > 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
> > 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
> > of H.323. Failure detection and handling should include all scenarios
> > connection-oriented transport protocol [TCP], connectionless oriented
> > transport protocol [UDP], etc.) for signaling. Failures of media
> > 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
> > can be located in the same zone of the primary GK or in a different
> > 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
> > into something that exists today similar to this problem?
> > I find that routers are doing something very similar to this for the
> > two decades. Failure detection and handling, database synchronization
> > re-synchronization, and many more. Can we use many those for our
> > 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
> > synchronized other than the respective primary and the alternate GK, we
> > simplify some of the problems. Moreover, GK needs not to be involved
> > the network level link states. Assuming that the GK will be able to
> > 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
> > 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.
> > > 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 
More information about the sg16-avd