Subject: [Sigtran] M2PA Alignment Clarification

From: "Erickson, Mark" <[email-masked]>
Date: Mon, 2 Oct 2006 13:30:51 -0500

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-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 2 Oct 2006 16:07:24 -0600

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.
> 
> 
>    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.
> 
> 
>    received  by  an endpoint once the link is transitioned to in service.
>    Is there a better way to handle this situation?
> 
> 
>    Mark

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