Subject: [Sigtran] I-D ACTION:draft-ietf-sigtran-m2pa-07.txt

From: [email-masked]
Date: Tue, 21 Jan 2003 07:52:50 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Signaling Transport Working Group of the IETF.

	Title		: SS7 MTP2-User Peer-to-Peer Adaptation Layer
	Author(s)	: T. George et al.
	Filename	: draft-ietf-sigtran-m2pa-07.txt
	Pages		: 55
	Date		: 2003-1-20
	
This Internet Draft defines a protocol supporting the transport of
Signaling System Number 7 (SS7) Message Transfer Part (MTP) Layer 3
signaling messages over Internet Protocol (IP) using the services of
the Stream Control Transmission Protocol (SCTP).  This protocol would
be used between SS7 Signaling Points employing the MTP Level 3
protocol. The SS7 Signaling Points may also employ standard SS7 links
using the SS7 MTP Layer 2 to provide transport of MTP Layer 3
signaling messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sigtran-m2pa-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sigtran-m2pa-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sigtran-m2pa-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Tom George <[email-masked]>
Date: Tue, 21 Jan 2003 10:40:01 -0600

Here is a list of changes made in M2PAv7 arranged by threads. I am
working on a more detailed list of changes and should be able to post
that tomorrow.

List of comments on M2PA draft version 6. 
01/21/2003

Here is my list of comments on M2PA draft version 6 and how they were
incorporated into version 7. 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. 09/02/02 Howard May, Ming Lin "[Sigtran] M2PA - Retrieval
    State". Is this state needed?

    11/21/02 Jeff Craig suggested more changes.

    A: Retrieval state is not needed. It is eliminated in Figure 7 and
    elsewhere.

    AIP is changed to INITIAL ALIGNMENT.

    ALIGNED NOT READY and PROCESSOR OUTAGE states were added. 

02. 09/04/02 Andrew Booth "[Sigtran] M2PA 6: message acknowledgement"
    and 
    09/12/02 anssharma "[Sigtran] M2PA : FSN value in Zero Data Acks"

    Incrementing FSN on ack-only message causes endless cycle of acking
    empty messages.

    A: Do not increment FSN on empty User Data message. Section 4.2.1
    is updated.

03. 09/17/02 Jeff Craig "(M2PA) link status messages should be received
    and processed during LPO".

    M2PA should not ack User Data messages, but it is OK to receive
    them. And M2PA should receive Link Status messages.

    A: Changed 4.1.4, 2nd paragraph.

04. 09/18/02 Jeff Craig "[Sigtran] (M2PA) Receipt of User Data during
    AIP, PROVING should cause transition to OOS".

    A: Discard message as in MTP2. Text already says this. See Brian
    Bidulock message 09/19.

05. 09/18/02 Jeff Craig "[Sigtran] (M2PA) Does an ACK (0-byte User
    Data) received in ALIGNED-READY cause transition to INS?"

    A: Yes. The text says "User Data message". That would include the
    ones with 0-byte data.

06. 09/19/02 Jeff Craig "[Sigtran] Re: Comments on
    draft-bidulock-sigtran-m2pa-test-02.ps".

    Rename timer T1 to T2, and others as well.

    A: T1 is renamed to T2. 
       T3 is renamed to T1.
       New timer T3 is added.
    New names should correspond more closely to MTP2 timer names. 

07. 09/19/02 Jeff Craig "[Sigtran] Suggested New Test Cases for
    draft-bidulock-sigtran-m2pa-test-02.ps".

    Should we eliminate the interval timers?

    A: The LS Busy, LS PO, and LS Ready MAY be sent periodically. But
    it should not be a requirement.  

    Requirement for periodic LS Ready was removed from
    4.1.3. Status_Interval was removed.

    Diagram in 5.1 was changed to show only one LS Ready, but text
    notes that more may be sent.

    Also in 4.1.3, Proving_Rate was changed to Proving_Interval.

    Requirement for periodic LS PO was removed from 4.1.4.

    Requirement for periodic LS Busy was removed from 4.1.5.

