[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sigtran] m3ua- IG
Tolga,
Tolga Asveren wrote: (Sat, 11 Jan 2003 13:11:17)
> Brian,
> --- "Brian F. G. Bidulock" <bidulock@openss7.org>
> wrote:
> > Tolga,
> >
> > Tolga Asveren wrote:
> > (Sat, 11 Jan 2003
> > 12:03:50)
> > > Brian,
> > > [...snip....]
> > > > > [TOLGA]This is the reason why you have the
> > > > management
> > > > > functionality on SG. You get the responses and
> > > > create
> > > > > the global view of the corresponding
> > subsystem.
> > > > Not
> > > > > all of the SSP is sent to SS7 network, only
> > one.
> > > >
> > > > Not all the responses necessarily go through the
> > > > same SG.
> > > >
> > > > Still broken.
> > > [TOLGA] We were already here I think. The solution
> > is
> > > simple, do not use multiple SG configuration,
> > which
> > > anyhow is a strange mode of operation (multiple
> > MTP3
> > > logic for the same PC, working independently)
> >
> > M3UA can support MTP3 routing keys on multiple SG.
> [TOLGA] I think supporting multiple SG case is
> optional. And I wouldn't consider not supporting it as
> a modification to M3UA protocol but just as not
> supporting one type of configuration.
MTP3 RKs are supported on multiple SG. You will need
a statement saying the your SSN RKs are not supported
on mutliple SG (amoung other things).
> >
> > Besides, its still broken. How do you handle
> > subsystem
> > congestion?
> [TOLGA] What is specail about it? How different it is
> from congestion of signalling point case for ANSI
> networks when multiple SGs are used? Again management
> logic decides, when to declare the subsystem as
> congested.
Subsystem congestion is implementation dependent and
resides on the ASP. The SGP cannot know the algorithm
and cannot correlate multiple congestion messages from
multiple ASPs.
> >
> > Also, you have race condition with your correlation
> > of
> > SSP messages. One ASP can issue SSA before the SSP
> > has arrived from other ASP. Like so:
> >
> > ASP1 SSA ----- SSP SGP1
> > ASP2 SSA ----- SSP SGP2
> > ASP3 SSA ----- SSP SGP3
> > ASP4 SSA ----- SSP SGP4
> > ASP5 SSA ----- SSP SGP5
> > ASP6 SSA ----- SSP SGP6
> > ASP7 SSA ----- SSP SGP7
> > ASP8 SSA ----- SSP SGP8
> >
> > The SCCP thinks it has sent SSP followed by SSA.
> > The
> > SG receives:
> >
> > SSP, SSP, SSP, SSA, SSP, SSA, SSA, SSP, SSP, SSP,
> > SSA, SSA, SSP, SSA, SSA, SSA
> >
> > Some are responsive to SST, some are broadcast.
> > What
> > will the SG send? Also note that SCCP management
> > messages are not send on the same SLS, so some of
> > these
> > can get reversed in between ASP and SGP.
> [TOLGA] For the ones which are not sent on the same
> SLS, isn't there also the possibility that they get
> missequenced in the TDM based SS7 network?
Only during failures or congestion (which almost never occur).
With your solution, because of the way SCTP treats streams,
it will occur as in normal operation with no failures. This
will fail conformance tests.
> Although all of those are questions about the
> implementation dependent part and are not related with
> M3UA, still I would think:
> For your scenario, SG would respond with SSA if it has
> received one SSA from one ASP -and if it didn't
> received SSP from it afterwards-, before the timer it
> started after receiving SST, expires.
But SSA and SSP can get reversed by SCTP, them being on
different streams and even different associations to
different SGP. Therefore, your algorithm is often wrong
in the normal course of affairs and cannot be shown to
meet SCCP conformance. Your are breaking the MTP User by
mucking with its messages.
>
> >
> > Your algorithm falls flat on its face because it
> > cannot tell the different between respones to SST
> > and
> > broadcast messages (it is not contained in the
> > message).
> [TOLGA] Again my answer for the non-M3UA part:
> Management logic on SG keeps global SSP states. When
> this state is changed based on a message received from
> an ASP, it can be considered as an event to be broadcasted.
You cannot tell at the SG, only at the ASP. Which was the
response to SST? The SSA's above or the SSP's?
--brian
--
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran