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

Hi Brian,

Thanks for the quick (and lengthy) reply :)  The details are appreciated.

It's going to take me a while to get through this email, I'll respond
once I've had time to absorb it.

Thanks again.
Andrew

Brian F. G. Bidulock wrote:

>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
>
>  
>