Re: M2PA: Abnormal BSN received in any two BSNs within three consecutive packets

Debasri,

RFC 4165 states:

| 4.  Procedures
| 
|    Because M2PA provides MTP3 with an interface and functionality like
|    MTP2, its internal functioning is similar to that of MTP2.
| 
|    Except as modified in this document, M2PA SHOULD follow the
|    requirements of the applicable MTP2 specification.  These may include
|    [Q.703] or [T1.111].  The same standard MUST be followed on both ends
|    of the M2PA link.

Abnormal BSN handling is one of these procedures not modified by the RFC,
so you should handle abnormal BSN in the same fashion as the applicable
standard.  One case where you might not want to do that is when attempting
to directly translate/convert from MTP2 to M2PA, but it is applicable in
most regular M2PA applications (thus the SHOULD instead of a MUST).

Some time after M2PA-06, we decided to remove all of the text from M2PA
that was common with, and a verbatim repetion of, Q.703.  One reason was
copyright concerns, another was avoiding conflicts between the wording in
M2PA and the wording in, for example, Q.703.  Also, depending on the
applicable standard, we would have had to say: do this for Q.703 and do
that for Q.2110, and so it became unmanageable.  Therefore, if M2PA says
nothing on a procedure like Abnormal BSN, consult the MTP2 standard and
follow its procedures where possible.

I hope that helps.

--brian

debasri Sarkar wrote:                             (Wed, 30 May 2007 18:00:45)
> 
>    Hi,
> 
> 
> 
>    I  have  a query related to the behaviour of M2PA stack, when abnormal
>    BSN is received in any two BSNs within three consecutive packets.
> 
> 
> 
>    M2PA  draft  draft-ietf-sigtran-m2pa-06.txt  had  mentioned  about the
>    behavior of 'Abnormal BSN
>    handling'  explicitly  (refer  to  section  4.2.1).  But,  it has been
>    removed from latest RFC 4165
>    section 4.2.1.
> 
>    What should be the correct behavior of M2PA stack when it receives two
>    incorrect BSNs in
>    three consecutive data_ack/data+data_ack ?
> 
>    Will  it silently drop the packet and does not send data indication to
>    user application (in
>    case of data with a piggybacked data_ack)? The link remains IN_SERVICE
>    if this solution
> 
>    is taken.
> 
> 
> 
>    Or,   will   it   make  the  link  Out  of  Service  as  mentioned  in
>    draft-ietf-sigtran-m2pa-06.txt after
> 
>    receiving two abnormal BSNs in three consecutive packets?
> 
> 
> 
>    Thanks for giving your valuable time to read this query.
> 
> 
> 
>    Regards,
> 
>    Debasri Sarkar

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


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