Subject: [Sigtran] M2PA: List of changes in version 8

From: Tom George <[email-masked]>
Date: Fri, 25 Apr 2003 11:39:13 -0500

List of changes in M2PA draft version 8. 
Tom George
04/25/2003

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:

Portions of the document that duplicated MTP2 (e.g., Q.703) were
removed. The document now focuses on differences between M2PA and
MTP2. 

Specific changes:

Authors. I moved Malleswar Kalla and Greg Sidebottom from authors to
Acknowledgements. 

Abstract. Added last sentence about M2PA operating like MTP2.

TABLE OF CONTENTS. Updated sections.

1.5 Signaling Transport Architecture, paragraph 2. Added 2 sentences
about M2PA replacing MTP2.

1.5 Signaling Transport Architecture, para "Figure 2 shows
...". Clarified wording.

1.6.1 Support for MTP Level 2, para 2. Moved this here. It was in
1.7.1.

1.6.2 Support for peer-to-peer, last para. Clarified reasons for
eliminating FISU. 

1.7.1 Removed old section "Support of MTP3/MTP2 Primitives" and moved
its content to 1.6.1. Old section 1.7.2 and following sections are
moved up.

1.7.1 MTP2 Functionality, para 1. Clarified.

1.7.3 Changed name from "SCTP Stream Management" to "SCTP Association
Management". 

1.7.3 SCTP Association Management, last para. Added paragraph about
SCTP notifications. 

1.8.1 Definition of the M2PA / MTP Level 3 boundary. Removed the list
of primitives, since this duplicates MTP2.

2.2.2 Forward Sequence Number (FSN), last para. Added range of
values. 

2.3.1 User Data, para "M2PA SHALL NOT ..." Changed requirement from
"does not" to "SHALL NOT".

2.3.2 Link Status, list. Changed name of "Processor Outage Ended" to
"Processor Recovered".

3. Changed name from "M2PA Link State Control" to "State Control".

3.1  SCTP Association State Control. New section with the same
information about SCTP states.

3.2  M2PA Link State Control. Removed list of states, since this
duplicates MTP2.

3.2  M2PA Link State Control. Removed state diagram (old Figure 7),
since this duplicates MTP2. Subsequent diagrams are renumbered.

4.  Procedures. Added text to this previously empty section. This
explains that M2PA works like MTP2 except as specified.

4.1.1 Signal Unit. Added paragraphs 3-6. They clarify services
provided by SCTP.

4.1.3  Link Alignment. This section is significantly rewritten to
eliminate duplication of MTP2. The procedure itself is no longer
described. Instead, it is explained how M2PA messages replace MTP2
messages and how they are sent differently.

4.1.4 Processor Outage. This section is significantly rewritten to
eliminate duplication of MTP2. 

4.1.5 Level 2 Flow Control. This section is rewritten to eliminate
duplication of MTP2. Paragraph about definition of Busy is
removed. Paragraph about T6 expiry is removed. Paragraph about T7
expiry is removed. Paragraph about stopping T6 is removed. T6 range of
values is removed.

4.1.6  Link Out of Service. Added new section to collect information
about procudures when a link is OOS.

4.1.7 Changed name of section from "Error Monitoring" to "SCTP
Association Problems".

4.1.7 SCTP Association Problems. Added 1st paragraph listing possible
SCTP failures. 

4.2.1  Sending and receiving messages, para 2 and 4. Clarified that
status is sent on stream 0, data on stream 1.

4.2.1  Sending. Removed paragraph about passing user data messages to
MTP3, since this duplicates MTP2.

4.2.1  Sending. Removed requirement to set first FSN to 1. Follow MTP2
instead.

4.2.1  Sending. Removed requirement to increment FSN. This duplicates
MTP2. 

4.2.1  Sending. Removed paragraph with the definition of BSN. This
duplicates MTP2. 

4.2.1  Sending. Removed requirement to removed acknowledged messages
from queue. This duplicates MTP2. 

4.2.1  Sending. Removed paragraph with the "2 out of 3"
criterion. This duplicates MTP2.  

4.2.1  Sending. Para "If there is ...". Added last sentence giving
guidance about sending ack message promptly.

4.2.1  Sending. Para "Note that there is no reason ...". Clarified
reason, i.e., that the messages are not retrieved for changeover.

