Subject: RE: [Sigtran] (M2PA) Initial version of M2PA IG is Now Available

From: "Craig, Jeffrey" <[email-masked]>
Date: Sat, 27 May 2006 14:45:54 -0500

Hello Andrew and Brian,

<Regarding treatment of LSR/LSPR received during proving>

Andrew queried:
> What do you think of section 2.5 of Jeff's document?  Is it a
legitimate
> concern?

Brain replied:
> No, I don't.  I've had running code there for 5 years.
> Where does it say RFC 4165 that LS Ready is ignored while T4 is
running?
> I see where it says that a peer MAY send additional LS Ready messages
> while timer T1 is running.  If you are concerned that the other end
has
> sent LS Ready and is (for some bad reason) ignoring your previous LS
Ready
> messages, send another in response.  You are permitted by the RFC to
do
> so.  That is you always MAY send additional LS Ready messages while
timer
> T1 is running. In fact, you could pace them in the same manner as LS 
> Proving messages from the moment you send the first one.

Brian, are you saying that it is obvious that M2PA implementers should 
mark received LSR during proving? Please cite the section of the 
applicable standard that mandates for MTP2 the equivalent procedure
during
proving. Hopefully, your citation will apply to implementations for
which
FISU is not sent continuously (as is the case for M2PA LSR).

One issue is that the M2PA RFC does not mandate that LSR be sent more
than
once. Another issue is that the RFC does not mandate a rate to send LSR,
if the implementer chooses to send it periodically. An optimally
interoperable M2PA implementation, therefore, should send LSRs
periodically
and should handle a peer that sends only one LSR (which may arrive
during
proving). The IG says this.

<Regarding failing the link if timely LSR(1) not received after LSPR
sent>

Brian stated:
> Experience with SS7 makes me disagee.  Forcing a link to fail is bad,
the
> result being increased message loss in the network.
> ...
> This later is because failing the link before changeover will
> result in message loss.
> ...
> I think that, asside from excessive delay of acknowledgement of actual
> MSUs, MTP3 should decide when to fail a blocked link.

Un-bounded protocol waits are bad. Sometimes it is necessary for M2PA
to fail the link, and not receiving LSR(1) for seconds after sending
LSPR is one of those times. As Brian suggests, for the scenario to
happen,
something serious must go wrong. So why keep the link aligned when
something has gone seriously wrong?

Brian, are you saying that the scenario can't happen or are you saying
it
can only happen for contrived test cases (of which I have at least one)?

Brian, please explain in more detail why this form of 'failing the link'

results in more message loss than other forms of 'failing the link',
such 
as association failure. Please explain why M2PA should not fail a
blocked 
link when the association fails. Citing applicable standards text would
be
a good start.

Brian stated:
> I believe transport grade of service should be dealt with at the
network 
> and transport levels and is largely an operational consideration.

Perhaps I am misunderstanding what you are trying to say, but
I know of a few large operators who disagree with it as written.
M2PA should have an awareness of its transport and implement error rate
monitors, somewhat like MTP2 and ATM, to ensure that the quality of the
transport is sufficient to sustain an in-service signaling link. T7
expiry
is not the best mechanism for achieving this.

Regards,

Jeff

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Friday, May 26, 2006 5:33 PM
To: Andrew Booth
Cc: [email-masked]; Davidson, Mark
Subject: Re: [Sigtran] (M2PA) Initial version of M2PA IG is Now
Available

Andrew,

Andrew Booth wrote:
(Fri, 26 May 2006 15:01:51)
> Hi Brian,
> 
> Some comments and questions inline.
> 
> Brian F. G. Bidulock wrote:
> 
> >Mark,
> >
> >Davidson, Mark wrote:                      (Fri, 26 May 2006
09:22:50)
> >  
> >
> >>The waiting occurs after the LSPR is sent (an LSR has not yet been
> >>sent).
> >>I.e., the LPO side waits for the first LSR, but the RPO side does
not
> >>need to wait for the second one.  The change you refer to affected
> >>the RPO side.  The wait I'm referring to is on the LPO side.
> >>    
> >>
> >
> >Just as the side exiting LPO must wait for a FISU or MSU in ANSI
> >T1.113.3-2000 Clause 8 (Q.703 has little to say on the matter).
> >M2PA just uses LSR in this case instead of a FISU or MSU.
> >
> >I take it back: "receive" in the passage you quoted can stay at
> >"receive".  No change required.
> >  
> >
> I agree that the behaviour is similar to MTP2, but the effect on the
> network is bad (link congestion or messages queued for arbitrary
time). 
> I think failing the link after T7 in this case would make the protocol
> better.  Do you agree?

