RE: M2PA Alignment Clarification

I don't believe M2PA would necessarily have access to TSN #s...per SCTP,
10.2 A - DATA Arrive notification doesn't include the TSN # (just the
assoc id and stream id). [M2PA assumes ordered delivery by stream and
has it's own sequence numbers...I don't think it needs TSN information.]
If not, M2PA will not know about the missing messages on stream 0. SCTP
does ordered delivery within a stream, and won't deliver up to M2PA the
LSP/LSR messages until the missing/late message is received on stream 0
but will deliver up the SLTM since it is a different stream. So even if
an M2PA implementation is following M2PA RFC 4.1.8 to the letter (within
the M2PA layer), there could be no messages on stream 0 to read at this
point and the race condition could still apply. 

I agree that if both ends wait to send the LSR/data until all LSP
messages are ack'd (it'd have to be determined indirectly by checking
the # of unack'd messages using the Status primitive to SCTP, per SCTP
RFC 10.1 H) this issue will be resolved - but as previously stated this
has to be a requirement of the M2PA spec, or the issue will remain when
connecting with implementations that don't do this. 

Is this the best way to resolve the issue? The initial option proposed
was to ignore LSP messages received in the In-service state (again, a
spec change is needed since it'd differ from MTP2 procedures) - anyone
see any issues with this? 

Any else have input? I know there are a lot of M2PA implementations out
there... I would hate to not clarify the spec if there is a potential
for interoperability issues between what could be conforming
implementations... 

Cathy Newman

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Wednesday, October 04, 2006 8:50 AM
To: Davidson, Mark
Cc: Newman, Catherine J; [email protected]; Erickson, Mark
Subject: Re: [Sigtran] M2PA Alignment Clarification

Mark,

Well, if the implementation does not follow the recommendations
of RFC 4165 section 4.1.8, then there will be a problem.

If, at the receiver, you should wait until it can be determined
that no messages are outstanding for stream 0 before reading data
messages on stream 1, per section 4.1.8.  When you read an SLTM
and have a missing TSN, as all M2PA messages are sent ordered,
you can easily detect that there is a missing message from stream 0.

Per 4.1.8, your receiver should wait until the link status stream
messages are read before processing messages read from stream 1.

Therefore, if you make your receiving implementation follow 4.1.8
to the letter, then you will not have a problem: it will wait until
all proving messages have been received before processing the SLTM.

--brian


Davidson, Mark wrote:                    (Wed, 04 Oct 2006 07:21:45)
> Brian,
> 
> I agree that if ALL senders wait for the last LSP to be acked by SCTP
> before sending LSR/DATA then the problem is fixed (though I dislike
> munging the layers in this way).  But the original problem is one for
> the receiver, not the sender.  I.e., the receiver cannot guarantee
that
> the far end follows this procedure.  Changing what is sent, doesn't
help
> guarantee what is received.  We don't get to assume the same vendor on
> both ends.  So the problem remains.
> 
> -Mark Davidson
> 

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