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

From: [email-masked]
Date: Fri, 30 Aug 2002 07:50:00 -0400

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-06.txt
	Pages		: 50
	Date		: 2002-8-29
	
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-06.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-06.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-06.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: Fri, 30 Aug 2002 10:30:10 -0500

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