Subject: Re: [Sigtran] M2PA LPO during alignment/proving (was: M2PA version 7 changes)

From: [email-masked]
Date: Wed, 5 Feb 2003 14:11:13 -0500

Hello Tom,

>If M2PA is in ALIGNED READY and receives LS PO, it should go to ALIGNED
>NOT READY. When it gets LS Ready from the other end, then it would go to
>PROCESSOR OUTAGE.

I think you meant 'Local Processor Outage Request' (LPO) primitive from
MTP3, rather than 'LS PO' in the preceding paragraph.

I recommend that the M2PA state machine be split into two figures, one
that addresses the 'normal' alignment case, and another that addresses
the 'processor outage' case. I am not sure that the Q.703 SDL can be
accurately reproduced in a single text-style figure.

The M2PA state machine is missing transitions and has incorrectly labeled
transitions, relative to Q.703:

1) LSPO received during ALIGNED_READY  causes a transition to
PROCESSOR_OUTAGE (Q.703, figure 8, sheet 7 of 14).

2) LSPO or LSR received during ALIGNED_NOT_READY causes a transition
to PROCESSOR_OUTAGE (Q.703, figure 8, sheet 9 of 14).

3) LSPOE received during PROCESSOR_OUTAGE causes M2PA to notify
MTP3 of end of remote processor outage (no state transition).
(Q.703, figure 8, sheet 12 of 14).

4) In the absence of both local or remote processor outage,
a 'continue' primitive or 'flush buffers' primitive from MTP3
during PROCESSOR_OUTAGE causes a transition to IN_SERVICE
(Q.703, figure 8, sheet 13 of 14). Reception of LPR during
PROCESSOR_OUTAGE does not cause a transition, but rather
prompts M2PA to signal MTP3 (Q.703, figure 8, sheet 13 of 14).

5) A 'Local Processor Outage Request' (LPO) primtive received from MTP3
during PROCESSOR_OUTAGE results in no state transition, though M2PA
records the LPO state.

----

After all of this....
Perhaps M2PA, just like SAAL/ATM, should abandon support of this
obsolete (processor outage) procedure, and instead, fail the link
when it receives the LPO primitive from MTP3. Many, if not most,
modern MTP3 implementations never generate this primitive.

Why does M2PA need processor outage? SAAL/ATM does just fine
without it.

Regards,

Jeff

Tom George <[email-masked]>@ietf.org on 02/05/2003 12:28:35 PM

Sent by:    [email-masked]

To:
cc:    [email-masked]
Subject:    Re: [Sigtran] M2PA LPO during alignment/proving (was: M2PA
       version 7  changes)

Franz,

Comments below...

Gaiser Franz wrote:
>
> Hi All,
>
> two additions to the Link State Transition Diagram below:
>
> 1.) Figure 7. M2PA Link State Transition Diagram:
> Missing the handling of receiving LS PO in state ALIGNED READY:
Situation: After Proving the local side is in state ALIGNED READY and sends
LSR; the peer side is in state ALIGNED NOT READY experiencing Processor
Outage and starts sending LS PO. To which state the local M2PA is moving ?
Transition to PROCESSOR OUTAGE ? If so, the state PROCESSOR OUTAGE handles
both local and remote processor outage and then there must be an arrow from
PO to IN SERVICE in case of receiving LS PO Recovered (and there is no
local PO situation).

If M2PA is in ALIGNED READY and receives LS PO, it should go to ALIGNED
NOT READY. When it gets LS Ready from the other end, then it would go to
PROCESSOR OUTAGE.

I updated the diagram accordingly. See below.

>
> 2.) Figure 7. M2PA Link State Transition Diagram:
> Missing the handling of receiving User data in state ALIGNED NOT READY.
Transition to PROCESSOR OUTAGE ? What is to do with this message then (to
be discarded) ?

We are in the middle of discussing this in another thread. It looks like
User Data should not be sent/received when in ALIGNED NOT READY. If it
can happen, it would be an error case that I would prefer not to show in
the diagram.

> regards, franz

Updated piece of the diagram:

  |                       |   +-----+                  |
  |                       |   |     | LPO/LPR          |
  |                       V   V     |                  |
  |                 +-----------+   |                  |
  |                 |  PROVING  |---+                  |
  |<----------------|           |--------------------->+
  |      MTP3 Stop  +-----------+     SCTP Comm Error  |
  |   OR T3 Expiry        |  |     OR SCTP Comm Lost   |
  |   OR Receive LS OOS   |  |                         |
  |                       |  +-------------------------|--------+
  |                       |     T4 Expiry              |        |
  |                       |     Send LS PO             |        |
  |                       |                            |        |
  |                       | T4 Expiry                  |        |
  |                       | Send LS Ready              |        |
  |                       |                            |        |
  |                       |                            |        |
  |                       V           SCTP Comm Error  |        V
  |                 +-----------+  OR SCTP Comm Lost   |  +-----------+
  |                 |  ALIGNED  |--------------------->+  |  ALIGNED  |
  +<----------------|   READY   |<----------------------->| NOT READY |
  |      MTP3 Stop  +-----------+     LPO/LPR             +-----------+
  |   OR T1 Expiry        |        OR Receive LS PO/PR       |       |
  |   OR Receive LS OOS   |                                  |   T1  |
  |   OR Receive LS Align | Receive LS Ready      Receive    | Expiry|
  |                       | OR Receive User Data    LS Ready | OR Rcv|
  |                       |                                  |    LS |
  |                       |                                  |  Align|
  |                       |                                  |       |
  |                       V                                  V       |
  |                 +-----------+                      +-----------+ |
  |                 |    IN     |<-------------------->| PROCESSOR | |
  |                 |  SERVICE  |     LPO/LPR          |   OUTAGE  | |
  |                 +-----------+  OR Receive LS PO/PR +-----------+ |
  |                       |                                  |       |
  |                       |                                  |       |

--
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas 75075  *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

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