Subject: Changes in draft-ietf-sigtran-m2pa-02.txt

From: Tom George <[email-masked]>
Date: Fri, 02 Mar 2001 02:06:20 -0600

I just sent draft-ietf-sigtran-m2pa-02.txt to [email-masked],
so it may not be announced for a few days. In the meantime...

Here are the changes in draft-ietf-sigtran-m2pa-02.txt (M2PA version
2), and a list of open issues.

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

A short summary of the changes:
-------------------------------

Made a decision on the LI octet question. I chose option 1a from the
list of many options for how to deal with the LI octet.

Added examples of more normal cases to 4.1.2 Link Alignment.

A lot of clarifying and rewording.

A more detailed list of changes:
--------------------------------

1.1 Scope: Added "Likewise, IP telephony applications would have
access to SS7 services."

1.6.1 Support for MTP Level 2 / MTP Level 3 interface boundary: Added
reference [10].

1.6.1 : Noted primitives that use larger sequence numbers.

1.7.4 SCTP Stream Management: Added paragraph about 2 streams.

1.7.5 Retention of MTP3 in the SS7 Network: Section is
renumbered. There were two 1.7.4's.

1.8.1 Definition of the M2PA / MTP Level 3 boundary: Added
reference [10].

1.8.1 : Mentioned discard level.

2.2.1 User Data: Clarified the LI octet.  

Figure 6: M2PA Link State Transition Diagram: Added paths from AIP and
INS-LOCAL to OOS.

4.1.2 Link Alignment: I added two examples of relationships between
links and associations - Figures 7 and 8. The old example is now
Figure 9.

4.1.2 Link Alignment: I reduced the upper limit of the range for T1
from 150 to 50.

4.1.3 Processor Outage: In last paragraph, added mention of Continue.

4.1.4 Level 2 Flow Control: Removed requirement that M2PA cease
transmitting when remote end is busy. SCTP has procedures to take care
of this.

4.1.5 Error Monitoring: Added requirement to periodically check SRTT.

4.2.4 Flush Buffers, Continue: Added mention of Continue.

4.2.4 Flush Buffers, Continue: In (a) clarified that messages are to
be discarded.

4.2.6 Changeover: Added note of which primitives use large sequence
numbers.

4.2.6 Changeover: Paragraph beginning "For data retrieval,": This
paragraph was reworded significantly to make it clearer.

4.2.6 Changeover: Added paragraph beginning "As an example of how the
BSNT is determined," to, uh, give an example of how the BSNT is
determined.

4.2.6 Changeover: Added paragraph beginning "If there are any messages
on the SCTP receive queue,". MTP3 needs to get whatever messages it
can.

4.2.6 Changeover: Added paragraph beginning "M2PA must be able to
respond to the BSNT request". Recommendation about SCTP.

4.2.6 Changeover: Added paragraph beginning "It is helpful for
M2PA". Another recommendation about SCTP.

4.2.6 Changeover: Added paragraph beginning "For emergency
changover". Covers the case of emergency changeover.

5.5  Level 2 Flow Control: Added this example.

5.6 MTP3 Signaling Link Congestion: This was section 5.5 "Congestion
Notification to Upper Layer" in previous version.

6. Security: I added text like what is in the other adaptation layer
drafts.

8.  Acknowledgements: Added a name.

10.  Author's Addresses: Updated Ram Dantu.

Open issues: 
------------

1) Mapping of links and associations: It might be a good idea to give
more information about what data needs to be kept to do this mapping,
and how the SCTP INIT and ASSOCIATE primitives are called.

2) Link Alignment: Is there a need for a proving period?

3) What should M2PA do if there is a processor outage during link
alignment?

4) 2.1.1: The header has a version number. But there is no version
negotiation. A procedure for version negotiation should be added,
similar to M2UA.

5) 4.1.2 Maybe move the information in this section about mapping SS7
and SCTP entities to a different section, such as the stream
management section, or a new subsection of 4.1.

6) 7 Add extensibility text as in the other adaptation layer drafts.

7) Is it possible to use M2PA without an MTP3 layer above it? 

8) There could be a problem with SCTP slow start after a
changeover. Numerous messages could be thrown onto the new
link/association, which might previously have been carrying little or
no traffic. 

9) It has been suggested that the Common Header be changed to be like
the other adaptation layers. What is the advantage of this? (See
SIGTRAN e-mail from Bernard Kuc 12/04/00 for suggested text.)

10) Since there are several comments about features needed by SCTP and
MTP3, it might be helpful to add sections about this, e.g., "What M2PA
needs from SCTP".

11) Brian Bidulock e-mail on SIGTAN list 03/01/01 notes that changeover
can begin as time-controlled, then change to normal changeover. Need
to investigate how that affects section 4.2.6 Changeover.

Note: I think I have answered all of the comments I have received,
either by incorporating them into the document, putting them in the
Open Issues, or answering on the e-mail list. Let me know if you have
a comment that has not been addressed.

tomG.
-- 
* Tom George        972-519-3168         [email-masked]   *
* PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
*    Alcatel USA, Inc.; 1000 Coit Rd, MS 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. *