08. 09/27/02 Anshoo "[Sigtran] M2PA v6: Two Out of Three Valid BSN".

    A: I left this as is, since it makes it easier to convert M2PA to
    MTP2.

09. 09/26/02 Howard May "[Sigtran] M2PA V6: T7". Should T7 timer be
    per-message? 

    A: Yes. Updated section 4.2.1 Sending and receiving messages.

10. 10/10/02 Howard May "RE: [Sigtran] M2PA V6: LS Busy".

    Is it OK to be sending LS Busy and LS PO at the same time?

    A: There is no harm in this. No change needed to the draft.

11. 10/11/02 Richard Knowles "[Sigtran] M2PA testing at Plugtest".

    Change timer names: T1 to T2, T3 to T1. 

    T3 in Q.703 has no analog in M2PA. It should exist.

    A: Done. See previous item (6) on this.

12. 10/31/02 Barry Nagelberg "[Sigtran] m2pa v6: Recovering from a
    processor outage".

    11/05/02 Rohan. "[Sigtran] Clarification regarding Processor
    Outage". In section 4.2.4, do we need Continue before sending
    messages?

    Move last paragraph of 4.2.4 to 4.1.4. Change the statement to
    remove requirement that M2PA receive Flush Buffers or Continue.

    A: The last paragraph of 4.2.4 was moved to 4.1.4. The wording in
    4.1.4 was changed to refer to the MTP2 standards for the use of
    Flush Buffers and Continue. 

13. 10/31/02 Barry Nagelberg "[Sigtran] m2pa v6: Notifying MTP3 about
    end of PO".

    If peer receives LS PO Ended during Alignment, it should not
    notify MTP3 with the Remote Processor Recovered Indication.

    A: The last paragraph of 4.1.4 is changed to say that the Remote
    Processor Recovered Indication is given only in the IN SERVICE
    state.

14. 10/31/02 Barry Nagelberg "[Sigtran] M2pa v6: Timer T7 timeout
    during PO".

    M2PA should not fail a link because of T7 expiry if there is a
    Processor Outage condition.

    A: Correct. Section 4.1.4 is modified accordingly.

15. 11/04/02 Jeffrey Craig "[Sigtran] M2PA Plugtest Comments - Day
    1". Several comments.

    1. T7 should be disabled during Remote PO.

       A: Yes. See previous item about this.

    2. During ALIGNED-READY with local processor outage in-effect, is
       received User Data an event that should trigger a transition
       to INS state? (Currently M2PA should not receive user data from
       SCTP when LPO is in effect.)

       A: M2PA should not receive user data from SCTP when LPO is in
       effect because it cannot be processed by MTP3 (or one of the
       higher layers). 

    3. Should M2PA support the PO outage procedure as in Q.703, or
       should it take the link OOS when it detects LPO?

       A: I put the PO procedure in M2PA because it seemed better to
       keep the link up when possible, rather than failing it and
       going through alignment again.

    4. Should LSA received during ALIGNED-READY cause a transition to
       OOS (to match Q.703)?

       01/17/03 Tom George "[Sigtran] M2PA: LS Alignment after
       proving".

       A: LS Alignment causes OOS in either the "Aligned Ready" or "In
       Service" states. It also should put the link out of service in
       the "Aligned Not Ready" state.

       I updated the state diagram accordingly. 

16. 11/06/02 Michael Tuexen. "[Sigtran] M2PA discussions on M2PA".

    The handling of Alignment messages in 'unexpected' state needs
    to be clarified in the ID.

    A: Done. See the paragraph "Anomalous messages..." at the end of
    4.1.3.

17. 01/01/03 S Magesh. "[Sigtran] Contradiction between M2PA RFC Draft
    Version 6 and M2PA RFC Test Specification Draft Version 02".

    Timer names in M2PA draft do not match the M2PA test spec.

    A: Brian Bidulock suggests changing timer names. 

    Done. See previous item about this (6).

18. 01/03/03 Srini "[Sigtran] M2PA two out of three". Is the statement
    worded accurately?

    A: Yes, though it is a bit hard to read. Leave it as in Q.703.

