Subject: Re: AW: [Sigtran] M2PA draft 07 comment: LPO

From: [email-masked]
Date: Wed, 19 Feb 2003 11:18:39 -0500

Hello Tom,

My lengthy responses are below.

Regards,

Jeff

                      Tom George                                                                                                  
                      <Tom.George@alca         To:                                                                                
                      tel.com>                 cc:      [email-masked]                                                          
                      Sent by:                 Subject: Re: AW: [Sigtran] M2PA draft 07 comment: LPO                              
                      sigtran-admin@ie                                                                                            
                      tf.org                                                                                                      

                      02/18/03 05:59                                                                                              
                      PM                                                                                                          

>Jeff,
>
>One thing that confuses me about this diagram is the distinction between
>ALIGNED and PROVING. It looks like both ends would get to ALIGNED, start
>T3 and wait for the other end to send LS Proving. But they don't send LS
>Proving until they go to PROVING, so it looks like both ends would just
>sit and let their T3s expire.

Multiple-paged SDLs are such fun, aren't they? I obviously have joined
you in confusion, considering my previous timer T1 post.

Q.703 figure 9 sheet 2 shows that either LSPx should be sent
upon transition to ALIGNED from NOT_ALIGNED. LSPx is repeatedly sent
during PROVING. This ensures that during successful alignment a peer
will receive LSPx during ALIGNED, will disable T3, and move to
PROVING (shown on figure 9 sheet 3).

The ALIGNED state is used to ensure that a LSPx is received.
The PROVING state is used to ensure the viability of the link under
greater load, greater message size. It may also be used for MTU
discovery, opening SCTP windows, etc.

>
>So I have the sending and receiving of LS Proving messages going on in
>the PROVING state.
>

M2PA PROVING procedure matches Q.703, but INITIAL_ALIGNMENT
does not currently match, leading to the confusion over when
to send/receive LSA and LSPx. That is why I suggest that the
NOT_ALIGNED and ALIGNED states be used in place of the singular
INITIAL_ALIGNMENT state.

>
>BTW, I would be very happy to reference Q.703 wherever possible and am
>open to suggestions on how to do it. Unfortunately, there are parts of
>the SDLs that do not apply to M2PA (e.g., sending FISUs), so I have been
>stumped on how to do this.

Yes, I understand that it is a challenge. In section "4.1.3 Link
Alignment", I think it would be helpful to reference the Q.703 SDLs
as a guide and list the basic equivalence between the M2PA and
MTP2 primitives:

LSA  == SIO
LSB  == SIB
LSO  == SIOS
LSPN == SIN
LSPE == SIE
LSPO == SIPO
Data == MSU

For each paragraph in section 4.1.3, one could reference the applicable
SDL figure and sheet. This may be excessive, but I think it would add
clarity. Here follows my attempt to revise the draft based on the
recent alignment and LPO discussions:

----------------
OLD TEXT 4.1.3
After the association is established, M2PA SHALL send a Link Status
Out of Service message to its peer.

NEW TEXT 4.1.3
After the association is established, M2PA SHALL send a Link Status
Out of Service message to its peer and, prior to receiving a Start
Request from MTP3, MAY periodically send Link Status Out of
Service messages ([Q.703] Figure 4 and Figure 8 Sheet 1). During
the Out of Service State M2PA SHOULD ignore received Link Status
Out of Service messages and SHOULD respond to all other received
messages by sending a Link Status Out of Service message."

----------------
OLD TEXT 4.1.3

Once the association is established and M2PA has received a Start
Request from MTP3, M2PA sends the Link Status Alignment message to
its peer. If M2PA has not already received the Link Status Alignment
message from its peer, then M2PA starts timer T2.

NEW TEXT 4.1.3

Once the association is established and M2PA has received a Start
Request from MTP3, M2PA sends the Link Status Alignment message to
its peer and moves to the NOT_ALIGNED state ([Q.703] Figure 9
Sheet 1).