4.2.1  Sending. Para "Note that since SCTP ...". Added requirement to
keep messages in queue until they are acked.

4.2.1  Sending. Para "Because propagation ...". Clarified that T7 is
per-message. Removed list of conditions about T7 expiry, since this
duplicates MTP2. 

4.2.1  Sending. Removed T7 range of values since this duplicates MTP2.

4.2.2 Removed old section "Link activation and restoration". It
duplicates MTP2. 

4.2.3 Removed old section "Link deactivation". It duplicates MTP2. 

4.2.4 Removed old section "Flush Buffers and Continue". It duplicates
MTP2.  

4.2.2 MTP3 Signaling Link Congestion. This and subsequent sections are
renumbered. 

4.2.2 MTP3 Signaling Link Congestion. Deleted old paragraph about
Congestion Indication primitive. This duplicates MTP2.

4.2.3 Changeover. Removed old paragraphs that explain data
retrieval. This duplicates MTP2. 

4.2.3 Changeover. Removed old requirements to send Retrieval Complete
to MTP3. This duplicates MTP2. 

5.1  Link Initialization. In Figure 12, showed timer T3 start and
stop. 

5.8  Link Changeover. Removed old paragraph about messages being
retrieved in the Communication Lost primitive. This no longer applies,
since M2PA has its own queue.

6. Security. Removed material from this section that duplicates the
SIGTRAN security draft. Rearranged the remaining material.

7.1 SCTP Payload. Removed UDP since port is not registered for UDP.

8.  Acknowledgements. I moved Malleswar Kalla and Greg Sidebottom from
authors to here.

9.  References. Divided into Normative and Informative sections. 

10.  Author's Addresses. Removed information for names removed from
the author list.

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

---

From: "Rohan Pascal S Goveas" <[email-masked]>
Date: Mon, 28 Apr 2003 12:33:12 +0530

All,
    Can anyone give me a pointer to the mail discussions thread which led to
the introduction of Proving state in M2PA and the exchange of Proving
message during this state.

Thanks in advance.

Rohan

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 28 Apr 2003 01:58:22 -0600

Rohan,

Proving was included in the original drafts some years ago.

The reasons for proving are the same as for Q.703 and Q.2140.  Because
SCTP does not provide any assurances of grade of service or carrying
capacity of an association it is wise to ensure that the association is
usable before performing changeback at MTP3.  Otherwise, an unusable
association would be offered traffic and then fail, reducing the overall
message transfer reliability of the network due to potential losses and
missequencing resulting from the changeover procedure at MTP3.  (Even
Q.2140 provides for a proving period with loading at approximately 50%
of the cell rate as a normal procedure even though the SAAL provides
much stronger assurances of the quality of service of of the link than
does SCTP.)

If you question the need for proving in M2PA, consider that it has
purpose in both Q.703 and Q.2140: the reduction of message loss and
missequencing due to changeback/changeover oscillation from repeated
failure under load.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Rohan Pascal S Goveas" <[email-masked]>
Date: Mon, 28 Apr 2003 16:36:38 +0530

Brian,
   In Q.703 the purpose of proving period is to verify the stability of the
link for a certian duration of time(Proving interval). During the Proving
state LS  Normail / Emeregency messages are exchanged. In contrast in M2PA
we have a message called Ls (Proving) with a filler which is used to verify
the SCTP checksum.This filler isnt the in MTP2.
    Once the SCTP association is established it means that it can reliably
and in sequence deliver the message to the peer. i.e we can put traffic once
the both peers Ready instead of putting the assocaition thru a proving
period.
 Secondly  SCTP treats any payoad data given for transport without any
distinction, keeping this in mind what is the idea behind the sending of
filler size equivalent to that of of User data traffic.
Are we doubting the relability of the underlying SCTP to carry MTP3 User
data??.

Rohan

----- Original Message -----
From: Brian F. G. Bidulock <[email-masked]>
To: Rohan Pascal S Goveas <[email-masked]>
Cc: Tom George <[email-masked]>; SIGTRAN e-mail list
<[email-masked]>
Sent: Monday, April 28, 2003 1:28 PM
Subject: Re: [Sigtran] Proving Message

Rohan,

--brian

