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

From: Andrew Booth <[email-masked]>
Date: Wed, 12 Mar 2003 14:48:07 -0500

Hi Jeff,

I like a lot of your proposed changes. They specify more precisely when 
to send LS PO, when it should be expected, and how to exit from the 
processor outage state. I do have some concerns with the amount of 
change to the state machine but I can't find any major issues.

A few specific comments are included below.

[email-masked] wrote:

>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).
>
As I understand it this change eliminates the need to mark received LS 
Align messages before a Start request has been received from MTP3, hence 
simplifying the description of the state machine. Am I understanding the 
idea correctly? Or is it also to align the state changes more closely 
with MTP2?

>
>
>----------------
>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).
>  
>
All this is fine, but the LS Alignment messages now seems a little 
pointless. According to the proposed state machine, an implementation 
can go In Service without ever receiving LS Alignment. Why not just send 
LS Proving instead of LS Alignment? Or am I missing something?

>
>----------
>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.
>
One way to fit more state transitions on the diagram would be to replace 
complicated blocks of events with indicators like (Note 1). This also 
means that transitions that are very complicated, such as from the 
Processor outage state to the In Service state, can be cross referenced. 
It does make the diagram slightly less readable. It might look something 
like this:

NOTE: I am not proposing this state diagram, just suggesting another way 
to representing state transitions.

[first half of the diagram omitted]

| | +-----------+ |
| +-->| PROVING |------------------------------------->+
|<--------------| |-------------+ SCTP Comm Error |
| (Note 1) +-----------+ | OR SCTP Comm Lost|
| | | \ | |
| | | ---------------+ | T4 Expiry |
| | | (Note 2)| | (LPO) |
| T4 Expiry | \ | | |
| (No LPO) | ---------+ | | +------->+
| | (Note3) | | | | |
| | | | | (Note 4) | |
| | | | | | |
| | | | | | |
| Rcv LS Prov X | | | | | |
| +------+ | | | | | |
| | | V | | | | |
| | +-----------+ LPO | | V +-----------+ |
| +-->| ALIGNED |-------|-------|-+---->| ALIGNED | |
+<----------| READY |<------|-------|-------| NOT READY | |
| (Note 5) +-----------+ LPR | | +-----------+ |
| | | | +-----+ | (Note 6) |
| | | +----+ | | |
| | | | V | |
| | +-------|------------------+---->+ |
| \ | Recv LS PO | |
| \ | | |
| (Note 7)\ | | \
| | | | |
| V V V |
| +-----------+ LPO or Rcv LS PO +-----------+ |
| | IN |------------------>| PROCESSOR | |
+<---------------| SERVICE |<------------------| OUTAGE | |
+-----------+ (Note 8) +-----------+ |
MTP3 Stop | |
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 +------->+

Note 1:
MTP3 Stop OR
Received LS OOS OR
SCTP Comm Error OR
...

Note 2:
...
...
Note 8:
The transition from Processor outage to In Service is based on several 
factors. See section ... for more details.

>
>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.
>
Pathological case: If you receive both LS PO and LS PR within T4 then 
the text could be innacurate.

>
>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.
>
Does this mean that if we transition to Processor Outage directly from 
Aligned Ready (or from Proving) that we don't send and In Service 
indication? If we send both RPO and In Service indications should they 
be sent in that order?

Corner case: should we include "(h) M2PA has not send a Link In Service 
indication to MTP3 since receiving a Start Request."?

>
>
>
>-----------------
>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).
>
Should we also flush the receive buffers and the RTB?

Andrew

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

-- 
Andrew Booth, Software Developer
Signaling Systems Group, Performance Technologies
613-237-4344

Visit www.pt.com/mailing.html to subscribe to our Packets & Signals eLetter.

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

---

From: [email-masked]
Date: Thu, 13 Mar 2003 08:16:20 -0500

Hello Andrew,

My responses are embedded below.

Regards,

Jeff

>idea correctly? Or is it also to align the state changes more closely

(jeff)
yes. yes. There is a list thread that describes the reasoning.

>[first half of the diagram omitted]

(jeff)
I have no comments on this, though I appreciate clarity whenever
I encounter it.

>the text could be innacurate.

(Jeff)
Received LSPO overrides received LSR. LSR received after LSPO and
prior to LSPOE is a protocol error. A peer experiencing LPO should never
send LSR prior to sending LSPOE or LSO.

>indication?

(jeff)
Entry to processor outage state means that alignment/proving is
complete, and so MTP3 should be notified. The form the notification
takes depends on the circumstances (LPO, RPO). Please refer to
the Q.703 SDLs for examples. The net of it is that if RPO is in effect,
then MTP3 is informed of RPO in lieu of in-service.

>If we send both RPO and In Service indications should they
>be sent in that order?

(jeff)
I am not sure what you mean by this. When alignment/proving
completes MTP3 is informed of either RPO or In Service, not both.
If MTP3 had been informed of RPO, and then subsequently that
status clears, it is notified with a RPO Recovered Indication.

>indication to MTP3 since receiving a Start Request."?

(jeff)
No, for reasons mentioned above.