Re: M2PA questions on synchronization and message handling

Hi,



Brian F. G. Bidulock wrote:
> 
> Dario,
> 
> Dario wrote:                                     (Mon, 17 Dec 2007
> 03:47:00)
>> 
>> HI,
>> 
>> here are three questions for M2PA RFC 4165:
>> 
>> 1.	Synchronization after PO during Initial Alignment
>> the question is: is the synchronization in Initial Alignment identical to
>> synchronization in stable PO state in terms of exchanged messages and
>> procedures?
>> (at least – during Initial Alignment , there was no User Data messages
>> sent,
>> so what is the purpose of such sequence?)
> 
> Sequence numbers do not need synchronization during initial alignment
> because they are still at their initial values.
> 

OF course the sequence numbers do not need synchronization since there were
no
User Data messages exchanged at that point.
But my questions are the following:
- is the sequence of messages for synchronization the same in Initial
Alignment as in stable PO state:
  LS Processor Recovered ->
  LS Ready (1) <-
  LS Ready (1) ->

- how these messages collide with Link Status messages (for example, LS
Ready on stream 0) and what are the consequences?



Brian F. G. Bidulock wrote:
> 
>> 
>> 2.	when FLUSH primitive is received from MTP level 3 in M2PA, should
>> M2PA:
>> a.	flush outgoing buffers
>> b.	flush both outgoing and incoming buffers?
>> 
>> Perhaps it is not clear are both points a) and b) listed in RFC section
>> 4.1.4.  to be executed?
> 
> Yes, both.  Note that in (a) incoming buffers are not flushed, just
> messages
> that were queued and unacknowledged, which are the messages received
> during
> processor outage that could not be delivered to MTP3 from earlier on in
> section 4.1.4.
> 

Brian F. G. Bidulock wrote:
> 
>> 
>> 3.	Unexpected FSN and/or invalid BSN
>> The RFC states that 
>> „If M2PA receives a User Data message with an FSN that is out of order,
>> M2PA
>> shall discard the message“. (RFC4165, section 4.2.1)
> 
> The statement in RFC 4165 section 4.2.1 applies to an FSN that is out of
> order.
> 
>> 
>> In addition to that, Q.703 states
>> „In the case that a message signal unit or fill-in signal unit is
>> received
>> having a backward sequence number value which is not the same as the
>> previous one or one of the forward sequence number values of the signal
>> units available for transmission, the signal unit is discarded. The
>> following message signal unit or fill-in signal unit is discarded.
>> If any two backward sequence number values in three consequtively
>> received
>> message signal units or fill-in signal units are not the same as the
>> previous one or any of the forward sequence number values of the signal
>> units in the retransmission buffer at the time that they are received,
>> then
>> they are received, then level 3 is infomed that the link is faulty“
>> (section 5.3.1)
>> 
>> If M2PA is to follow all these statements that it would mean that
>> reception
>> of message with invalid sequence number would cause transition to Out Of
>> Service state:
>> 
>> For example:
>> -	User Data message with either unexpected FSN or invalid BSN is
>> received:
>> discard it
>> -	User Data with correct FSN (FSN=x) is received, it must be discarded
>> due
>> to Q.703 statement
>> -	Nex User Data with FSN=x+1 is received. This is now unexpected FSN
>> since
>> previously received message is discarded. Etc.
> 
> The statement in Q.703 section 5.3.1 applies to a BSN that is invalid.
> 
> You compare apples and oranges.
> 
> --brian
> 

not if they are connected:

1. message is received with invalid BSN. This message wil be discarded
2. User Data message is received with FSN=x, valid, but it should be
discarded according to Q.703 statement above.
3. User Data message is received with FSN=x+1. This is unexpected FSN and
the message will be discarded....and so on.

finally ack timer will expire and the link will go Out of Service.
 



-- 
View this message in context: http://www.nabble.com/M2PA-questions-on-synchronization-and-message-handling-tp14370241p14435533.html
Sent from the IETF - Sigtran mailing list archive at Nabble.com.