Subject: RE: [Sigtran] M2PA Alignment Clarification

From: "Newman, Catherine J" <[email-masked]>
Date: Tue, 3 Oct 2006 18:38:40 -0400

Brian,

I'm not sure I understand your suggestion...
There is no indication to M2PA of remote SCTP acknowledgment, and no
M2PA acknowledgement for LSSUs (even T7 does not apply). 

Per the M2PA RFC section 4.1.3, "it is RECOMMENDED that the
Proving_Interval be set so that the traffic load generated with the Link
Status Proving messages during the proving period is comparable to the
normal traffic load expected when the link is in service."  Therefore,
it doesn't seem that this is meant to be a timeout.

Going back to the original issue, the far end had recently sent LSPN (or
LSPE) followed by an LSR on stream 0. Since it received an LSR from the
near end, it also sent an SLTM on stream 1. The SCTP protocol doesn't
guarantee ordering between streams, thus the proving messages (last few
LSPN/LSPE and LSR) and SLTM can be received in the reverse order from
what was sent - I don't see why this should be considered an error. The
comparable scenario doesn't exist in MTP2 (on which the M2PA RFC
alignment/proving procedures are based) since there are 2 streams in
M2PA which creates additional race conditions that don't exist in MTP2.
The M2PA RFC should explicitly address this scenario.

Thanks,
Cathy Newman

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Tuesday, October 03, 2006 10:39 AM
To: Erickson, Mark
Cc: [email-masked]
Subject: Re: [Sigtran] M2PA Alignment Clarification

Mark,

Just wait until all your proving messages (or the LSR) have
been acknowleged by the peer SCTP before sending DATA.

Otherwise, choose your Proving_Interval more wisely.

--brian

Erickson, Mark wrote:                     (Tue, 03 Oct 2006 09:12:37)
> Brian:
> 
> So, a stream synchronization error was created during alignment due to
> normal, real-life network conditions.  How should the link recover -
> that was my original question?  Force the link down and attempt to
> re-establish the link?
> 
> Is there a better method?  What about acknowledging the proving
messages
> in some fashion?

-- 
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: Tue, 3 Oct 2006 17:06:20 -0600

Catherine,

Newman, Catherine J wrote:                (Tue, 03 Oct 2006 18:38:40)
> M2PA acknowledgement for LSSUs (even T7 does not apply). 

All implementations are capable of providing this indication.  When
proving messages are sent they are delivered to SCTP where they
consume send buffer space.  When they are acknowledged by the SCTP
peer, their space is added back to the available send buffer space.
The sending application can always check when they have all been
acknowledged, by checking the available send buffer.  This can be
done most expediently when T4 expires.

SS7 MTP2 does not presume an implementation.  SCTP has only one
physical wire (per interface) also.  SCTP choses which messages are
sent from which streams.  So can an implementation of SS7.  MTP2
provides guidance in this area: it says that LSSU take priority
over DATA to the wire.  Using the buffer technique above, you can
restore MTP2 prioritization of messages to the wire by not sending
the SLTM until the proving messages have been acknowledged.

--brian

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