RAS terminal and gateway discovery/registration messages

Mohamed Mustafa 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.

Boaz
http://people.itu.int/~michaely





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.

-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