Subject: RE: [SIGTRAN] M2PA - Local Processor Outage/Processor Recovered P rocessing

From: Hecht Martin <[email-masked]>
Date: Tue, 6 Apr 2004 17:17:03 -0400

Brian,

You are, of course, correct that the concept of Long and Short RPO is MTP-3,
it is just that in our implementation MTP-2 is somewhat aware of whether the
RPO is short or long. As my questions involved LPO and RPO I thought that
this was pertinent.

As I understand your response, when the diagrams in the draft (pgs 40 and
41) refer to a flush taking place, they are referring to a flush initiated
by L3, not by M2PA.

Is this correct?

Thus, if the inbound messages are buffered during LPO, and there is no flush
request from L3, then those buffers will be processed.  The same thing
basically on the RPO side.

Correct?

Thank you for your response,

Martin Hecht
Signaling Core Group, Embedded Division
Comverse, Inc

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, April 06, 2004 4:54 PM
To: Hecht Martin
Cc: SIGTRAN Mailing List (E-mail)
Subject: Re: [SIGTRAN] M2PA - Local Processor Outage/Processor Recovered
Proce ssing

Hecht,

Hecht Martin wrote:
(Tue, 06 Apr 2004 10:21:58)
> To interested M2PA parties,
> 
> I have a couple of questions concerning LPO/RPO, LPR/RPR in accordance
with
> draft-ietf-sigtran-m2pa-11.
> 
> I can see the basic relationship between the MTP-2 and M2PA processing of
> the Processor Outage conditions.  In MTP-2 there is a short and a long RPO
> condition; while in M2PA there is only RPO.

Q.703 (MTP2) does not have a short and long RPO concept.  Q.704 (MTP3) has a
short and long RPO concept.

> 
> In MTP-2 RPO ends when a FISU or MSU is received; all messages in the TB
and
> RTB are deleted and the FSN is "reset" at that point, i.e.,
> resynchronization occurs.  I can see how this is "mapped" to M2PA.
> 
> What I don't see is, referring to pg. 40:
> 
> While in LPO, A must buffer messages 14-16 without acknowledging them.
> 
> While in RPO, B may continue acknowledging messages.
> 
> LPO ends at A.  A flushes 14-16 (the messages that were buffered without
> acknowledgement).
> 
> Why are 14-16 flushed?  Why were they buffered in the first place?

In the example, processor outage is of long term at A, and MTP3 flushes the
messages.  If processor outage were of short term, they would not be
flushed.

> 
> This means that 14-16 are lost.

Not necessarily.  Because these messages are not acknowledged to B from A, B
will retransmit these messages on another link as part of the normal
changeover procedure, providing that B does not consider the outage to be of
long term.  If B also considers the outage to be of long term, it will flush
these messages from its RTB.

> 
> On pg. 41:
> 
> B flushes 6 from its Receive Buffer.
> 
> Why is this buffer flushed?

For the same reason as above.  When MTP3 at A flushes buffers it flushes RB,
TB and RTB.

> 
> This means that buffer 6 is lost.

Not necessarily, because it was not acknowledged, it could be retransmitted
on another link (processor outage short term) or intentionally flushed
(processor outage long term).

Consider that whether processor outage is of long term or short term is
determined by MTP3 using timer T1 at Level 3, not Level 2.  The example is
one where Q.704/T1 expires at A.

--brian

> 
> Thanks,
> Martin Hecht
> Signaling Core Group, Embedded Division
> Comverse, Inc
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
______________________________________________________________________
  This email message has been scanned by PineApp Mail-Secure and has been
found clean.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Apr 2004 16:51:53 -0600

Hecht,

Hecht Martin wrote:                                                                  (Tue, 06 Apr 2004 17:17:03)
> RPO is short or long. As my questions involved LPO and RPO I thought that

M2PA is specifies with the traditional L2/L3 split.  If your implementation of
MTP2 includes partial MTP3 functionality (as is often done with dedicated
link equipment) your M2PA implementation could either incorporate this partial
L3  or the partial L3 could be layerd on top of M2PA.

> 41) refer to a flush taking place, they are referring to a flush initiated

Yes.  Even though the signal to flush might be coming from a partial L3
implemented in the link entity, it is still coming from L3 and not M2PA.

> basically on the RPO side.

Yes.  Same as the LPO side.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Apr 2004 17:11:12 -0600

Hecht,

You might also take a look at test case 3.4.1 in

  http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-m2pa-test-05.txt

as it describes the L3->L2 primitives in more detail.

Actaully, I had to resubmit m2pa-test-05 because it was sumbitted during
the last cut-off.  Until it appears, you can get it here:

  http://www.openss7.org/docs/draft-bidulock-sigtran-m2pa-test-05.txt

Which brings up another note, perhaps it would be a good idea to advance this
test specification to on INFORMATIONAL RFC on the tail of M2PA.

Comments?

--brian

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