Re: (M2PA) Initial version of M2PA IG is Now Available

Andrew,

Forgive me for the long note, but I figured you were asking for
details...

Andrew Booth wrote:                           (Mon, 29 May 2006 16:03:59)
>
> I don't follow you here, perhaps we're talking about different scenarios.
> 
> If an MTP3 (or an "implementation specific management function") has
> sent "Local Processor Recovered" and "Flush" or "Resume" to MTP2 then it
> perceives the link as "In Service".  Hence T1 will either be cancelled
> (short duration LPO) or have expired. In neither case is T1 running when
> MTP3 starts to send Data on the link again. If at this point the remote
> M2PA doesn't provide the expected LSR then any messages from MTP3 are
> stuck in the M2PA TB, there is no primitive between M2PA and MTP3 that
> notifies MTP3 of this "funny" situation.

Several things you are missing:

- T1 is still running on the blocked link at the peer.  And the peer is
  still holding messages in preparation for changeover.

- The side sending LSPR cannot resume sending data messages until it has
  received the LS Ready.  This is in accordance with, for example, ANSI
  T1.111.3-2000 clause 8, which goes further to say that messages are
  not accepted from L3 until the procedure completes.

> The best you can hope for is that MTP3 will try to perform an SLT
> procedure (which will fail) at the end of LPO before performing a
> changeback, and hence will fail the link. I believe SLT is optional at
> the end of processor outage though, so this isn't a complete solution.
> If the SLT procedure is skipped, data from MTP3 will continue to
> accumulate in the M2PA TB until "false link congestion" takes the link
> out of service or another SLT procedure is fails (again, I IIRC the
> periodic SLT procedure is optional, but practically it is used fairly
> universally).

You should know that failing a link due to a failed SLT beyond the
initial SLT procedure is counter-recommended.

> Aside: AFAIK, MTP3 doesn't fail a link after a time controlled
> changeover, it just doesn't use it for traffic. Maybe that's just a
> difference in terminology.

The link is marked as failed when Out_of_Service is received from L2
regardless of whether the link is in time controlled changeover or not.


MTP2 is not permitted to accept messages from MTP3 until the Resume
procedure completes. (ANSI T1.111.3-2000 Clause 8), so there will be no
accumulation in the TB if the MTP3 is compliant with that standard.
These messages are queued in the hold buffer created when the link
became blocked and T1 was started and remain there until T1 expires, the
Resume procedure completes and they are drained to the current link, or
they are passed to an alternate link when a changeover procedure
completes.  In any case, as messages have been held while the link was
blocked any new messages for transmission on the link must be queued
behind already queued messages to preserve message order.

At the other end of the link T1 is running.  When M2PA at the other end
of the link receives LSPR it indicates remote processor recovered to
MTP3.  At this point, MTP3 either flushes buffers or resumes and is
bound by the same requirement to wait for the flush or resume procedure
to complete before sending messages on the link.  It too is holding
messages in a hold buffer an has T1 running.  When flush or resume is
received from MTP3, M2PA MUST send LS Ready, and only after the
procedure completes (again according to ANSI T1.111.3-2000 clause 8) can
is send further User data messages from the hold buffer followed by new
messages.

Consider the delayed LSPR.

It is resonable that, as the link was completely quiescent during
processor outage, the LSPR might be extraoridinarily delayed.  Level 2
bridges and Level 3 switches might have aged spanning tree information
or arp cache during the quiescent period, causing additional delays to
the LSPR message not be experienced by messages during normal operation.

If the processor outage is of a very short duration, SCTP can have User
Data messages delivered to it that have not been succesfully
acknowledged by the SCTP peer and the LSPR message will not even be
transmitted until these messages clear to the other side.  So for very
short outages it is still possible that the LSPR message is considerably
delayed.

SCTP's fast recovery algorithm relies on the appearance of subsequent
messages from the missing message (indicating a gap) and a SACK with a
gap report to invoke the FR algorithm.  As the LSPR is not followed by
any message until the LS Ready is received, CRC error or other loss of
the LSPR will require the sender to wait at least RTO_min before it is
retransmitted.  SCTP RTO_min is set to 1 second.  With the other
considerations it is quite easy for LSPR to be delayed over 1 second.
T7 is typically 1 second.

> It seems to me that this transport delay is a reasonable reason for
> taking the link out of service (provided we have data pending on the LSR).
> 
> After all, if the link were in service when a transport delay caused T7
> to expire then the link would fail. I don't see the two cases as
> substantially different.
> 
> Does that make any sense? Or am I missing something?

The remote end MUST send LS Ready in response to LSPR.  Broken
implementations aside, take a look at what happens at the proper
functioning remote end of the link when LPSR or its LS Ready gets
delayed in transit and a procedure is used to fail the link.

When the timer expires (node A) waiting for LS Ready after sending LSPR,
two conditions are possible at node A:

1. Node A follows ANSI T1.111.3-2000, in which case the signalling link
   has not been marked available at Level 3 until the Resume procedure
   completes, which includes syncrhonization of sequence numbers
   requiring it to wait for LS Ready.

2. Node A ignores ANSI T1.111.3-2000 and marks the link as available at
   Level 3 before the LS Ready is received.  (I think this is the case
   that you were considering.)

