Subject: RE: [Sigtran] M2PA - Retrieval State

From: "May, Howard" <[email-masked]>
Date: Mon, 2 Sep 2002 13:46:33 +0100

Brian, Ming,

I concur with your points, I do not believe that the Retrieval State adds
anything and now would support it's removal.  

With regards aligning more closely with Figure 2/Q.703.  Assuming you are
correct when you say 'MTP3 is concerned about: PROCESSOR OUTAGE and ALIGNED
NOT READY' then shouldn't their addition be mandatory?

Howard

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 02 September 2002 11:04
> To: May, Howard
> Cc: 'Ming Lin'; [email-masked]
> Subject: Re: [Sigtran] M2PA - Retrieval State
> 
> 
> Howard,
> 
> I agree with Ming.  There is no difference between RETRIEVAL state and
> OOS state.  Q.703 gets (and even MTP3b) along quite nicely without an
> LSC RETRIEVAL state: both only use an Out of Service state.  
> For consistency
> with MTP2/MTP3b the RETRIEVAL state needs to be removed.
> 
> M2PA/Figure 7 should be made to be consistent with Figure 
> 2/Q.703. Figure
> 2/Q.703 has no RETRIEVAL state.  The only states listed in 
> Q.703 overview
> are:
> 
>         Figure 2/Q.703               M2PA/Figure 7
>         ------------------           ------------------
>         Power Off                    IDLE
>         Out of Service               OOS
>         Initial Alignment            AIP, PROVING
>         Aligned Ready                ALIGNED READY
>         In Service                   INS
>         Processor Outage             --
>         Aligned Not Ready            --
>         --                           RETRIEVAL
> 
> It would be good if M2PA could at least conform to the Q.703 
> state machine
> overview diagram (even if it falls short of the detailed 
> SDLs).  Several
> things should be done to M2PA/Figure 7 to accomplish this:  
> RETRIEVAL state
> should be removed (MTP3 does not distinguish it from OOS 
> state).  PROVING
> state should be removed--well collapsed with AIP--(MTP3 does 
> not distinguish
> Proving from Initial Alignment), and two states need to be 
> added to the
> diagram which MTP3 is concerned about: PROCESSOR OUTAGE and 
> ALIGNED NOT READY.
> PROCESSOR OUTAGE state results from local processor outage condition
> experienced in the INS state.  ALIGNED NOT READY state 
> results from local
> processor outage condition experienced in the ALIGNED READY 
> state.  Thus, the
> diagram should be updated as follows:
> 
>                                                               
>           
>                     +-----------+                             
>           
>                     |  POWER    |                             
>           
>                     |   OFF     |                             
>           
>                     +-----------+                             
>           
>                           |                                   
>           
>                           | Power On                          
>           
>                           |                                   
>           
>         Flush Buffers     |  +-------------------------+      
>           
>         OR Retreival      |  |                         |      
>           
>                +-------+  |  |                         |      
>           
>                |       |  V  V                         |      
>           
>                |    +-----------+                      |      
>           
>                +--->|  OUT OF   |                      |      
>           
>   +---------------->|  SERVICE  |<--+                  |      
>           
>   |                 +-----------+   | Link Configured  |      
>           
>   |                       |   |     | (Associate)      |      
>           
>   |                       |   +-----+                  |      
>           
>   |                       |                            |      
>           
>   |                       | MTP3 Start                 |      
>           
>   |                       V                            |      
>           
>   |                 +-----------+                      |      
>           
>   |                 |  INITIAL  |                      |      
>           
>   +<----------------| ALIGNMENT |--------------------->+      
>           
>   |      MTP3 Stop  +-----------+     SCTP Comm Error  |      
>           
>   |   OR T1 Expiry        |  |     OR SCTP Comm Lost   |      
>           
>   |   OR T4 Expiry        |  |                         |      
>           
>   |   OR Receive LS OOS   |  
> +-------------------------|---------+      
>   |                       | Send and                   |      
>    |      
>   |                       |      Receive LS Alignment  |      
>    |      
>   |                       V                            |      
>    |      
>   |                 +-----------+        LPO/LPR       |   
> +-----------+
>   |                 |  ALIGNED  |<---------------------|-->|  
> ALIGNED  |
>   +<----------------|   READY   |--------------------->+   | 
> NOT READY |
>   |      MTP3 Stop  +-----------+     SCTP Comm Error      
> +-----------+
>   |   OR T3 Expiry        |        OR SCTP Comm Lost          
>    |      
>   |   OR Receive LS OOS   |                                   
>    |      
>   |                       | Receive LS Ready                  
>    |      
>   |                       | OR Receive User Data              
>    |      
>   |                       |                                   
>    |      
>   |                       V                                   
>    V      
>   |                 +-----------+        LPO/LPR           
> +-----------+
>   |                 |    IN     |<------------------------>| 
> PROCESSOR |
>   |                 |  SERVICE  |                          |  
>  OUTAGE  |
>   |                 +-----------+                          
> +-----------+
>   |                       |                                   
>    |      
>   |                       |    MTP3 Stop                      
>    |      
>   |                       | OR Receive LS OOS                 
>    |      
>   |                       | OR SCTP Comm Error                
>    |      
>   |                       | OR SCTP Comm Lost                 
>    |      
>   |                       | OR T6 Expiry                      
>    |      
>   |                       | OR T7 Expiry                      
>    |      
>   |                       | OR M2PA Link Failure              
>    |      
>   |                       |                                   
>    |      
>   
> +<----------------------+<-------------------------------------+      
>                                                               
>           
>                                                               
>           
>              Figure 7: M2PA Link State Transition Diagram     
>           
>                                                               
>           
> 
> Text should be updated to be consistent with this diagram.
> 
> --brian
> 
> May, Howard wrote:                                            
>                         (Mon, 02 Sep 2002 09:46:20)
> > Dear Ming
> > 
> > I think Issue 18, included in your email below, is resolved by Toms
> > correction (well done with the ascii art work Tom!).  Ming 
> could you post a
> > summary of the other problems you see with the Retrieval state.
> > 
> > I currently believe the Retrieval state to be worthwhile.  
> As the link can
> > only leave the Retrieval state after an event from MTP3 it 
> guarantees that
> > MTP3 will be able to perform and complete retrieval 
> procedures before the
> > link comes back into service.   If the Retrieval state is 
> not used then I
> > think we would be left in a situation where the link could 
> come back into
> > service before Retrieval had been completed.  There is then 
> an issue of
> > either allowing MTP3 and M2PA to fight over messages in the 
> TX buffer (MTP3
> > trying to Retrieve them and M2PA trying to transmit them - clearly
> > undesirable) or perhaps when the link fails moving messages 
> left in the Tx
> > buffer to another buffer until MTP3 decides whether it 
> wants them or not (My
> > gut feeling is that this is where more problems lie rather 
> than the use of
> > the Retrieval state)
> > 
> > Cheers
> > 
> > > -----Original Message-----
> > > From: Ming Lin [mailto:[email-masked]]
> > > Sent: 01 September 2002 05:08
> > > To: Tom George
> > > Cc: [email-masked]
> > > Subject: Re: [Sigtran] I-D ACTION:draft-ietf-sigtran-m2pa-06.txt
> > > 
> > > 
> > > Dear Tom,
> > > 
> > > I think we should remove RETRIEVAL state, this state will 
> > > result in many problem but no use,
> > > for example the No. 18 issue.
> > > 
> > > "18. 08/09/02 Howard May "[Sigtran] M2PA - Minor corrections?" 
> > >      In Figure 7, RETRIEVAL receives MTP Start. Go to 
> AIP, not OOS.
> > >  A: Yes.  [Done.]"
> > > 
> > > ----- Original Message ----- 
> > > From: "Tom George" <[email-masked]>
> > > Cc: <[email-masked]>
> > > Sent: Friday, August 30, 2002 11:30 PM
> > > Subject: Re: [Sigtran] I-D ACTION:draft-ietf-sigtran-m2pa-06.txt
> > > 
> > > 
> > > > M2PA Changes for version 6
> > > > 08/28/2002
> > > > 
> > > > Here are the changes in draft-ietf-sigtran-m2pa-06.txt (M2PAv6).
> > > > 
> > > > If anyone wants to study the changes in detail, I have a 
> > > "diff" file I
> > > > can send.
> > > > 
> > > > This is not a complete list of changes. I did not include minor
> > > > rewording.
> > > > 
> > > > 
> > > > This is the list of comments received on M2PAv5 on the 
> SIGTRAN list.
> > > > 
> > > > 
> ==================================================================
> > > > 
> > > > Here is my list of comments. For the most part, they 
> are arranged by
> > > > the thread from the SIGTRAN list.
> > > > 
> > > > Everyone please make comments. I think the discussion 
> would go more
> > > > smoothly if you only talked about one item per e-mail.
> > > > 
> > > > 
> > > > 1. Section 2.2. FSN/BSN should be 24 bits, not 23.
> > > > 
> > > > A: This was a typo. It will be 24 in M2PAv6.  [Done.]
> > > > 
> > > > 2. 05/06/02 Jeff Craig "[Sigtran] (M2PA) What actions 
> > > should be taken
> > > >    if LSA or User Data Received in PROVING?" There is 
> no guidance
> > > >    about anomalous events during alignment/proving.
> > > > 
> > > > A: I agree that some text should be added. I have not 
> worked out the
> > > > details and would welcome suggestions.
> > > > 
> > > >    My ideas:
> > > > 
> > > >    User Data received during PROVING should be discarded.
> > > > 
> > > >    Link Status Alignment received during PROVING should 
> be ignored.
> > > > 
> > > >    [Done.]
> > > > 
> > > > 3. 05/10/02 Jeff Craig, "[Sigtran] (M2PA) Please 
> standardize M2PA
> > > >    protocol timer identifiers" and Jeff Craig 06/21/02 
> > > "m2pa comment:
> > > >    timers". Line up timer names in Q.703 and M2PA. Add 
> the T7 timer.
> > > > 
> > > > A: This is what I got out of the discussion:
> > > > 
> > > >    Keep same names for T1, T3, T6. [Done.]
> > > > 
> > > >    Rename M2PA T2 to T4. [Done.]
> > > > 
> > > >    Don't use "timer" names for the rate parameters.  [Done.]
> > > > 
> > > >    T7 - see #11 below.  [Done.]
> > > > 
> > > > 4. 05/17/02 Jeff Craig, "[Sigtran] (M2PA) Please add a Network
> > > >    Appearance parameter to the M2PA protocol". A suggestion 
> > > that a NA
> > > >    parameter be added to M2PA.
> > > > 
> > > > A: I prefer not to add this.  [Done.]
> > > > 
> > > > 5. 05/22/02 anssharma, "[Sigtran] M2PA Clarification". In 
> > > level 2 flow
> > > >    control, M2PA stops transmitting. What does it do with the
> > > >    messages?
> > > > 
> > > > A: I think is an implementation matter.  [Done.]
> > > > 
> > > > 6. 05/24/02 Lisa Gorgone, "[Sigtran] M2PA:Questions on sequence
> > > >    number". Some questions about bad values of FSNR and BSNR.
> > > > 
> > > > A: M2PAv5 (4.2.1) says to fail the link if one FSNR is out 
> > > of order. I
> > > > think that is OK. There is nothing about bad BSNR 
> values. I would be
> > > > inclined to fail the link in this case as well, since one end is
> > > > acking messages that the other does not have in its 
> transmit buffer.
> > > > 
> > > >    I have a question about the BSNR values on the list. 
> 2 out of 3
> > > >    consecutive messages with bad BSNRs?
> > > > 
> > > >    Eliminate acks on the Status stream. All acks go 
> over the Data
> > > >    stream. If there is no User Data message to be sent, 
> > > send one with
> > > >    no data in it. Get rid of Link Status In Service, 
> since its only
> > > >    purpose was to carry an ack. [Done.]
> > > > 
> > > > 7. 05/24/02 Brian Bidulock "[Sigtran] Re: M2PA 
> Clarification". Does
> > > >    M2PA need to withhold messages from SCTP during busy?
> > > > 
> > > > A: This is how Q.703 works, so we should copy it. 
> Before there were
> > > > M2PA sequence numbers, messages were withheld while the 
> > > peer was Busy
> > > > to prevent message loss in case the link later failed. 
> Now that M2PA
> > > > has its own sequence numbers, this is no longer a danger. 
> > > So M2PA can
> > > > continue transmitting while its peer is Busy. 
> > > > 
> > > >    I updated secion 4.1.5 Level 2 Flow Control.  [Done.]
> > > > 
> > > > 8. 06/18/02 amish.chana "[Sigtran] M2PA Comment: 
> > > Multi-homing". Should
> > > >    M2PA support multi-homing?
> > > > 
> > > > A: It is allowed. The only change needed is in 4.1.2 so 
> that it says
> > > > "the IP address (or IP addresses if multi-homing is 
> used)".  [Done.]
> > > > 
> > > > 9. 06/19/02 Lisa Gorgone "Re: [Sigtran] M2PA Comment:Retrieval
> > > >    State". Does M2PA need a RETRIEVAL state? Does 
> RETRIEVAL state
> > > >    cause harm?
> > > > 
> > > > A: I would like to have more discussion about this. 
> > > > 
> > > >    Since there has not been more discussion, I will 
> leave this as is
> > > >    for M2PA version 6.  [Done.]
> > > > 
> > > > 10. 06/21/02 Javier Pastor-Balbas "[Sigtran] M2PA Comment:
> > > >     Multi-homing". Also 06/21/02 "[Sigtran] Multiplexed 
> > > M2PA links on
> > > >     an association".  Should M2PA allow multiple links per
> > > >     association?
> > > > 
> > > > A: The disadvantage of this is that if the association 
> > > dies, you lose
> > > > all the links on the association. This is one of the 
> main reasons I
> > > > did not allow for multiple links in an association. 
> > > > 
> > > >    No change to the draft is needed.  [Done.]
> > > > 
> > > > 11. 06/21/02 Andrew Booth "[Sigtran] M2PA Comment: T7 Timer" and
> > > >     several of the earlier threads. Should there be an 
> equivalent of
> > > >     MTP2 T7?
> > > > 
> > > > A: OK, you finally convinced me. 8-) I added the T7 
> timer in 4.2.1
> > > > Sending/receiving messages and 4.1.5 Level 2 Flow 
> Control.  [Done.]
> > > > 
> > > > 12. 06/25/02 Lyndon Ong "RE: [Sigtran] M2PA Queries - 
> > > summary". Just a
> > > >     summary of the discussion.
> > > > 
> > > > A: No answer needed. [Done.]
> > > > 
> > > > 13. 06/26/02 Karen King "[Sigtran] A couple of comments on M2PA
> > > >     processor outage". Recommend adding text to 4.1.4 
> > > Processor Outage
> > > >     about flushing buffers as in Q.703.
> > > > 
> > > > A: Even though this is in Q.703, the action is taken by 
> > > MTP3. Section
> > > > 4.1.4 (next to last paragraph) does allow for the 
> flush. Flush is
> > > > described in 4.2.4. So I think this is taken care of 
> (although there
> > > > may be problems in 4.2.4 - that's another thread).  [Done.]
> > > > 
> > > > 14. 06/28/02 Ray Singh "[Sigtran] Comment on M2PA - Performance
> > > >     Monitoring". Add back the monitoring of SCTP 
> > > association that was
> > > >     in draft version 3.
> > > > 
> > > > A: The reason I took this out is that I never had any 
> solid ideas
> > > > about what SCTP parameters should be monitored and what the 
> > > acceptable
> > > > values would be. If we could come up with something 
> > > helpful, I am not
> > > > opposed to adding the monitoring back in. But I don't see 
> > > the point of
> > > > adding it if the criteria will be some implementation-dependent
> > > > parameters having implementation-dependent values. 8-( [Done.]
> > > > 
> > > > 15. 07/12/02 anssharma "[Sigtran] M2PA - Flush 
> Buffers". Questions
> > > >     about Flush.
> > > > 
> > > > A: These are good questions but I have not had time to 
> think about
> > > > them.
> > > > 
> > > > 
> > > > 16. 07/19/02 Ray Singh "[Sigtran] Comment on M2PA - Slow 
> > > Start". What
> > > >     kind of warning is needed about slow start?
> > > > 
> > > > A: I proposed a general warning about slow start to 
> replace specific
> > > > warnings throughout the document.
> > > > 
> > > > alignment, changeover, path failure (multihoming), reduced 
> > > volume. See
> > > > Tolga, 07/26/02. [Done.]
> > > > 
> > > > 
> > > > 17. 07/22/02 Tolga Asveren "[Sigtran] M2PA : LS 
> messages on stream
> > > >     0". Are there problems with sending Status and Data 
> on different
> > > >     streams? What mimics MTP2 best?
> > > > 
> > > > A: The problem with putting LS and Data on the same 
> stream is that a
> > > > LS message can get stuck behind a Data retransmission. This is
> > > > contrary to the message priority of MTP2. (Brian 
> Bidulock 08/13/2002
> > > > 21:00 pointed out that this is a problem that MTP2 does 
> not have.)
> > > > 
> > > > The problem with using SCTP unordered transmission for LS 
> > > messages is
> > > > that they can get out of order with each other. For 
> > > example, a LS Proc
> > > > Outage could get out of order with a LS Proc Outage Ended. 
> > > > 
> > > > MTP does not require that LSSUs and MTUs be associated with 
> > > each other
> > > > in any particular way. It has MTP2 put LSSUs ahead of 
> MTUs in the
> > > > transmit buffer. So it should not be required that M2PA 
> > > transmit LS in
> > > > order with Data.
> > > > 
> > > > Having M2PA put LS at the front of the M2PA transmit queue 
> > > helps some,
> > > > but it does not do anything about the messages that are 
> in the SCTP
> > > > send queue. To truly imitate MTP2 at this point, we 
> would need a way
> > > > to give a message to SCTP and tell it to put the message at 
> > > the front
> > > > of its send queue.
> > > > 
> > > > (Or, we could restrict SCTP to just 1 message in its send 
> > > buffer. This
> > > > would allow M2PA to prioritize like MTP2. But this would 
> > > create severe
> > > > problems of its own. No one seemed to like this option.)
> > > > 
> > > > Sending LS and Data on different streams allows for a partial
> > > > imitation of the MTP2 transmission priority. If the 
> receiving M2PA
> > > > gives priority to reading incoming LS messages (on stream 
> > > 0) over Data
> > > > messages (on stream 1), then LS messages can be 
> received sooner than
> > > > if they waited behind the Data messages. Also, it is 
> possible for
> > > > SCTP, by some implementation-dependent method or some 
> future SCTP
> > > > extension, to give a higher priority to sending messages on 
> > > stream 0.
> > > > 
> > > > My conclusion is to leave the draft alone. Having separate 
> > > Status and
> > > > Data streams does not exactly imitate MTP2, but it is 
> as close as we
> > > > can get using SCTP.  [Done.]
> > > > 
> > > > Some related matters:
> > > > 
> > > > I will add to 4.1.7 so that it says that M2PA transmits 
> LS messages
> > > > before Data messages. This is in addition to the attempt to 
> > > prioritize
> > > > SCTP stream 0. [That was already there. Done.]
> > > > 
> > > > The FSN should be ignored in the LS messages. FSN should be
> > > > incremented only for Data messages. [That was already 
> there. Done.]
> > > > 
> > > > I will add a warning that one has to watch out for a 
> > > wraparound of the
> > > > FSN/BSN numbers. This is unlikely with 24 bits, but should 
> > > probably be
> > > > mentioned. [Done.]
> > > > 
> > > > 
> > > > 18. 08/09/02 Howard May "[Sigtran] M2PA - Minor corrections?" 
> > > > 
> > > >     In Figure 7, RETRIEVAL receives MTP Start. Go to 
> AIP, not OOS.
> > > > 
> > > > A: Yes.  [Done.]
> > > > 
> > > > 
> > > > 
> ==================================================================
> > > > 
> > > > More detailed list of changes:
> > > > 
> > > > 2.2  M2PA Header: Changed BSN and FSN to 24 bits in diagram.
> > > > 
> > > > 2.3.2 Link Status: Removed In Service (10) from list of values.
> > > > 
> > > > 2.3.2.1 Link Status Proving, 1st para: Removed 
> statement about SCTP
> > > > slow start.
> > > > 
> > > > 3.  M2PA Link State Control, Figure 7: M2PA Link State 
> Transition
> > > > Diagram:
> > > > 
> > > >     T2 is renamed T4.
> > > > 
> > > >     Added T7 expiry.
> > > > 
> > > >     In RETRIEVAL, MTP3 Start goes to AIP instead of OOS.
> > > > 
> > > > 4.1.2 MTP and SCTP Entities, 2nd para: Added "(or IP 
> addresses, if
> > > > multi-homing is used)".
> > > > 
> > > > 4.1.3 Link Alignment, 1st para: Removed list item 3 
> about SCTP slow
> > > > start.
> > > > 
> > > > 4.1.3 Link Alignment, several places: Renamed T2 to T4.
> > > > 
> > > > 4.1.3 Link Alignment, para "Anomalous...": Added this paragraph.
> > > > 
> > > > 4.1.5 Level 2 Flow Control, para "The peer M2PA 
> should...": Changed
> > > > "shall cease transmitting messages" to "should continue 
> transmitting
> > > > messages".
> > > > 
> > > > 4.1.5 Level 2 Flow Control, para "The peer M2PA shall 
> not...": Added
> > > > this paragraph about T7.
> > > > 
> > > > 4.2.1 Sending and receiving messages, para "When M2PA 
> > > receives a User
> > > > Data message...": Specified that this is a _User Data_ message.
> > > > 
> > > > 4.2.1 Sending and receiving messages: Removed paragraph 
> stating that
> > > > ack may be sent in User Data or Link Status.
> > > > 
> > > > 4.2.1 Sending and receiving messages, para "M2PA should 
> follow the
> > > > criterion...": Added this paragraph about 2-out-of-3 criterion.
> > > > 
> > > > 4.2.1 Sending and receiving messages, para "M2PA should 
> ignore...":
> > > > Added this paragraph.
> > > > 
> > > > 4.2.1 Sending and receiving messages, para "Note: In all
> > > > calculations...": Added this paragraph.
> > > > 
> > > > 4.2.1 Sending and receiving messages, para "If there is no 
> > > other User
> > > > Data...": Changed this to say M2PA sends User Data with 
> no payload
> > > > instead of LS In Service.
> > > > 
> > > > 4.2.1 Sending and receiving messages, last 2 
> paragraphs: Added these
> > > > paragraphs about T7.
> > > > 
> > > > 4.3 SCTP Considerations: Added this section to discuss 
> slow start.
> > > > 
> > > > 5.1  Link Initialization, several places: Renamed T2 to T4.
> > > > 
> > > > 7.1 SCTP Payload Protocol Identifier: Registered User 
> Port Number is
> > > > 3565. Removed UDP.
> > > > 
> > > > 9.  References: Updated some of the references.
> > > > 
> > > > 10.  Author's Addresses: New address for Brian Bidulock.
> > > > 
> > > > (end)
> > > > 
> > > > 
> > > > -- 
> > > > * Tom George          972-519-3168           
> > > [email-masked]   *
> > > > * PB2-1323       Intranet:  
> > > http://www.ssd.usa.alcatel.com/~tgeorge/  *
> > > > * Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 
> > > 75075-5813   *
> > > > * 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
> > > 
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 2 Sep 2002 14:24:54 -0600

Howard,

Another approach would be to ignore processor outage states altogther
ala Q.2210; however, M2PA already closely parallels the processor outage
procedures of Q.703: the states are just missing from the state diagram.

--brian

May, Howard wrote:                                (Mon, 02 Sep 2002 13:46:33)