Experience with SS7 makes me disagee.  Forcing a link to fail is bad,
the
result being increased message loss in the network.

It think that implementations should be validated to behave correctly as
with SS7; therefore, the only thing that could delay the LSR would be
the
transport.  I believe transport grade of service should be dealt with at
the network and transport levels and is largely an operational
consideration.

For example, we recently discussed a case (on tsvwg) where the SCTP
stack
parameters were set so that it took over 3 seconds for a multi-homed
SCTP
host to switch from the primary address to the secondary, resulting in
link
failure from T7 time expiry whenever the primary failed.

Before failing the link in such a manner, one would need to check that
the
LSPR was acknowledged by the other end at the transport and that the
current
experienced RTT is not approaching T7, or even that it is beneath T6,
and that
MTP3 has already changed over (Q.704-T1 expiry, processor outage is of a
long
duration).  This later is because failing the link before changeover
will
result in message loss.  But then, if you wait for MTP3 T1 to expire and
changeover to occur, it makes no difference whether you wait or fail the
link because changeover has occured.

I think that, asside from excessive delay of acknowledgement of actual
MSUs,
MTP3 should decide when to fail a blocked link.

> 
> >  
> >
> >>If Q.703 is followed closely the link will not align.  I think
that's
> >>a problem.
> >>    
> >>
> >
> >It doesn't appear that all those Q.703 implementations out there have
> >any problem aligning.
> >
> >So you don't think that M2PA should correct Q.703 SDLs?
> >  
> >
> What do you think of section 2.5 of Jeff's document?  Is it a
legitimate
> concern?

No, I don't.  I've had running code there for 5 years.

Where does it say RFC 4165 that LS Ready is ignored while T4 is running?

I see where it says that a peer MAY send additional LS Ready messages
while
timer T1 is running.  If you are concerned that the other end has sent
LS
Ready and is (for some bad reason) ignoring your previous LS Ready
messages,
send another in response.  You are permitted by the RFC to do so.  That
is
you always MAY send additional LS Ready messages while timer T1 is
running.
In fact, you could pace them in the same manner as LS Proving messages
from
the moment you send the first one.

I think that the RFC should prescribe the desired behaviour rather than
going
to lengths to counter-recommend all undesired behavior.

Again I think that implementations should be validated.  See test case
3.1.5.
Would such a misbehaving implementation even align with itself?  Or
would it
fail this test.

--brian

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

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 27 May 2006 15:18:12 -0600

Jeffrey,

Craig, Jeffrey wrote:                          (Sat, 27 May 2006 14:45:54)
> during proving. Hopefully, your citation will apply to implementations
> for which FISU is not sent continuously (as is the case for M2PA LSR).

MTP2 does not send Link Status Ready.  It has no such message.  RFC 4165
states that Link Status Ready is used by each side to indicate alignment
instead of the FISU [or MSU].  What it does _not_ say is to ignore Link
Status Ready when T4 is running.  Doing so is simply someone's mishappen
invention or just a bug of an implementation.

Such a misbehaving implementation would not even align reliably with
itself.

> than once.

It is not an issue, once is sufficient for other than broken
implementations that can't even align with themselves.  Anyone can
think of hundreds of other ways that a implementation could be
wrongly implemented.  It is not the place of the protocol specification
to describe nor warn againsst all incorrect behaviour.

> Another issue is that the RFC does not mandate a rate to send LSR, if
> the implementer chooses to send it periodically. An optimally
> periodically and should handle a peer that sends only one LSR (which
> may arrive during proving). The IG says this.

It is a poor recomendation to suggest that an implementation should
accomodate a broken implementation that cannot align with itself.  It
is a better SS7 network policy to fail alignment with links that present
obvious interoperability problems.

> 
> Brian stated:
> > Experience with SS7 makes me disagee.  Forcing a link to fail is bad, the
> Un-bounded protocol waits are bad.

The wait is not unbounded: it is bounded by MTP3 T1.

> Sometimes it is necessary for M2PA to fail the link, and not receiving
> LSR(1) for seconds after sending LSPR is one of those times.

MTP3 will fail the link in T1 (2 seconds).

> As Brian suggests, for the scenario to happen, something serious must
> go wrong.  So why keep the link aligned when something has gone
> seriously wrong?

I did not say that something was seriously wrong: I said that the only
reason for a delay from a validated implementation was a transport
delay.  As LSPR is sent in the data stream, this could simply be
because of HOL blocking on user Data messages already queued for
delivery to the peer by SCTP with a closed cwnd, not anything serious.

