Re: M2PA Alignment Clarification

Mark,

Your network is too poor to sustain an M2PA link.  The best
thing to do is to let it fail and allow messages to be routed
via some more viable alternate route.

In SS7 it is better that a link fails during SLTM/SLTA exchange
that immediately after receiving fully loading.  Recent SS7 MTP
specifications have included link oscillation avoidance
procedures to attempt to avoid links aligning and then failing
immediately after loading.  Otherwise, oscillating links can
destroy the message discard/missequencing characteristics of an
SS7 node.

In your case, the network reordering or loss is so high and of
such a long duration that it is highly unlikely that the link
can maintain in service even if you were to jimmy your way into
the "in service" state.  Better to let it fail and allow MTP to
place the link into lockout state.  It will be reattempted later
and perhaps better network conditions will prevail at that
point.

--brian

Erickson, Mark wrote:                           (Mon, 02 Oct 2006 13:30:51)
> 
>    All:
> 
> 
>    We  recently  came  across a sequencing problem that I think was dealt
>    with in PO procedures, but wasn't addressed for alignment.
> 
> 
>    There  was  an  M2PA  link  routed  over an IP network that was fairly
>    unstable - that is, there was a fair amount of packet loss/retransmits
>    occurring.   During alignment when establishing the link, the near end
>    had  completed  proving and transmitted LSR, but the far end was still
>    transmitting  proving  messages.   The  far end sent its final proving
>    messages which were dropped by the network, blocking stream 0.  In the
>    meantime, the far end transmitted a DATA message containing a SS7 SLTM
>    on  stream  1.   The  near  end received the SLTM, and, even though it
>    hadn't  received  a  LSR,  placed  the  link  in  service.  After this
>    transition,  the  near  end  received  the  remaining proving messages
>    retransmitted  by  the far end to unblock stream 0, at which point the
>    link  was  taken  out  of  service  due to the apparently missequenced
>    messages.
> 
> 
>    The  simple/obvious  answer  to this is to ignore any proving messages
>    received  by  an endpoint once the link is transitioned to in service.
>    Is there a better way to handle this situation?
> 
> 
>    Mark

> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran


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