---

From: "pardeep" <[email-masked]>
Date: Mon, 28 Apr 2003 15:17:24 +0530

Brian
As you have written that Proving was included in the original drafts some
years ago. May be you are refering to Q.703. In case of Q.703 checking of
link reliabilty & integrity was its job, but in case of M2PA we are using
the services of SCTP which is "RELIABLE".

As you have written that SCTP does not provide any assurances of grade of
service or carrying
capacity of an association implementation may want to ensure that the
association is usable before sending actual MTP3 traffic (in changeback or
intial alignement) .

But I don't think this is required because all these functionality of SCTP
stack will be tested during functional/ load testing of SCTP Stack.
Load/Stress testing of SCTP shouldn't be the part of M2PA functionality. If
SCTP association is established sucessfully then M2PA should trust that it
is usable for carrying traffic.

Thanks

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "Rohan Pascal S Goveas" <[email-masked]>
Cc: "Tom George" <[email-masked]>; "SIGTRAN e-mail list"
<[email-masked]>

Rohan,

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 28 Apr 2003 05:31:43 -0600

pardeep,

> the services of SCTP which is "RELIABLE".

SCTP is only "reliable" until the association fails.

> stack will be tested during functional/ load testing of SCTP Stack.

No, it is required due to prevailing network conditions and has nothing
to do with SCTP stack function/load testing.

> is usable for carrying traffic.

On the contrary, just because an association is established, has exchanged
the alignment messages, does not mean that it is usable.  It may fail, for
example, due to congestion when offered traffic.

This is also true for Q.2140.  Did you think that SCTP was so different
from SCCOP?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 28 Apr 2003 05:35:16 -0600

Rohan,

> the SCTP checksum.This filler isnt the in MTP2.

Read Q.2140.

--brian

---

From: David Lehmann <[email-masked]>
Date: Mon, 28 Apr 2003 08:40:35 -0400

> SCTP is only "reliable" until the association fails.

Couldn't this happen with or without a proving period?

-- 

David Lehmann                          Ulticom, Inc.
AOL/Yahoo IM: davidULCM                1020 Briggs Road
1-856-787-2729                         Mt. Laurel, NJ 08054   USA

---

From: David Lehmann <[email-masked]>
Date: Mon, 28 Apr 2003 10:51:39 -0400

> Are we doubting the relability of the underlying SCTP to carry MTP3 User

Good question.  Can the authors address this question?
Also, why don't we need to prove the worthiness of the
SCTP associations which carry SS7 messages over M3UA?

--

---

From: Tolga Asveren <[email-masked]>
Date: Mon, 28 Apr 2003 12:23:02 -0700 (PDT)

> SCTP associations which carry SS7 messages over
[TOLGA]The reason to have filler size equivalent to
that of user data traffic was, to increase cwnd of
SCTP during proving period.

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: David Lehmann <[email-masked]>
Date: Mon, 28 Apr 2003 15:38:53 -0400

> SCTP during proving period.

If that is so necessary, why isn't it in M3UA?

--

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 28 Apr 2003 14:08:27 -0600

David,

David Lehmann wrote:                                                                 (Mon, 28 Apr 2003 15:38:53)
> If that is so necessary, why isn't it in M3UA?

It is.  M3UA just ignores the issue.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 28 Apr 2003 14:07:40 -0600

David,

David Lehmann wrote:                                                                 (Mon, 28 Apr 2003 10:51:39)

Read Q.2140.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 28 Apr 2003 14:07:00 -0600

David,

David Lehmann wrote:                                                                 (Mon, 28 Apr 2003 08:40:35)
> Couldn't this happen with or without a proving period?

With a proving period sooner than later: i.e. before changback
and not requiring changeover for recovery.

--brian

---

From: Tom George <[email-masked]>
Date: Tue, 29 Apr 2003 11:11:36 -0500

David,

Yes, an association can fail with or without a proving period. Proving
can only verify the usability of the link during the proving period.
Network conditions could change after the proving period ends. That is
one of the things you have to live with when using a shared resource
instead of having a dedicated link as in traditional SS7. 

The M2PA proving period gives some assurance, though not an absolute
guarantee, that the association can be used as a link. 

tomG.

> Brian F. G. Bidulock wrote:
  [...]