Subject: [Sigtran] M2PA: List of comments on M2PAv7

From: Tom George <[email-masked]>
Date: Fri, 07 Mar 2003 21:06:43 -0600

Here is my list of M2PAv7 comments with the resolutions I have so far. 

The ones that are not resolved:

   08. How to define BSNT.
   10. Some comments from Jeff Craig about Figure 7.

List of comments on M2PA draft version 7. 
Tom George
03/07/2003

Here is my list of comments on M2PA draft version 7 and how they were
incorporated into version 8. For the most part, they are arranged by
the thread from the SIGTRAN list. The date/name/subject identify the
beginning of the thread.

The items that are still open are marked with "??".

01. 01/22/03 Tom George "M2PA version 7 detailed list of changes".

    7.1 SCTP Payload Protocol Identifier

    Paragraph "The SCTP...": UDP should not have been added. M2PA has
    a registered port for SCTP and TCP, not UDP.

    A: Removed UDP.

02. 01/22/03 Tolga Asveren "Re: [Sigtran] M2PA version 7 changes".

    Flush buffers.

    01/29/03 Tom George "[Sigtran] M2PA Flush Buffers (was: M2PA
    version 7 changes)".

    02/03/03 Tom George "[Sigtran] M2PA Flush Buffers".

    A: I rewrote and rearranged section 4.1.4 as suggested by this
    discussion. The M2PA in LPO stops transmitting User Data
    messages. It buffers but does not ack incoming User Data
    messages. It acks User Data messages received before the LPO. It
    stops T6.

    Likewise, the peer stops transmitting User Data messages. It
    buffers but does not ack incoming User Data messages. It acks User
    Data messages received before the LPO. It stops T6 and T7.

    I added an explanation about Continue to section 4.2.4. 

03. 01/22/03 Franz Gaiser "Re: [Sigtran] M2PA version 7 changes".

    Several comments.

    1. Figure 7. M2PA Link State Transition Diagram: Why is there an
       arrow from state INITIAL ALIGNMENT to state ALIGNED NOT READY ?

       01/29/03 Tom George "[Sigtran] M2PA LPO during
       alignment/proving".

       01/31/03 Franz Gaiser "AW: [Sigtran] M2PA LPO during
       alignment/proving (was: M2PA versio n 7 changes)"

       A: Arrow from INITIAL ALIGNMENT to ALIGNED NOT READY was
       removed. The diagram now shows more clearly that LPO during
       alignment/proving does not stop the alignment/proving process.

    2. Figure 7. Missing the handling of receiving LS PO in state
       ALIGNED READY.

       A: It goes to ALIGNED NOT READY. I added that to Figure 7. 

    3. Figure 7. Missing the handling of receiving User data in state
       ALIGNED NOT READY.

       A: This does not cause a state change. The PO procedure later
       in the document tells what to do. I would rather not try to
       crowd this into Figure 7.

    4. 4.2.1 Paragraph "If M2PA receives a User Data message with an
       FSN that is out of order, M2PA SHALL take the link out of
       service." Does "take the link out of service" mean also that
       the peer side is informed via sending LS OOS message?

       01/29/03 Tom George "[Sigtran] M2PA Link OOS". 

       A: Yes. I made an "OOS" section in the document - 4.1.6.

    5. Figure 13. Example: Link Initialization - Proving. New Timer T3
       "ALIGNED" is missing in the figure.

       01/29/03 Tom George "[Sigtran] M2PA T3 and T4". 

       Yes. Also there is a problem in 4.1.4. T3 and T4 should be
       started together. Not T4 after T3. 

       A: Figures 12 and 13 updated. The T3 and T4 timers are in
       Figure 13. 

       In 4.1.4, T3 and T4 are now started together.

04. 01/24/03 Karen King "[Sigtran] M2PA Draft 7 comment". 

    Processor outage.

    A: Moved paragraphs in 4.1.4 Processor Outage to clarify. 

05. 01/26/03 Lyndon Ong "[Sigtran] m2pa comment: author list". 

    1. Trim the author list.

       A: Removed from author list and placed in Acknowledgements:

          Malleswar Kalla, Greg Sidebottom.

    2. References need to be sorted into Normative and Non-normative,
       in separate sections.

       A: Done.

          Added reference to RFC 3309 SCTP Checksum Change.

    3. Update security section based on the security framework
       document (which should come out this week).

       02/11/03 Tom George "[Sigtran] M2PA Security section".

       A: I updated the text.