19. 01/14/03 Jeffrey Craig "[Sigtran] (M2PA) Any word on when we can
    expect a M2PA v7?".

    Brian Bidulock suggested some stylistic changes.

    A: I made some stylistic changes suggested by Brian Bidulock:

       - I changed the reference format.
       - I added dots to the diagrams in section 5. 
       - I added figure numbers to the diagrams in section 5. 

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

-- 
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel USA, Inc.; 1000 Coit Rd, MS PB7-SWPRO; 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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 21 Jan 2003 10:20:29 -0700

Tom,

Good job!

--brian

Tom George wrote:                                                                      (Tue, 21 Jan 2003 10:40:01)

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

---

From: Tom George <[email-masked]>
Date: Wed, 22 Jan 2003 15:03:18 -0600

This is a more detailed list of changes. It is arranged according to
the order of the document. 

This list does not include minor changes to wording, formatting, etc.

General changes:

   Changed the reference format. E.g., [Q.703] instead of [2].

   Changed some requirement words to capital letters: SHOULD, MUST,
   etc. I MAY have missed some. Let me know if any SHOULD or MUST be
   changed. 

1.6.2 Support for peer-to-peer communication

   In last paragraph, removed "Link Status messages" since they are
   not used to carry acknowledgement. 

2.3.1 User Data 

   Added: "The User Data is an optional field. It need not be included
   in an acknowlegement-only message."

3.  M2PA Link State Control

   State IDLE changed to POWER OFF. 

   State AIP changed to INITIAL ALIGNMENT.

   Added states ALIGNED NOT READY and PROCESSOR OUTAGE.

   Removed state RETRIEVAL.

   Updated state diagram (Figure 7). Changes include:

      IDLE renamed POWER OFF. 

      AIP changed to INITIAL ALIGNMENT.

      Added arrow to OUT OF SERVICE: "Flush Buffers or Retrieval",
      since Retrieval state was removed. 

      Added "OR Receive LS OOS" to arrow INITIAL ALIGNMENT -> OOS.

      Added "OR T3 Expiry" (new timer T3) to arrow PROVING -> OOS.

      Added "Send LS Ready" to arrow PROVING -> ALIGNED READY. 

      Added "OR Receive LS Align" to arrow ALIGNED READY -> OOS.

      Added "OR Receive LS Align" to arrow IN SERVICE -> OOS.

      Added states ALIGNED NOT READY and PROCESSOR OUTAGE, and arrows
      in/out.

4.1.2 MTP and SCTP Entities

   Table 2 - Changed "IPSP Y" to "IPSP Y/Z" since same info applies to
   both.

4.1.3  Link Alignment

   Timer T1 is renamed to T2.

   Timer T3 is renamed to T1.

   Added new timer T3. Added statements about when T3 is started,
   stopped, and what happens if it expires.

      Paragraph "When M2PA has both...": Added "M2PA starts the
      aligned timer T3 and moves to the proving state."

      Added paragraphs:

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

   Paragraph "During the proving period...": Proving_Rate is changed
   to Proving_Interval, since that is a better description.

   Paragraph "When the proving period timer T4...": Added that M2PA
   goes to ALIGNED READY state. It is no longer required to send LS
   Ready periodically. It is allowed. Changed 

         "send Link Status Ready messages to its peer at interval
	 Status_Interval. These messages are used to verify that both
	 ends have completed proving."
      to
         "send a Link Status Ready message to its peer. These [oops - 
	 should be "the"] 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."

   In paragraph "If M2PA receives a Stop command...", clarified that
   M2PA goes to OOS state.  

   In paragraph "Anomalous messages..." item (b) has added "before
   or" during proving.

   Recommended values: Changed these to be more consistent with Q.703.

   Recommended values: Removed Status_Interval.

   Recommended values: Changed Proving_Rate to Proving_Interval.