Whether the blockage of the link is "of long duration" is an MTP 3
concept already address by Q.704 with the T1 timer.

> it can only happen for contrived test cases (of which I have at least
> one)?

I'm saying that failing in the link at MTP 2 is not proper SS7 engineering
because it causes MTP 3 to unnecessarily discard messages.  MTP 3 must
be allowed to decide whether to clear buffers or resume the link so that
buffered messages can be properly treated at each end with minimal
message loss.  This invented procedure at MTP 2 stands to impair MTP's
ability to provide an expected grade of service to its users.

If you fail the link any time before MTP 3 T1 when the link could have
recovered within T1, you will cause a changeover where none was
necessary.  An increased number of changeovers increases the number of
lost, duplicated and missequenced messages.  ANSI T1.111.4/Q.704
explicity warn about this.  So, by failing the link before T1, the
opposite of the desired effect results.

If you wait until after T1, MTP 3 will complete changeover anyway whether
the link is later failed or not.

> Brian, please explain in more detail why this form of 'failing the
> link' results in more message loss than other forms of 'failing the
> link', such as association failure.

It doesn't.  What contributes increased message loss and missequencing
is the fact that failing the link when it was not necessary to do so
increases the number of changeovers which increases message loss and
missequencing.  By not adding this procedure, MTP 3 is fully in control
of when it performs a changeover on a blocked link and will properly
handle the disposition of buffers (i.e. can resume without changeover).

> Please explain why M2PA should not fail a blocked link when the
> association fails. Citing applicable standards text would be a good
> start.

I did not say that M2PA should not fail a link when the association
fails.  The proposed standard RFC 4165 section 4.1.7 addresses link
failure due to SCTP Communication Lost notification to M2PA.

> I know of a few large operators who disagree with it as written.

Yes, I would expect that "operators" would be concerned with
"operational considerations", but they have little place in IETF
protocol specifications.

> expiry is not the best mechanism for achieving this.

Funny you should mention ATM.  Q.2210 does not replace the Q.703
AERM/SUERM with an extra mechanism in MTP3b: SSCOP performs error
detection and receives indications from AAL5.  In a similar way under
M2PA, SCTP performs error detection and receives indications from IP.
Neither in MTP3b nor in M2PA are separate error mechanisms instituted
beyond T7.  When developing the RFC we agreed by consensus to follow
closely the already tried and true model of Q.2210.

Also, any method you can imaging will not be applicable to all IP
network scenarios.  This is best addressed at the network and SCTP
levels.  SCTP parameters can be adjusted to acheive just about whatever
objectives an operator has.  IP is so flexible that it can be closely
constrained if desired: an operator can run MPOA or CLIP over a CBR VC
over ATM AAL5 if they want.  Or they could run a priority VLAN on IP
running directly over SONET.

Understand that it is outside the scope of the SIGTRAN WG to come up
with new QOS protocols or procedures.  There are ample protocols,
mechanisms and procedures available to operators as provided by the
IETF in other transport area working groups.

This _is_ the rationale and consensus that the WG took during the
development of the M2PA protocol and approved by the WG when the
RFC was issued.  I don't know why you would want to undermine that
consensus now.

--brian

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

---

From: Andrew Booth <[email-masked]>
Date: Mon, 29 May 2006 16:03:59 -0400

Hi,

>invention or just a bug of an implementation.
I think the RFC does (implicitly) say to ignore LS Ready during proving.
If I recall correctly, MTP2 (q.703/T1.111.3) ignores FISU during
proving. Hence in the absence of specific text, M2PA should ignore LS
Ready during proving.

The successfull M2PA implementors seem to have figured out that this
doesn't work since M2PA is not required to repeat LS Ready the way MTP2
repeats FISU. I would guess that everyone has concluded that they should
accept LS Ready during proving.

That doesn't mean the RFC wording is correct. If an implementor's guide
does go forward I think it's worth including some clarifying text,
something similar to what Jeff has in section 2.5 of his document.

[snip]

>MTP3 will fail the link in T1 (2 seconds).
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.

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

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.

>delivery to the peer by SCTP with a closed cwnd, not anything serious.
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?

Regards,
Andrew

[snip]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 29 May 2006 15:01:26 -0600

Andrew,

Andrew Booth wrote:                          (Mon, 29 May 2006 16:03:59)
> proving. Hence in the absence of specific text, M2PA should ignore LS

