RE: M2PA Alignment Clarification

Brian:

Whether or not the network was too poor to sustain the link is not the
point.  The point is that if you have some - read that any - packet loss
in the network, if a proving packet is lost in the network at the end of
the proving period, this situation can be created.  It's just that it's
easier to create/more prevalent in lossier networks.

Mark

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Monday, October 02, 2006 6:07 PM
To: Erickson, Mark
Cc: [email protected]
Subject: Re: [Sigtran] 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/