Re: 'abnormal BSN' handling in M2PA

debasri,

debasri Sarkar wrote:                                              (Thu, 05 Jul 2007 12:20:35)
> 
>    Hi,
> 
>    I need some clarification regarding 'abnormal BSN' handling in M2PA.
> 
>    According  to  ITU-T specification Q.703, if two out of three received
>    message
>    have  wrong BSN, the message signal unit or fill in signal unit should
>    be
>    discarded.  Also  level 3 is informed that the link is faulty (section
>    5.3.1).
> 
>    Question 1:
>    -----------------
>    This   is  contradicting  with  the  test  case  3.8.10  specified  in
>    draft-bidulock-sigtran-m2pa-test-08.
> 
>    Test Description:
>    (1)   The test begins with the link in the "In Service" state.
>    (2)   Send a Data message to the IUT with an abnormal Backward
>             Sequence Number.
>    (3)   Check that the IUT acknowledges the Data message delivers an
>             MSU to Level 3 at the IUT.
>    (4)   Send a Data message to the IUT with an normal Backward Sequence
>             Number.
>    (5)   Check that the IUT acknowledges the Data message delivers an
>             MSU to Level 3 at the IUT.
>    (6)   Check that the IUT maintains the "In Service" state.
> 
>    In step 3 M2PA should not deliver the data to level 3 and should not
>    acknowledge the data. It should silently discard it.

Well, no.  Look a Test Case Q.781/8.10.  The expected behaviour for Q.703 is
that the receiver of the MSU with the bad BSN discards the MSU but sends a
negative acknowledgemnet for the FSN causing the sender to retransmit the MSU
(hopefully with a correct BSN).  M2PA can neither negatively acknowledge nor
retransmit.  Therefore, the original message with the bad BSN must be
accepted (but of course the BSN not processed).  (Yes, this should have been
stated in RFC 4165 but wasn't.)

> 
>    Question 2:
>    -----------------
>    In  test  case  3.8.11  of draft-bidulock-sigtran-m2pa-test-08, out of
>    service message
>    is  send  from  IUT  after a DATA_ACK message with normal BSN when two
>    DATA_ACK
>    message is received with abnormal BSN previously.
> 
>       ___________________________________________________________________
> 
>    |
>                                                    |
>      |   VAT:
>    PT                                    IUT                      |
> 
>    |
>                                                    |
>      |              DATA-ACK  --FFFFFF,
>    7FFFFF->                                                      |
>      |              DATA-ACK  --FFFFFF,
>    7FFFFF->                                                      |
>      |              DATA-ACK  --FFFFFF,
>    FFFFFF->                                                      |
>      |
>    <-----------------  OUT-OF-SERVICE         |
> 
>    |
>                 !out of service                |
> 
>    |
>                                                    |
> 
>    |___________________________________________________________________|
> 
>    When  two  DATA_ACK has been received with wrong BSN value, why should
>    we wait
>    for  next DATA_ACK (with or without correct BSN value) to indicate the
>    link as a
>    fauly link?
>    Rather,  OOS  message can be trasmitted to peer along with proper link
>    status indication
>    to level 3 just after reception of 2 consecutive wrong BSN reception.

Test case Q.781/8.11 shows it that way with FISUs too.

In general, even though IUT may send an OUT-OF-SERVICE in response to the second
DATA-ACK, it does not prevent the PT from emitting the third DATA-ACK before
the OUT-OF-SERVICE arrives.


--brian



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