Re: Sigtran extension for network management and association changeover.

Xiangsong,

Xiangsong Cui wrote:                      (Fri, 05 Mar 2010 17:41:20)
> >>As you said in your draft, local implementation is not engough
> >>for the expected benefit, and we do wish a feasible solution for 
> >>the high-performance Sigtran network.
> >
> >No, that's not what I said.  Local implementation is not enough
> >for the _full_ benefit.  Nevertheless there is still _benefit_
> >to be had by one or both ends performing the Interworking Procedures.
> 
> *We* expect the higher benefit. Before the huge Time-Bandwidth Product,
> time-controlled changeover is near to non-changeover, because there are
> too much sent but unacknowledged messages, undetermined in the floating way.

Then you do not want SS7 either.  International SS7 and many national
variants (e.g. ETSI) permit an MTP implementation to _always_ use
time-controlled changeover instead of sequenced changeover.  (This
includes satellite links by the way.)  This is because there are
cases where message missequencing can occur when changing over.  It
was never the intention of SIGTRAN to improve upon SS7 in this way.
If you try to use SIGTRAN in an environment where even traditional SS7
will not work, it is likely to fail.

There are implementors in this WG that swear by the time-controlled
method, and that is one of the reasons why the corid draft never
moved forward.

An example where sequenced changeover will not work is where the failed
association has a long delay and the alternate association has a short
delay.  See other examples in section 1.4.5 in the corid draft.

Because SCTP does not know anything about the traffic flows driving its
streams, messages received last on the failed or deactivated association
might be processed after the first messages received on the new association, 
resulting in significant message mis-sequencing.  Again, message discard
or message delay is better than mis-sequencing for SS7, so time-controlled
or flushing (BEAT/ACK) approaches are better in this regard.

I don't think that you have thought this out.

--brian

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/