06. 01/29/03 John Li "[Sigtran] M2PA Draft 7 comment". 

    02/11/03 John Li "[Sigtran] M2PA draft comments and questions."

    Several comments.

    1. Section 1.5. "In effect, the Signaling Gateway acts as a Signal
       Transfer Point (STP)". This was confusing.

       A: I reworded this paragraph slightly. 
          
	  Figure 2 shows an example of M2PA used in a Signaling
	  Gateway (SG). The SG is an IPSP equipped with both
	  traditional SS7 and IP network connections.  Any of the
	  nodes in the diagram could have SCCP or other SS7
	  layers. The Signaling Gateway acts as a Signal Transfer
	  Point (STP).  Other STPs MAY or MAY NOT be present in the
	  SS7 path between the SEP and the SG.

    2. Section 2.1.5 Message length. Should we specify the valid value
       range of the length?

       A: No. This is determined by MTP3. 

          No change to the draft is necessary.

    3. Section 2.3.1 User Data. "M2PA does not add padding to the MTP3
       message." Needs to be stronger. 

       A: I changed this to "M2PA SHALL NOT add padding to the MTP3
       message." It has to be a firm requirement.

    4. Section 4.1.3 Link alignment. Can we specify the recommended
       practice for choosing emergency proving vs. normal proving?

       A: No. This is determined by MTP3. 

          No change to the draft is necessary.

    5. Section 4.1.8. Clarify "If a Link Status Alignment message with
       an unsupported received by the newer version, the receiving
       end's M2PA SHALL NOT complete the alignment procedure."

       A: I changed this sentence to: "If a Link Status Alignment
       message with an unsupported version is received by the newer
       version, the receiving end's M2PA SHOULD reply with a Link
       Status Out of Service message and not complete the alignment
       procedure."

    6. Section 4.2.1 sending and receiving messages. "When M2PA
       receives a User Data message with Backward Sequence Number
       equal to 'n', it may remove all messages with Forward Sequence
       Number <= n from its queue." This does not account for
       wrap-around.

       A: There is a general warning about this in this section
       (4.2.1).

    7. Section 4.2.1. What is empty User Data message?

       A: It's an Ack (sections 2.3.1, 4.2.1). 

          No change to the draft is necessary.

07. 02/05/03 Andrew Booth "[Sigtran] M2PA 7 questions". 

    Several comments.

    1. Section 3: SCTP Restart is not mentioned. Is that OK?

       A: SCTP Restart does not affect M2PA. 

    2. Section 4.2.1: Is T7 a timer or an interval? Section 4.1.5:
       What should be done with T7 after Busy clears?

       A: T7 is a per-message timer.

       Brian Bidulock (02/05/03): T7 continues to run while busy (but
       not while processor outage).  This is the same as Q.703.  T7
       expiry just does not fail the link while busy, T6 expiry does.

    3. T6 (Busy timer) is stopped in LPO. There is no requirement to
       (re)start T6 when LPO ends. Therefore it appears that LPO ends
       Busy. Is this right?

       A: Brian Bidulock (02/05/03): Busy is cleared during processor
       outage because neither side should be sending anything during
       processor outage and the busy condition can no longer exist.
       When recovering from processor outage, the busy condition
       cannot exist because messages were not being sent.  Both T6 and
       T7 are stopped and the busy condition is cleared when entering
       processor outage state.  This is consistent with Q.703.

    4. Section 4.1.5: In MTP2, a Busy receiver stops acking until Busy
       clears. But in M2PA neither end does anything different in Busy
       (except start T6 and not fail on T7 expiry). Is this OK?

       A: This was discussed long ago. SCTP has congestion
       procedures. M2PA just runs T6 to make sure SCTP fixes the
       congestion in a reasonable amount of time. 

       Brian Bidulock (02/05/03): Neither end stops sending or
       acknowledging messages during the busy condition.  The busy end
       is just given more time (T6 instead of T7) to acknowledge.
       This is consistent with Q.703.