4.1.4 Processor Outage

   Paragraph "When M2PA detects ...": Changed "M2PA shall stop
   receiving incoming messages from SCTP" to "M2PA SHALL stop
   acknowledging received User Data messages."

   Paragraph "M2PA MAY send additional ...": It is no longer required
   to send LS PO periodically. It is allowed. Changed "M2PA should
   periodically send a Link Status Processor Outage message" to "M2PA
   MAY send additional Link Status Processor Outage messages".

   Paragraph "The peer M2PA ...": Timer T7 is disabled during
   PO. Added to end of paragraph, "and timer T7, if it is running."

   Paragraph "MTP3 may send a Flush Buffers...": Added sentence to
   point to Q.703, "The use of Flush Buffers and Continue is specified
   in Q.703 [Q.703] and T1.111.3 [T1.111]."

   Paragraph "When the processor outage ceases...": Moved sentence
   here from 4.2.4, "The local M2PA SHALL resume receiving and
   transmitting messages."

   Paragraph "If the peer is in the IN SERVICE...": Qualified that
   Indication is used only when in IN SERVICE. Changed "The peer uses
   the Remote Processor Recovered Indication" to "If the peer is in
   the IN SERVICE state, it uses the Remote Processor Recovered
   Indication".

4.1.5 Level 2 Flow Control

   Paragraph "M2PA MAY send additional..": It is no longer required to
   send the LS Busy messages periodically. It is allowed. Changed
   "M2PA should periodically send a Link Status Busy message" to "M2PA
   MAY send additional Link Status Busy messages".

   Paragraph "When the peer M2PA receives...": Since there can be more
   than one LS Busy message, this clarifies that the T6 timer is
   started only on the FIRST message. It is not restarted every time
   M2PA receives LS Busy. Added "first" and the sentence, "Additional
   Link Status Busy messages received while T6 is running do not cause
   T6 to be reset."

   Paragraph "If timer T6 expires...": Retrieval state was removed, so
   changed "Retrieval" to "Out of Service".

   Paragraph "Recommended values": Added T6 default 4.5 sec.

4.2.1  Sending and receiving messages

   Paragraph "The Forward Sequence Number ...": FSN is not incremented
   for the empty User Data messages. Added "(provided that the message
   contains a data payload)".

   Paragraph "If there is no other...": FSN is not incremented for the
   empty User Data messages. Changed "is incremented as with any other
   User Data message" to "is not incremented. It MUST contain the same
   FSN as the most recently sent User Data message containing Data."

   Added paragraphs:

      "If M2PA receives an empty User Data message, it SHALL NOT send
      an acknowledgement of that message."

      "Note that there is no reason to place empty User Data messages
      in the M2PA retransmit buffer, since the empty messages are not
      retransmitted and timer T7 (below) does not apply to them."

   Paragraph "Timer T7 provides...": 

      In (a), used clearer language. Changed "in the M2PA transmit
      buffer that has been sent" to "in the M2PA retransmit buffer".

      In (b), added for clarity, "(i.e., the local timer T6 is not
      running)".

      In (c), made T7 a per-message timer. Changed 
         "M2PA has not received an acknowledgement in the span of T7." 
      to 
         "There is a message in the M2PA retransmit buffer that has not
	 received an acknowledgement in the span of T7 since its last
	 transmission."

   Paragraph "Recommended values": Added T7 default 1.0 sec.

4.2.4  Flush Buffers and Continue

   Paragraph was deleted: "If M2PA receives either a Flush Buffers or
   Continue command from MTP3, and the processor outage condition
   ceases, M2PA shall resume receiving and transmitting messages." The
   information was moved to 4.1.4.

5.  Examples of M2PA Procedures

   Throughout this section: 

      Added Figure numbers for the diagrams.

      Added dots to improve readability.

5.1  Link Initialization (Alignment)

   Figures 12 and 13: Renamed timers as in the text. 

   Figure 13: Changed to show only one LS Alignment sent. Changed text
   in the figure from "Send Link Status Ready until" to "Send Link
   Status Ready (one or more)".

7.1 SCTP Payload Protocol Identifier

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

9.  References 

   Changed the reference format and updated some of the references. 

10.  Author's Addresses

   Updated some of the authors' information.

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