In case (1), Out_of_Service indication from L2 at node A will be ignored
(by TLAC) because T1 is  still running.  Because it failed, LSAC will
place the link in suspension (T32 or T34 for ANSI, 5 to 120 seconds).
After suspension, restoration will be attempted.  When T1 expires,
messages will be sent to the alternate link.  Because the link has
failed and buffers are not collected, they are discarded when the link
receives the Start command.  Because LSOS is sent by node A on Stream 0,
it is possible that LSOS is received by node B before the LSPR or data
messages preceding it, or it may arrive later.  Because LSPO is sent on
Stream 1 also, it is possible that LSOS is received on Stream 0 before
LSPO.

In case (2), Out_of_Service indication from L2 at node A will cause TLAC
to initiate sequenced changeover and a COO messages will be assembled
with BSNT/FSNC and sent to the other end and T2 will be started.  As the
COO message is sent via an alternate link, it might be received by node
B before or after the user data messages and LSPR queued on Stream 1 on
the affected association.  Again LSOS is sent by node A on Stream 0
(LSAC) and the link is placed into suspension (T32 or T34, 5 to 120
seconds).

Looking at node B, there are several possibilities visa vi LSOS:

- LSOS arrives before LSPO.  Node B initiates sequenced changeover and
  issues COO to node A.  If node A is case (1), it responds with ECA and
  messages are lost because node B cannot update its buffers.  If node A
  is case (2), it responds with COA and buffer updating is complete.

- LSOS arrives after LSPO but before LSPR.  Node B is already in
  changeover and the link is put into suspension.

- LSOS arrives after LSPR (i.e. after LS Ready is sent).  Node B
  initiates changeover procedures.  Again if node A is case (1), it
  responds with ECA and messages will be lost.  If node a is case (2),
  it responds with COA and buffer updating is completed.

In any case, when the LSOS is received, the link is put into suspension
and it will take up to several minutes for the link to be restored.

Looking at node B, there are several possibilitys visa vi COO (when node
is case (2) only).

- COO arrives before LSPO.  Node B initiates sequence changeover and
  issues COA to node A.   Node B issues Stop command to L2, the link is
  treated as failed, and is placed into suspension.  The other side will
  complete buffer updating.  It will take up to several minutes to
  restore the link from suspension.

- COO arrives after LSPO but before LSPR.  Node B is already in
  changeover and responds with ECA.  Node A will discard buffers.  The
  links is already in suspension.  When T1 expires at Node B, node B
  will clear buffers, discarding messages.

- COO arrives after LSPR.  Node B has the link back in service and will
  respondw ith COA.  Buffers will be updated,  Node B will place the
  link under suspension.

If, as is often the case for M2PA, the alternate link is in a different
link set, time-controlled changeover is chosen over sequenced (to avoid
missequencing of messages at the ultimate destination).  All COO/COA
exchanges above will result in the loss of buffered messages at both
ends.

Contrast this with just waiting.

When LSPR is received by node B before T1 timer expiry, the link is
resumed, LS Ready is sent (on Stream 1) and messages are transmitted on
the signalling link.  When message are sent, T7 is running.  If node A
does not receive the LS Ready in a timely manner, it will not receive
the messages queued behind it and T7 will expire and node B will stop
the link and initiate changeover.  If there are no User data messages
for node B to send, the link is quiescent and it does not matter how
long either side waits.  When the first message is sent by node B, T7 is
started and node A must respond.  If the SCTP association fails due to
excessive retransmissions or abort, node B will intiate changeover.

A node A in case (1), if T1 has not expired before receiving LS Ready,
the link will be resumed without message loss.  If T1 expires before LS
Ready arrives, changeover will occur and buffers will be flushed on the
link.  When the LS Ready eventually arrives, the link becomes available
and changeback can occur.

A node A in case (2) might have a problem, but placing the link out of
service an incurring message loss and full link suspension before
recovery is not a solution.  Case (2) is broken, even for SS7 links
because there is no guarantee that sequence number synchronization will
complete in a timely manner.

A better option if you are faced with such a broken implemenation might
be to use the old RPO/LPO latching option whereby when local processor
outage is requested when remote processor outage is received; that is,
LSPO is sent when LSPO is received, when LSPR is received, LSPR is sent.
That way node A is guaranteed to keep T1 running until the procedure
completes.  But this is an option already used in SS7 today and does not
require any alteration to M2PA to implement (when Remote_processor_outage
is indicated to L3, a MGMT function signals Local_processor_outage to
L2; when Remote_processor_recovered is indicated to L3, the MGMT
function signals Local_processor_recovered to L2.)

This is an L3/MGMT procedure that was used in the past to handle poorly
operating ITU-T MTP3 implementations (Red Book I think) and I don't
think that it is in use today because I don't believe there are any MTP3
implementations so broken that they do not leave T1 running until the
syncrhonization procedure is complete and L2 is fully ready to accept
MSUs.

It is quite possible to implement latching as a local matter to such a
case (2) implementation.  Your local M2PA/MGMT could indicate Remote
Processor Outage to L3 in response to Local Processor Outage, and
indicate Remote Processor Recovered only after LS Ready is received as
part of Local Processor Recovery.  This will hold your T1 timer running
until LS Ready is received.  This is completely a local matter.  ANSI
T1.111.3 completely removed local processor outage handling from the
SDLs for these very reasons.

So, by causing changeover and failing the link (sending LSOS), this T7
procedure causes buffer loss due to link failure, and buffer loss as
well as missequencing due to unnecessary changeovers, and long periods
of link suspension due to link failure.  All just because LSPR or LS
Ready might be delayed for a second or so which is fully reasonable
given SCTP's characteristics.  Although you are welcome to do this if
you want (the RFC does not forbid it), it cannot be recommended.

--brian

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