----------------
OLD TEXT 4.1.3
M2PA stops timer T2 when it has received the Link Status Alignment
message from its peer.

NEW TEXT 4.1.3
M2PA stops timer T2 when it has received a Link Status Alignment
message or Link Status Proving Normal or Link Status Emergency
message from its peer. It sends a Link Status Proving message,
starts timer T3, and then moves to the ALIGNED state ([Q.703]
Figure 9 Sheet 2).

----------
OLD TEXT 4.1.3
Note: Between the time M2PA sends Link Status Alignment to its peer
and receives Link Status Alignment from its peer, M2PA may receive
Link Status Out of Service from its peer. This message is
ignored. After receiving Link Status Alignment from the peer, receipt
of a Link Status Out of Service message causes M2PA to send Out of
Service to MTP3 and return to the Out of Service state.

NEW TEXT 4.1.3
Note: During the NOT_ALIGNED state M2PA may receive Link Status Out
of Service from its peer. This message is ignored. After moving to
the ALIGNED state, receipt of a Link Status Out of Service message
causes M2PA to send Out of Service to MTP3 and return to the Out of
Service state ([Q.703] Figure 9 Sheet 4).

----------
OLD TEXT 4.1.3

When M2PA has both sent and received the Link Status Alignment
message, it has completed alignment.  M2PA starts the aligned timer
T3 and moves to the proving state.

M2PA stops timer T3 when it receives a Proving Normal or Proving
Emergency message and starts proving period timer T4.

If timer T3 expires, then M2PA reports to MTP3 that the link is out of
service.  M2PA sends Link Status Out of Service to its peer.  M2PA
SHOULD leave the association established.  M2PA waits for MTP3 to
initiate the alignment procedure again.

During the proving period (i.e., after M2PA starts the proving period
timer T4), M2PA sends Link Status Proving messages to its peer at an
interval defined by the protocol parameter Proving_Interval. M2PA
sends either the Proving Normal or Proving Emergency message,
according to the Emergency and Emergency Ceases commands from
MTP3. M2PA uses the value of T4 corresponding to the Normal or
Emergency condition. However, if M2PA receives a Link Status Proving
Emergency message from its peer, then M2PA SHALL initiate the
Emergency proving period value for T4, but it SHALL continue to send
the Proving message (Normal or Emergency) determined by its own upper
layer MTP3.

NEW TEXT 4.1.3

Upon receiving either Link Status Proving Normal or Link Status
Proving Emergency during the ALIGNED state, M2PA stops timer T3,
starts proving period timer T4, and enters the PROVING state
([Q.703] Figure 9 Sheet 3).

