Re: 'abnormal BSN' handling in M2PA

Hi Brian,

Thanks a lot for the explanation.

For question 1, it is justified that we can send data indication to level 3
user
and DATA_ACK to PT, as there is no way to send a negative acknowledgement.

For question 2, it is absolutely right that the M2PA test draft is inline
with Test case Q.781/8.11
of MTP2 test specification. But, if OOS is  send after 2 wrong BSN reception
(not waiting
for the third), will it violate the MTP2 specs Q.703/5.3.1 ? What is your
view in this regard?

Thanks again for your time.

Regards,
Debasri

On 7/10/07, Brian F. G. Bidulock <[email protected]> wrote:
>
> 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.703is
> 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/
>

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