Well, no, but it explicitly says:

   The Link Status Ready message replaces the FISU of MTP2 that is sent
   at the end of the proving period.  The Link Status Ready message is
   used to verify that both ends have completed proving.  When M2PA
   starts timer T1, it SHALL send a Link Status Ready message to its
   peer in the case where MTP2 would send a FISU after proving is
   complete.  If the Link Status Ready message is sent, then M2PA MAY
   send additional Link Status Ready messages while timer T1 is running.
   These Link Status Ready messages are sent on the Link Status stream.

   In the case that MTP2 sends an MSU or SIPO message at the end of
   proving, M2PA SHALL send (respectively) a User Data or Link Status
   Processor Outage message.

How about changing the one line

   peer in the case where MTP2 would send a FISU after proving is

to

   peer in the case where MTP2 would send FISU(s) after proving is

Is that satisfactory?  I don't think that it merits changing a page
of text, possibly breaking other things.  Particularly when a M2PA
link that ignores LSR will not even align with itself.

(I'll reply separately on the second part.)

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 30 May 2006 03:04:27 -0600

Andrew,

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

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

> periodic SLT procedure is optional, but practically it is used fairly

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

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

> 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-masked]
http://www.openss7.org/

---

From: Andrew Booth <[email-masked]>
Date: Tue, 30 May 2006 11:53:36 -0400

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 30 May 2006 10:05:07 -0600

Andrew,

Andrew Booth wrote:                                  (Tue, 30 May 2006 11:53:36)
> once I've had time to absorb it.

Take your time.  One more issue regarding failing the link in such a manner:
there is no failure reason in the MTP L2 MIB that corresponds to such a link
failure.  Excessive delay of acknowledgement is not appropriate.

--brian

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

---

From: Andrew Booth <[email-masked]>
Date: Tue, 30 May 2006 12:55:07 -0400

Hi Brian,

I appreciate that minimal corrections leave less room for errors, but I
think your recommendation on its own may be a bit too subtle.

What I do like about Jeff's description is that the issue under
discussion is very clearly laid out, that page of text is informative
only and hence has a minimal risk of introducing errors.
I don't see any errors introduced in Jeff's proposed text, but if
minimal changes are desirable perhaps the following (it may be possible
to shorten things up even more):

2.5.3.        Text Changes

   Original Text (4.1.3. Link Alignment)
   ---------------------------------------------------------------------
   The Link Status Ready message replaces the FISU of MTP2 that is sent
   at the end of the proving period.  The Link Status Ready message is
   used to verify that both ends have completed proving.  When M2PA
   starts timer T1, it SHALL send a Link Status Ready message to its
   peer in the case where MTP2 would send a FISU after proving is
   complete. If the Link Status Ready message is sent, then M2PA MAY
   send additional Link Status Ready messages while timer T1 is
   running. These Link Status Ready messages are sent on the Link
   Status stream.

   New Text
   ---------------------------------------------------------------------

   (Paste in old text here).

   While timer T4 is running, M2PA SHOULD mark reception of either a
   Link Status Ready message or a Link Status Processor Outage message.
   Upon expiration of timer T4, M2PA SHOULD check whether a Link Status
   Ready message or a Link Status Processor Outage message was
   received, and if either message was received, M2PA SHOULD NOT start
   timer T1 and instead SHOULD operate as if the message had been
   received after timer T1 had been started. If neither message was
   received during proving, then M2PA SHOULD start timer T1 and proceed
   according to the applicable MTP2 standard.

Brian, Jeff, any thoughts on this?
Andrew

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 30 May 2006 11:19:44 -0600

Andrew,

Andrew Booth wrote:                                                (Tue, 30 May 2006 12:55:07)
>    Original Text (4.1.3. Link Alignment)

Several problems with that text.  It misses User Data (MSU) which is an
appropriate way of completing alignment.

Also, it does not indicate that when configured for proving either a
Link Status Proving Normal message or a Link Status Proving Emergency
message must be received before the LS Ready, LS PO or User Data can
be considered valid.  Also, the messages must contain the correct sequence
numbers to be considered valid as well.  It is not just the fact that
T4 is running that makes these messages valid.

This is the problem we faced when we developed the RFC: if you start
describing part of the state machine, you wind up describing large portions
of it, duplicating one standard.  There are subtle differences between
standards even during alignment.  ANSI and ITU SDLs are different in this
regard, and that is not even considering TTC.

I would be safer to say that the LS Ready replaces the FISU(s) sent after
proving.  If you want, stress the fact that once the LS Ready is sent, the
receiver should consider it in lieue of any FISU that might have otherwise
been sent after T4 expires.

--brian

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