If timer T3 expires, then M2PA reports to MTP3 that the link is
out of service, sends Link Status Out of Service to its peer and
moves to the OUT_OF_SERVICE state ([Q.703 Figure 9 Sheet 4). M2PA
SHOULD leave the association established.

During the PROVING state M2PA periodically sends either Link
Status Proving Normal or Link Status Proving Emergency according
to the Emergency and Emergency Ceases commands from MTP3
([Q.703] Figure 9 Sheets 5 and 6). M2PA uses the value of T4
corresponding to the Normal or Emergency condition. However, if
M2PA receives a Link Status Proving Emergency message from its
peer, then M2PA SHALL initiate the Emergency proving period value
for T4, but it SHALL continue to send the Proving message
(Normal or Emergency) determined by its own upper layer MTP3
([Q.703] Figure 9 Sheet 6).

Note: If M2PA receives a Link Status Alignment message during the
PROVING state, then M2PA stops timer T4, starts timer T3, and
moves to the ALIGNED state ([Q.703] Figure 9 Sheet 5).

************************************************
NOTE: There seems to be a differences between M2PA
and Q.703  concerning reception of LSR or LSPO
during PROVING. Currently M2PA indicates these
events should be recorded. This memory is used to
move from PROVING straight to either IN_SERVICE or
PROCESSOR_OUTAGE without starting timer T1. Unless
I am mistaken, Q.703 has no such memory -- these
events are ignored during PROVING, and timer T1
is always started upon expiry of T4 (end of
proving). Changing this in M2PA will require that
the periodic sending of LSR or LSPO become SHOULD
rather than MAY. Leaving this unchanged should
require that the M2PA state machine figure change
to show transitions from PROVING to either
ALIGNED_READY or ALIGNED_NOT_READY or IN_SERVICE or
PROCESSOR_OUTAGE. I don't know how to make this
change to the figure -- no room left.

I'm keeping the memory of these events during
PROVING (status quo) in the following revision.
************************************************

----------
OLD TEXT 4.1.3

When the proving period timer T4 expires, M2PA changes to the Aligned
Ready state. M2PA SHALL start the timer T1 and send a Link Status
Ready message to its peer. These Link Status Ready message is used to
verify that both ends have completed proving. M2PA MAY send additional
Link Status Ready messages while timer T1 is running.

NEW TEXT 4.1.3

If M2PA receives either Link Status Ready or Link Status
Processor Outage during PROVING, then it records the event
for processing upon expiry of timer T4.

When timer T4 expires and a Link Status Ready message has
been received, then M2PA, depending on local processor
outage state, either sends a Link Status Processor Outage
message and moves to the PROCESSOR_OUTAGE state or sends
a Link Status Ready message and moves to the IN_SERVICE
state.

When timer T4 expires and a Link Status Processor Outage
message has been received, then M2PA notifies MTP3 of the
remote processor outage condition, and, depending on local
processor outage status, M2PA either sends a Link Status
Processor Outage message or sends a Link Status Ready
message, and then moves to the PROCESSOR_OUTAGE state.

When timer T4 expires and neither Link Status Ready nor
Link Status Processor Outage have been received, then M2PA
starts timer T1. If a Local Processor Outage Notification
had been received from MTP3, then M2PA sends a Link Status
Processor Outage message and moves to the ALIGNED_NOT_READY
state, otherwise it sends a Link Status Ready message and
moves to the ALIGNED_READY state ([Q.703] Figure 8 Sheet 5).

During the ALIGNED_READY state, M2PA MAY periodically send
Link Status Ready messages.

During the ALIGNED_NOT_READY and PROCESSOR_OUTAGE states,
M2PA MAY periodically send Link Status Processor Outage
messages.

----------
OLD TEXT 4.1.3

M2PA SHALL stop timer T1 when it receives a Link Status Ready or User
Data message from its peer. If timer T1 expires, then M2PA reports to
MTP3 that the link is out of service. M2PA sends Link Status Out of
Service to its peer. M2PA SHOULD leave the association
established. M2PA waits for MTP3 to initiate the alignment procedure
again.

Note that if M2PA has already received a Link Status Ready message
from its peer when its timer T4 expires, there is no need to start
timer T1. M2PA can just send Link Status Ready to the peer and
continue along.

NEW TEXT 4.1.3

M2PA SHALL stop timer T1 when it receives either a Link Status Ready
or User Data or Link Status Processor Outage message from its peer
([Q.703] Figure 8 Sheets 7 and 9). If either local or remote processor
outage is in effect, then M2PA moves to the PROCESSOR_OUTAGE state,
otherwise it moves to the IN_SERVICE state ([Q.703] Figure 8 Sheet 7).

If timer T1 expires, then M2PA reports to MTP3 that the link is
out of service. M2PA sends Link Status Out of Service to its peer,
and moves to the OUT_OF_SERVICE state. M2PA SHOULD leave the
association established.

----------
OLD TEXT 4.1.3

Note that if M2PA has already received a Link Status Ready message
from its peer when its timer T4 expires, there is no need to start
timer T1. M2PA can just send Link Status Ready to the peer and
continue along.

NEW TEXT 4.1.3
[deleted -- content moved to PROVING discussion]

----------
OLD TEXT 4.1.3

If there is a local processor outage condition during the alignment
procedure, M2PA sends Link Status Processor Outage to its peer. When
the local processor outage condition ends, then M2PA SHALL send Link
Status Processor Outage Ended to its peer. M2PA SHALL attempt to
complete the alignment procedure during the local processor outage
condition.

If M2PA receives a Link Status Processor Outage during alignment, and
M2PA had received a Start Request from its MTP3, M2PA SHALL report
Remote Processor Outage to MTP3. M2PA SHALL attempt to complete the
alignment procedure during the remote processor outage condition.

NEW TEXT 4.1.3

[deleted -- Behavior has been clarified above. LSPO should only
be received during PROVING or ALIGNED_READY or ALIGNED_NOT_READY states.
LSPO should only be sent during ALIGNED_NOT_READY or PROCESSOR_OUTAGE
states].

----------
OLD TEXT 4.1.3

When all of the following are true:

   (a) M2PA has received a Start Request from MTP3.

   (b) M2PA's proving period T4 has expired.

   (c) M2PA has sent a Link Status Ready to its peer.

   (d) M2PA has received a Link Status Ready OR User Data
       message from its peer.

   (e) M2PA has not received Link Status Out of Service from its peer
       since it received Link Status Alignment.

   then M2PA SHALL send Link In Service to its MTP3.

NEW TEXT 4.1.3

When all of the following are true:

   (a) M2PA has received a Start Request from MTP3.

   (b) M2PA has not received a Stop Request from MTP3
       since the Start Request.

   (c) The association has remained established.

   (d) M2PA has received EITHER (a Link Status Aligned and
       a Link Status Proving message)) OR (two Link
       Status Proving messages).

   (e) M2PA's proving period timer T4 has expired.

   (f) M2PA has received a Link Status Ready OR User Data
       OR Link Status Processor Outage Ended message from
       its peer.

   (g) M2PA has not received Link Status Out of Service from
       its peer since the ALIGNED state.

   then M2PA SHALL send Link In Service to its MTP3.

