Re: [M3UA] Double Exchange procedures

"Brian F. G. Bidulock" <[email protected]>
Newsgroups gmane.ietf.sigtran
Organization http://www.openss7.org/
Message-ID <[email protected]>
Adnan,

If one doesn't understand something, it is better to form
questions rather than sweeping assertions.

You seem to prefer DE for most of the reasons that it was
technically counter-recommended in favor of SE.

Provisioning multiple RC values, one at each end per IPSP and
synchronizing them (which RC value corresponds to which) is
wasetful, prone to error, race conditions, and can yield
half-flows where two endpoints cannot communication (unbeknownst
to either of them when RC values lose synchronization).  Unless
grossly misconfigured, this can never happen in the real SS7
network and all communications between SS7 provider and SS7 user
are inherently full-duplex.

SE has half the RC values for the same system as DE, and cannot
result in broken half-traffic flows.  Contrary to your
statements, SE eases RC provisioning in comparison to DE.

--brian

Adnan Hasnain Alam wrote:                     (Sun, 07 Jun 2009 10:35:58)
> 
>    Hi Brian, David,
> 
>    IPSP SE mode confuses me. What is the RC value that should be sent in
>    the ASP Active message? And what should be the routing key that would
>    be associated with this RC value? Would routing key define traffic in
>    both directions (how do you do that!) or only in one direction.
> 
>    In IPSP DE mode, I am clear that each node would send its local RC
>    value in the ASP Active. And the routing key associated with this
>    local RC value would only define the nature of incoming traffic at
>    this node.
> 
>    Therefore I prefer IPSP DE mode. IPSP SE mode cause a lot of problems
>    in networks where there are many M3UA nodes interconnected in RC value
>    provisioning.
> 
>    All the best,
> 
>    Adnan
> 

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.