08. 02/06/03 Andrew Booth "[Sigtran] More M2PA 7 questions".

    02/18/03 Andrew Booth "[Sigtran] Repost - More M2PA 7 questions".

    Several comments.

    1. Does every User Data received from the peer increase the
       expected FSN for the subsequent message, even in cases where
       the received message is later discarded as part of a Flush
       Buffers or Changeover procedure?

       A: I think this is taken care of by acking the messages
       received before the PO. See the "Flush buffers" discussion.

    2. In 4.2.6, BSNT should be number of last message delivered to
       MTP3, not number of last message received by M2PA. 

       A: There was much discussion about this. 

          [?? STILL OPEN: We are getting close, but have not quite
	  agreed on this.]

    3. How should T7 be handled when remote processor outage abates?

       A: Add in 4.1.4:

          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 Processor Outage Ended
	  message. The local M2PA SHALL resume receiving and
	  transmitting messages. **M2PA SHALL restart timer T7 for any
	  messages in the retransmission buffer.**

    4. In section 5.1 we transition to proving without starting T3 and
       to aligned ready without receiving LS Proving.  

       A: These were unintentionally omitted. I added those events to
       the diagram.

    5. In 5.8 text, there is a reference to SCTP retrieval. 

       A: This is left over from an earlier version. I removed that
       paragraph.

    6. In 4.2.6, should there be a note about the circular buffer in 
       "any transmitted User Data messages beginning with the first
       unacknowledged message with FSN greater than FSNC."

       A: There is a general warning about this in 4.2.1.

09. 02/07/03 Wayne Taylor "[Sigtran] M2PA draft 7 question". 

    02/12/03 Jeff Craig "Re: [Sigtran] M2PA draft 7 question --
    alignment conclusion".

    Problems with LS Alignment received before MTP3 Start.

    A: Jeff Craig suggested replacement text. I used it with a few
    changes because of the new LS OOS section 4.1.6.

10. 02/11/03 Franz Gaiser "M2PA draft 07 comment: LPO".

    02/13/03 Franz Gaiser "AW: [Sigtran] M2PA draft 07 comment: LPO".

    What if Proving ends and there is an LPO?

    A: In section 4.1.3, I added to the end of the paragraph:

       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 the local
       processor outage condition exists when M2PA completes Proving,
       M2PA shall enter the ALIGNED NOT READY state.**

       Figure 7: Show an arrow from PROVING to ALIGNED NOT READY.

       [?? STILL OPEN: Jeff Craig 02/19/03 comments about Figure 7.] 

11. 02/13/03 Jeff Craig "[Sigtran] M2PA draft needs to note that timer
    T1 differs from Q.703 timer T1".

    A: On further review, there was no problem.

12. 02/18/03 Remove this paragraph from 5.8 because it no longer
    applies:

    Note that in this example, the sequence numbers and messages
    requested by MTP3 are sent from SCTP to M2PA in the Communication
    Lost primitive. In general, the retrieval of sequence numbers and
    messages is implementation dependent.

    A: Done.

13. 02/27/03 Subhashini "Re: [Sigtran] Repost - More M2PA 7 questions]
    - LS OOS during alignment."

    In Figure 7, "Receive LS OOS" in INITIAL ALIGNMENT should not
    cause transition to OUT OF SERVICE.

       A: Right. I removed that label from the arrow.

    In 4.1.3, how often should LS Ready be sent?

       A: It is optional. 

14. 02/27/03 Jeff Craig "[Sigtran] (M2PA) Another change to the state
    machine diagram -- Rcv Rdy or PO during PROVING".

    Several inputs to PROVING cause no state change (Receive LS
    Proving, LS Ready, LS PO). Show this in Figure 7.

    A: Done. Also LPO goes on this arrow.

15. 02/28/03 Andrew Booth "[Sigtran] M2PA nits".
    In 4.2.1, should "any of the FSNs of the User Data messages in the
    M2PA retransmit buffer" be retransmit buffer?

    A: Yes. I made the change.

16. 03/05/03 S. Magesh "[Sigtran] Modification in Figure 7 of M2PA
    Draft Version 7".

    Figure 7: Should transition from INITIAL ALIGNMENT to PROVING show
    "Send LS Align" along with "Receive LS Align" as in draft 6?

    A: I don't think it needs to be there. "Send LS Align" is an
    action in the INITIAL ALIGNMENT state. It does not cause the
    transition.

17. 03/06/03 I changed the overly wordy "Link Status Processor Outage
    Ended" to the merely wordy "Link Status Processor Recovered".

    A: Done.

=====================================================================

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