-----------------
OLD TEXT 4.1.4

When M2PA detects a local processor outage, it sends a Link Status
message to its peer with status Processor Outage. M2PA SHALL also
cease sending User Data messages to SCTP for transmission. M2PA SHALL
stop acknowledging received User Data messages.

M2PA MAY send additional Link Status Processor Outage messages as long
as there is a local processor outage and the link is in service. If
the link is out of service, M2PA SHOULD locally mark that it is in
local processor outage.

NEW TEXT 4.1.4

During PROCESSOR_OUTAGE or IN_SERVICE states, when MTP3 notifies
M2PA of local processor outage, M2PA sends a Link Status Processor
Outage message to its peer and moves to the PROCESSOR_OUTAGE state
([Q.703] Figure 8 Sheet 11). M2PA SHALL also cease sending User Data
messages to SCTP for transmission. M2PA SHALL stop acknowledging
received User Data messages.

M2PA MAY periodically send Link Status Processor Outage messages
during the PROCESSOR_OUTAGE state while local processor outage
is in effect.

-----------------
OLD TEXT 4.1.4

MTP3 may send a Flush Buffers or Continue command to M2PA as part of
its processor outage procedure (See section 4.2.4 Flush Buffers and
Continue). The use of Flush Buffers and Continue is specified in Q.703
[Q.703] and T1.111.3 [T1.111].

Alternatively, MTP3 may perform data retrieval as part of a changeover
procedure.

When the processor outage ceases, MTP3 sends a Local Processor
Recovered indication to M2PA. The local M2PA notifies its peer by
sending a Link Status message with status Processor Outage Ended. The
local M2PA SHALL resume receiving and transmitting messages.

NEW TEXT 4.1.4

