Subject: [Sigtran] M2PA: List of comments on version 7

From: Tom George <[email-masked]>
Date: Fri, 25 Apr 2003 09:38:15 -0500

List of comments on M2PA draft version 7. 
Tom George
04/25/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.

If anyone wants to study the changes in detail, I have a "diff" file I
can send.

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. It buffers but does not ack incoming User Data
    messages. It acks User Data messages received before the LPO. 

    Likewise, the peer buffers but does not ack incoming User Data
    messages. It acks User Data messages received before the LPO. 

    In other respects, M2PA SHOULD follow the same procedures as MTP2
    in processor outage.

    I removed section 4.2.4 "Flush Buffers and Continue" since
       (a) it is only relevant to Processor Outage, and
       (b) it is only duplication of MTP2. 

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: This arrow from INITIAL ALIGNMENT to ALIGNED NOT READY was
       incorrect. LPO during alignment/proving does not stop the
       alignment/proving process.

       Since this figure was removed, M2PA should follow MTP2 on this
       matter.

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

       A: Follow MTP2. It goes to ALIGNED NOT READY. 

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

       A: Follow MTP2 on this. Q.703 Figure 8 (sheet 9 of 14) says to
       go to In Service and stop T1. 

    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.3. In version 7, each side
       waits on the other to start proving. T3 and T4 should be
       started as they are in MTP2. M2PA begins sending Proving
       messages and starts T3.

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

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

    Processor outage. Needs clarification, especially about flushing
    buffers.

    A: Here M2PA should just follow MTP2. This section was rewritten
    accordingly.

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
	  above MTP3. The Signaling Gateway acts as a Signal Transfer
	  Point (STP).  Other STPs MAY 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. We finally settled on:

          The BSNT is the Forward Sequence Number of the last User
	  Data message received from the peer and accepted by the
	  upper layer MTP3.

       This should be the same as MTP2.

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

       A: Originally I was going to 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.**

       But this addition is no longer necessary. M2PA should do what
       MTP2 does.

    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. These changes mostly
    were to make M2PA consistent with MTP2. 

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: M2PA should go to the ALIGNED NOT READY state. This is the same
    as MTP2.

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, though the figure is gone. This works as in MTP2.

    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: This is correct, though the figure is gone. This works as in
MTP2.

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. But since this is the same as MTP2, the text no longer
    needs to be there. It has been removed. 

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. In any case, the figure has been removed.

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

    A: Done.

03/07/03 revised version sent to SIGTRAN list.

18. 03/10/03 Jeff Craig "Re: [Sigtran] M2PA: Revised section 3".

    Several comments from Jeff and others.

    A: These comments were intended to make M2PA more consistent with
    MTP2. M2PA should work like MTP2 in all of these cases, even
    though the figure has been removed.

19. 03/11/03 Magesh ""[Sigtran] Anomalous Messages.

    Section 4.1.3: "BEFORE OR" is incorrect:

    (b) Link Status Alignment received BEFORE OR during proving.

    A: This is correct. Since this was duplication of MTP2, the
    paragraph was removed.

20. 03/11/03 Subhashini "Re: [Sigtran] M2PA: Revised section 3".

    Figure 7: Show action of LS OOS in OOS and INITIAL ALIGNMENT. 

    A: The figure has been removed. M2PA should behave like MTP2 in
    this case.

21. 03/11/03 Subhashini "Re: [Sigtran] M2PA: Revised section 5-5.1".

    Questions about sending LS Proving and timers T3, T4. 

    A: No change needed.

22. 03/11/03 Subhashini "Re: [Sigtran] M2PA: Revised section 4.1".

    Question about receiving User Data during Proving. 

    A: No change needed.

23. 03/11/03 Andrew Booth "Re: [Sigtran] M2PA: Revised section 4.1".

    Several editorial comments.

    A: Several minor changes were made.

       Section 4.1.7 - the title was changed from "Error Monitoring"
       to "SCTP Association Problems".

       Concerning the comment about sending OOS to MTP3 after a Stop
       command: This is now like MTP2, so it is not mentioned in the
       document.

24. 03/11/03 Tom George "[Sigtran] M2PA Proc Outage section".

    In PO, should both ends stop T7?

    A: It is OK as is. The RPO end should still be acking messages
    sent before the PO, so the LPO can leave T7 running for those
    messages.

24. 03/12/03 Tom George "[Sigtran] M2PA T7 value".

    Does T7 range allow too many messages to buffer?

    A: Range is OK. Use congestion onset to prevent too many messages
    from buffering.

24. 03/12/03 anssharma "[Sigtran] M2PA Flush Buffers".

    Add to definition of Flush Buffers:

       c) M2PA SHALL discard all messages present in the transmit
	  queue that are waiting to be acknowledged by the peer.

       d) M2PA SHALL discard all messages that have been received and
	  buffered while the Peer was in Outage.

    A: OK. This is the same as MTP2 now, so it is not mentioned
    explicitly.

25. 03/12/03 Barry Nagelberg "Re: [Sigtran] M2PA: Revised section
    4.1".

    Section 4.1.4, last 2 paragraphs. The LPO end does not stop T7, so
    it should not have requirement to restart it. That belongs in the
    next paragraph.

    In last paragraph, reword to use the (new) PROC OUTAGE state. 

    A: OK. This is the same as MTP2 now, so it is not mentioned
    explicitly.

26. 03/13/03 Jeff Craig "Re: [Sigtran] M2PA: Revised section 4.1".

    Comment about state change from PROCESSOR_OUTAGE to IN_SERVICE. 

    A: This needs to be done as in Q.703. This is the same as MTP2
    now, so it is not mentioned explicitly.

27. 03/20/03 Magesh "Re: [Sigtran] M2PA: Revised section 4.2".

    Should first FSN be zero?

    A: Follow Q.703 instead of setting it to 1 as in M2PAv7.

28. 03/20/03 Tom George "[Sigtran] M2PA draft question".

    Q.703 duplication should be removed from draft. Add statement that
    M2PA follows MTP2 except as specified in the draft. 

    A: I rewrote the document accordingly. Especially note section 4
    "Procedures".

29. 04/01/03 Tom George "Re: [Sigtran] M2PA T7 timer again".

    A: No change needed.

30. 04/03/03 Rohan "[Sigtran] M2PA Sequence numbers size".

    Why are M2PA sequence numbers 24 bits?

    A: That is the maximum size allowed by the XCO/XCA message. 

       No change needed.

04/08/03 revised version sent to SIGTRAN list.

31. 04/11/03 Tom George "Re: M2PA draft "7b"".

    Comment from Jeff Craig. At the end of Proving, LS Ready is not
    sent if in PO. Make this like MTP2. 

    A: I qualified this so that it is consistent with MTP2. See Q.703
    Figure 8 (sheet 5 of 14). MTP2 sends either FISU or LPO, depending
    on its condition.

32. 04/21/03 David Lehmann "[Sigtran] M2PA pre-v8".

    Should names of LS messages be the same as MTP2?

    A: I decided to make them different since 

       (a) Their structures are different.

       (b) There are different messages (e.g., LS PR).

       (c) When comparing the two standards, I thought it would be
	   easier to have different names (SIPO vs. LS PO) than to
	   have to say which standard the message comes from (MTP2
	   SIPO vs. M2PA SIPO).

33. 04/24/03 Tolga Asveren "[Sigtran] M2PA: T7 and dropping SCTP
    association after link failure".

    This was posted after I submitted M2PAv8, so it will be on the
    list of v8 comments.

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

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