Subject: RE: [Sigtran] SIGTRAN Interop, Day 3 - M2PA v13 Procedures

From: [email-masked]
Date: Thu, 15 Sep 2005 05:55:51 -0700

Thanks, Brian, appreciate your response. 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, September 15, 2005 7:40 AM
To: Hastings, Charles
Cc: [email-masked]
Subject: Re: [Sigtran] SIGTRAN Interop, Day 3 - M2PA v13 Procedures

charles.hastings,

[email-masked] wrote:
(Thu, 15 Sep 2005 04:03:44)
> All,
> 
> As Michael indicated in his original email, here are the M2PA v13 
> issues observed at the SIGTRAN Interop, Day 3:
> 
> -In M2PA v13, an interpretation of the LPO Procedure / Process as
> follows:-
> When an IPSP (A) enters LPO, the Link Status LPO is sent to the Peer 
> IPSP (B).
> During LPO, IPSP A will not send User Data to B, nor will it Ack User 
> Data received from B.
> When IPSP A then sends LS PR to IPSP B, it will continue to not send 
> User Data to B, nor will it Ack User Data received from B until LS 
> Ready are exchanged.
> Once LS Ready are sent and received from A and B, User Data and Acks 
> will start.
> 
> 1. Comments on this interpretation?
> 2. Minor question: should there be any timer or other mechanism that 
> checks against receipt of Peer's LS Ready after PR has been sent?

We already pretty much agreed to alter this in 48 Hours (which is now)
to allow data transmission once the peer has _sent_ LS Ready rather than
when it has _received_ it.  The other timer in play is MTP3's T1 timer
that will fail the link if it is blocked too long.

> 
> -RPO / LS Ready receipt behavior in M2PA v13- In M2PA v13, when a peer

> IPSP (A) is in RPO, and receives LS PR from the peer IPSP (B), IPSP 
> (A) sends LS Ready.
> In the case where IPSP (B) never sends LS Ready in response, what 
> should be the behavior at IPSP (A)?

The above modification handles that.  IPSP (A) starts sending data once
it has _sent_ LS Ready.

> 
> -It was generally agreed by the group here that an IPSP should enforce

> the SCTP Stream Mapping for messages sent as defined in version 13, 
> but should accept messages on either stream on the receive side.-

It would be foolish to accept message on either stream, because placing
message on the wrong stream will result in missequencing and loss of
messages across a number of procedures.  Any implementation that is that
lax at sending them should use UDP. ;)

--brian

> Regards,
> Charles

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

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