MTP3 notifies M2PA of the onset of local processor outage condition
by sending a Local Processor Outage Request. Prior to the
PROCESSOR_OUTAGE state, M2PA records this event for future
processing. If this event is received during PROCESSOR_OUTAGE, then
M2PA sends a Link Status Processor Outage message to its peer and
records the event ([Q.703] Figure 8 Sheet 12). If this event is
received during IN_SERVICE, then M2PA sends a Link Status Processor
Outage message to its peer, records the local processor outage
state, and moves to the PROCESSOR_OUTAGE state ([Q.703] Figure 8
Sheet 11).

MTP3 notifies M2PA of the clearing of the local processor condition
by sending the Local Processor Outage Recovered Request. Prior to
the PROCESSOR_OUTAGE state, M2PA records this event by clearing its
record of the local processor outage condition. When this
indication is received during PROCESSOR_OUTAGE state, M2PA sends
a Link Status Processor Outage Ended message to its peer
([Q.703] Figure 8 Sheet 13).

M2PA timers T6 and T7 are stopped and remote busy status is
cleared upon transition to the PROCESSOR_OUTAGE state.

During PROCESSOR_OUTAGE if a Link Status Processor Outage Ended
message is received from the peer, M2PA notifies MTP3 that
remote processor has recovered ([Q.703] Figure 8 Sheet 12).

The use of Flush Buffers and Continue is specified in Q.703
[Q.703] and T1.111.3 [T1.111].

During PROCESSOR_OUTAGE if a Flush Buffers Request is received
from MTP3, then M2PA flushes the transmit message buffers and
records the event for future processing ([Q.703] Figure 8
Sheet 13).

During PROCESSOR_OUTAGE if a Continue Request is received
from MTP3, then M2PA records the event for future processing
([Q.703] Figure 8 Sheet 13).

If during PROCESSOR_OUTAGE M2PA determines that neither local
nor remote processor outage is in effect and either a Flush Buffers
Request or a Continue Request was received from MTP3, then it moves
to the IN_SERVICE state and begins receiving and transmitting
normally ([Q.703] Figure 8 Sheet 13).

>tomG.

[email-masked] wrote:
>
> Hello Franz,
>
> >an remark to your M2PA state event machine. In the case
> >'Proving' (T4 expired) is finished and local Processor
> >Outage is occurred, I missing an arrow from state
> >'PROVING' to state 'ALIGNED_NOT_READY'.
>
> You are correct, it's an error. Here is another try....
> (It would be a lot easier if M2PA simply referred to Q.703 SDLs.)
>
> Regards,
>
> Jeff
>
>                    +-----------+
>                    |   POWER   |
>                    |    OFF    |
>                    +-----------+
>                          |
>                          | Power On
>                          |
>        Flush Buffers     |  +-----------------------------------------+
>        OR Retrieval      |  |                                         |
>               +-------+  |  |                                         |
>               |       |  V  V                                         |
>               |    +-----------+                                      |
>               +--->|  OUT OF   |                                      |
>   +--------------->|  SERVICE  |<--+                                  |
>   |                +-----------+   | Link Configured                  |
>   |                      |   |     | (Associate)                      |
>   |                      |   +-----+                                  |
>   |     Receive LS OOS   |                                            |
>   |           +-------+  | MTP3 Start                                 |
>   |           |       |  V                                            |
>   |           |    +-----------+                                      |
>   |           +--->|    NOT    |                                      |
>   +<---------------|  ALIGNED  |------------------------------------->+
>   |     MTP3 Stop  +-----------+     SCTP Comm Error                  |
>   |  OR T2 Expiry        |        OR SCTP Comm Lost                   |
>   |                      |                                            |
>   |                      |    Receive LS Align                        |
>   |                      | OR Receive LS Prov Norm                    |
>   |     Receive LS Align | OR Receive LS Prov Emer                    |
>   |           +-------+  |                                            |
>   |           |       |  V                                            |
>   |           |    +-----------+                                      |
>   |           +--->|  ALIGNED  |                                      |
>   +<---------------|           |------------------------------------->+
>   |     MTP3 Stop  +-----------+     SCTP Comm Error                  |
>   |  OR T3 Expiry      ^    |     OR SCTP Comm Lost                   |
>   |  OR Receive LS OOS |    |                                         |
>   |                    |    |    Receive LS Prov Norm                 |
>   |                    |    | OR Receive LS Prov Emer                 |
>   |                    |    |                                         |
>   |   Receive LS Align |    |                                         |
>   |                    |    |                                         |
>   |                    |    |                                         |
>   | Receive LS Prov X  |    |                                         |
>   |           +------+ |    |                                         |
>   |           |      | |    V                                         |
>   |           |    +-----------+                                      |
>   |           +--->|  PROVING  |------------------------------------->+
>   |<---------------|           |------+          SCTP Comm Error      |
>   |     MTP3 Stop  +-----------+      |         OR SCTP Comm Lost     |
>   |  OR Receive LS OOS   |            |                               |
>   |                      |  T4 Expiry |                               |
>   |                      |   (LPO)    |                               |
>   |                      |            |                               |
>   |                      |            | MTP3 Stop            +------->+
>   |                      |            | OR Receive LS OOS    |        |
>   |                      |            | OR SCTP Comm Error   |        |
>   |                      |            | OR SCTP Comm Lost    |        |
>   |                      |            | OR T1 Expiry         |        |
>   |           T4 Expiry  |            | OR M2PA Link Failure |        |
>   |            (No LPO)  |            | OR Receive LS Align  |        |
>   |                      V            |                      |        |
>   |                +-----------+ LPO  V            +-----------+      |
>   |                |  ALIGNED  |------+----------->|  ALIGNED  |      |
>   +<---------------|   READY   |<------------------| NOT READY |      |
>   |     MTP3 Stop  +-----------+       LPR         +-----------+      |
>   |  OR T1 Expiry        |   |                         | Rcv LS Ready |
>   |  OR Receive LS OOS   |   |                         | OR Rcv Data  |
>   |  OR Receive LS Align |   +------------------------>+ OR Rcv LS PO |
>   |  OR SCTP Comm Error  |   Receive LS PO             |              |
>   |  OR SCTP Comm Lost   |                             |              |
>   |                      |    Receive LS Ready         |              |
>   |                      | OR Receive User Data        |              |
>   |                      V                             V              |
>   |                +-----------+ LPO or Rcv LS PO  +-----------+      |
>   |                |    IN     |------------------>| PROCESSOR |      |
>   +<---------------|  SERVICE  |<------------------|  OUTAGE   |      |
>                    +-----------+    MTP3 Flush     +-----------+      |
>        MTP3 Stop                 OR MTP3 Continue            |        |
>     OR Receive LS OOS                                        |        |
>     OR SCTP Comm Error                     MTP3 Stop         |        |
>     OR SCTP Comm Lost                   OR Receive LS OOS    |        |
>     OR T6 Expiry                        OR SCTP Comm Error   |        |
>     OR T7 Expiry                        OR SCTP Comm Lost    |        |
>     OR M2PA Link Failure                OR M2PA Link Failure |        |
>     OR Receive LS Align                 OR Receive LS Align  +------->+

--
* 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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Feb 2003 09:35:04 -0700

Jeffrey,

That would be fine, but ANSI T1.111.3 is different than Q.703, particularly
as regards processor outage handling and clear buffers/resume behavior.
Did you want to add SDL references for ANSI T1.111.3?  An what about JTTC
(which is rather different again)?

I agree that M2PA should not conflict with the SDLs, but referencing just
Q.703 seems inadequate.

--brian

[email-masked] wrote:                                             (Wed, 19 Feb 2003 11:18:39)

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

---

From: Tom George <[email-masked]>
Date: Wed, 19 Feb 2003 15:06:22 -0600

So where do we go with this? IMHO referencing 2 or even 3 documents in
each paragraph would be unwieldy. 

tomG.

> I agree that M2PA should not conflict with the SDLs, but referencing just
  [...]