Subject: [Sigtran] Re: Comments on draft-bidulock-sigtran-m2pa-test-02.ps

From: [email-masked]
Date: Thu, 19 Sep 2002 12:07:11 -0400

Hello Brian,

Even more comments...

> > >
> > >Again, M2PA timers are to be aligned with Q.703 timers.  If they
> > >aren't in the M2PA draft then the M2PA draft needs to be corrected.
> >
> > Yes. M2PA timers STILL do not match Q.703.
> > Those that do match are:     T4, T6, T7.
> > Those that do not match are: T1, T3 (missing T2, T5)
>
> T2 is necessary.  This is the amount of time that the sender of
> an LSA will wait to receive an LSA.  If this timer is not running,
> MTP3 signalling link allocation and restoration procedures will
> not work properly.  The link could hang indefinitely.
>
> T5 is unnecessary.  T5 is only used in Q.703 to slip SIBs in between
> other messages.  As SCTP is reliable, one BUSY is enough until a
> BUSY-ENDED is sent.
>
> T8 is unnecessary for obvious reasons.
>
> The others should align.

I agree.

> > >Huh??
> > >
> > >3.1.4 does not have LSPO.
> >
> > I am referring to the test case description paragraph following
> > the section header: "...or a status 'Processor Outage' message...."
>
> But no LSPO is sent as part of the test.

Yes. My original comment related to the M2PA requirements related
to PO. The comment does not apply to this particular test figure
or steps.

> > >Q.703 uses LSPO (SIPO) as an indication of ready (FISU).  If the
> > >IUT sends READY it will begin receiving DATA (and lots of it) before
> > >it can assert LSPO.  Because the LPO considition occured before
> > >alignment completed, it is appropriate to use LSPO instead of LSR
> > >to complete alignment.
> > >
> >
> > I agree with what you are saying. The M2PA draft does not require
> > or suggest this behavior.
> >
> > It looks like M2PA needs a ALIGNED_NOT_READY state. Nowhere in the
> > M2PA draft does it say that LSR should not be sent when LPO is
> > in effect, and the ALIGNED-READY state is entered. This needs to
> > mentioned, or an appropriate procedural reference made.
> >
> > I would assume then, that reception of LSPO in ALIGNED-READY should
> > stop M2PA v6 timer T3. Currently, since there is no discrete
> > ALIGNED_NOT_READY state, I have implemented two "INS" states --
> > entry into one is signaled to MTP3 with "In Service Indication",
> > the other is signaled to MTP3 via "Remote Processor Outage Condition".
>
> I submitted a diagram which included PROCESSOR OUTAGE and
> ALIGNED-NOT-READY states.

Okay. Please post it to the list to prompt discussion.
Is the consensus that your new figure is going into M2PA v7?
I don't recall ever seeing it.

> > >
> > >But it should not be ignored nevertheless.  LSA is sufficient
indication
> > >that the peer M2PA has restarted.
> >
> > The M2PA draft should change to match this behavior, that is,
> > reception of LSA during INS or ALIGNED_NOT_READY should cause
> > a transition to RETRIEVAL/OOS.
>
> That brings up another point.  The last time we talked about
> the diagram we agreed there was no such thing as a separate
> RETRIEVAL state.  It does not exist in the Q.703 diagrams and
> there is no cause for it in M2PA either.

I agree.

> >The link cannot indicate OOS to MTP3 (because it is in LPO and
> > >cannot talk to MTP3!)  Therefore there is no (and is never any)
> > >indication at MTP3 until the LPO clears.  This is true of the
> > >MTP2/MTP3 interface that M2PA faithfully preserves.  Understand?
> >
> > I disagree. LPO does not mean that MTP3 is unavailable.
>
> MTP2 not being able to communicated with MTP3 is the very
> definition of the LPO state.
>
> > Q.703 Figure 8... upon the following events during ALIGNED_NOT_READY:
> > link failure; reception of SIO, SIN (LSPN), SIE (LSPE), SIOS (LSO);
stop;
> > then transition to OUT_OF_SERVICE.
> >
> > L2 must inform L3 that the link is no longer ALIGNED. I must not
> > hang out waiting for LPO cancellation.
>
> L2 cannot communicate to L3 until LPO clears.  (The Local Processor
> that happens to be out *is* L3).

Okay.

So, in terms of M2PA:
If LSO is received, or the association drops, during the
ALIGNED-NOT-READY (link aligned and LPO) state, the link
moves to the OOS state, and communicates nothing to MTP3.

When M2PA receives 'Local Processor Outage Recovered Request'
from MTP3 during OOS, then M2PA responds with 'Out of Service Indication'.

>I think it is fairly clear from these statements and others that M2PA
>must closely follow Q.703.  Otherwise the same "services" will not be
>provided to MTP3 and the objectives of M2PA lost.
>What procedures of Q.703 do you believe are not applicable to M2PA?

Perhaps my point was not clear.

The current M2PA draft does not follow Q.703 in the areas we are
discussing, and it needs to be changed.

We are in passionate agreement on this.

> > >
> > >This is the data portion of the DATA message.  The MSU if you will.
In this
> > >case, however, it is too short to be a valid MSU.
> >
> > I haven't studied the relevant specs, but should M2PA/MTP2 validate L3
payload
> > length beyond a non-zero check?
>
> There are no 1 byte MSUs in Q.703.  In Q.703 SIO+SIF of 1 byte is an
LSSU.
> M2PA does not send LSSUs in DATA.  Did you expecte M2PA to deliver 1-byte
> messages to MTP3?  I don't know that MTP3 would be prepared to deal with
> them because it never receives them from Q.703.

Ummmm.
Q.703 2.3.8: "The signalling information field consists of an integral
number
of octets, greater than or equal to 2 and less than or equal to 272".

So the M2PA requirement is that all received User Data messages
having a length <= (min_sif + sio + m2pa_header = 19) are discarded.

M2PA ignores the Q.703 text related to max size.

Regards,

Jeff

"Brian F. G. Bidulock" <[email-masked]> on 09/19/2002 10:47:00 AM

Please respond to [email-masked]

To:    [email-masked]
cc:    [email-masked]
Subject:    Re: Comments on draft-bidulock-sigtran-m2pa-test-02.ps

Jeffrey,

More comments below...

[email-masked] wrote:                     (Thu, 19 Sep 2002
09:43:36)

<snip>
> >
> >A while ago on the list, we came to a consensus that M2PA timers
> >and timer names should be aligned with Q.703 timer names.  If this
> >is different, the M2PA timer should be renamed T2.
> >
>
> Yes. M2PA timer T1 should be changed to T2 to match Q.703.
>

<snip>
> >
> >This is the period of time that the ITU will wait for a proving
> >message before placing the link OOS.  It is consistent with Q.781.
> >If you consider that the M2PA peer sends an LSA and then crashes
> >(without taking down the SCTP association), then the link must
> >fail to align at some point so that MTP3 or managment can consider
> >taking other actions.  The nature of M2PA make it possible that
> >the peer M2PA application hangs at any point without tearing down
> >the SCTP association.
>
> M2PA does not currently require this timer -- there is no requirement to
fail
> the link if no LSPx is received within a given period.
>
> Perhaps this requirement and timer should be added.
>
> In that case M2PA timer T3 must change. It could become Q.703
> timer T1, except that the M2PA timer functionality (timeout waiting
> for LSR or User Data) does not match Q.703 timer T1.
>
> According to Q.703, T1 starts at initial alignment (MTP3-START)
> and stops at the transition to INS. T1 timeout causes transition
> to OOS.

<snip>
> >
> >Again, M2PA timers are to be aligned with Q.703 timers.  If they
> >aren't in the M2PA draft then the M2PA draft needs to be corrected.
>
> Yes. M2PA timers STILL do not match Q.703.
> Those that do match are:     T4, T6, T7.
> Those that do not match are: T1, T3 (missing T2, T5)

T2 is necessary.  This is the amount of time that the sender of
an LSA will wait to receive an LSA.  If this timer is not running,
MTP3 signalling link allocation and restoration procedures will
not work properly.  The link could hang indefinitely.

T5 is unnecessary.  T5 is only used in Q.703 to slip SIBs in between
other messages.  As SCTP is reliable, one BUSY is enough until a
BUSY-ENDED is sent.

T8 is unnecessary for obvious reasons.

The others should align.

<snip>
> >Huh??
> >
> >3.1.4 does not have LSPO.
>
> I am referring to the test case description paragraph following
> the section header: "...or a status 'Processor Outage' message...."

But no LSPO is sent as part of the test.

<snip>
> >Q.703 uses LSPO (SIPO) as an indication of ready (FISU).  If the
> >IUT sends READY it will begin receiving DATA (and lots of it) before
> >it can assert LSPO.  Because the LPO considition occured before
> >alignment completed, it is appropriate to use LSPO instead of LSR
> >to complete alignment.
> >
>
> I agree with what you are saying. The M2PA draft does not require
> or suggest this behavior.
>
> It looks like M2PA needs a ALIGNED_NOT_READY state. Nowhere in the
> M2PA draft does it say that LSR should not be sent when LPO is
> in effect, and the ALIGNED-READY state is entered. This needs to
> mentioned, or an appropriate procedural reference made.
>
> I would assume then, that reception of LSPO in ALIGNED-READY should
> stop M2PA v6 timer T3. Currently, since there is no discrete
> ALIGNED_NOT_READY state, I have implemented two "INS" states --
> entry into one is signaled to MTP3 with "In Service Indication",
> the other is signaled to MTP3 via "Remote Processor Outage Condition".

I submitted a diagram which included PROCESSOR OUTAGE and
ALIGNED-NOT-READY states.

<snip>
> >
> >But it should not be ignored nevertheless.  LSA is sufficient indication
> >that the peer M2PA has restarted.
>
> The M2PA draft should change to match this behavior, that is,
> reception of LSA during INS or ALIGNED_NOT_READY should cause
> a transition to RETRIEVAL/OOS.

That brings up another point.  The last time we talked about
the diagram we agreed there was no such thing as a separate
RETRIEVAL state.  It does not exist in the Q.703 diagrams and
there is no cause for it in M2PA either.

<snip>
> >The link cannot indicate OOS to MTP3 (because it is in LPO and
> >cannot talk to MTP3!)  Therefore there is no (and is never any)
> >indication at MTP3 until the LPO clears.  This is true of the
> >MTP2/MTP3 interface that M2PA faithfully preserves.  Understand?
>
> I disagree. LPO does not mean that MTP3 is unavailable.

MTP2 not being able to communicated with MTP3 is the very
definition of the LPO state.

> Q.703 Figure 8... upon the following events during ALIGNED_NOT_READY:
> link failure; reception of SIO, SIN (LSPN), SIE (LSPE), SIOS (LSO); stop;
> then transition to OUT_OF_SERVICE.
>
> L2 must inform L3 that the link is no longer ALIGNED. I must not
> hang out waiting for LPO cancellation.

L2 cannot communicate to L3 until LPO clears.  (The Local Processor
that happens to be out *is* L3).

<snip>
> >
> >If M2PA does not ignore this sequence of events, it will behave in a
> >manner different from Q.703 and unexpected by L3.
>
> If the blanket requirement is that M2PA procedures match Q.703, then
> the draft needs to say so. But is this blanket statement correct
> for all M2PA procedures (answer is no)?

M2PA must present the same behavior to MTP3 as L3 expects of Q.703.
This means that indications must be given in the same circumstances
and within the same time intervals.  How else would one ever expect
an M2PA implementation to work with a comformant MTP3 implementation?
For example, hanging out forever waiting for an LSA without running
a timer does not meet L3's expectations and break both the basic and
dynamic signalling link allocation procedures.

Besides M2PA says:

"The delivery mechanism described in this document allows for full
MTP3 message handling and network management capabilities between
any two SS7 nodes; ..."

"MTP3 is adapted to the SCTP layer using the [M2PA] ..."

"The SS7 MTP3/MTP2 (MTP2-User) interface is retained in the IPSP.
The M2PA protocol layer is required to provide the equivalent set
of services to its user as provided by MTP Level 2 to MTP Level 3."

I think it is fairly clear from these statements and others that M2PA
must closely follow Q.703.  Otherwise the same "services" will not be
provided to MTP3 and the objectives of M2PA lost.

What procedures of Q.703 do you believe are not applicable to M2PA?

> >
> >This is the data portion of the DATA message.  The MSU if you will.  In
this
> >case, however, it is too short to be a valid MSU.
>
> I haven't studied the relevant specs, but should M2PA/MTP2 validate L3
payload
> length beyond a non-zero check?

There are no 1 byte MSUs in Q.703.  In Q.703 SIO+SIF of 1 byte is an LSSU.
M2PA does not send LSSUs in DATA.  Did you expecte M2PA to deliver 1-byte
messages to MTP3?  I don't know that MTP3 would be prepared to deal with
them because it never receives them from Q.703.

--brian

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

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Sep 2002 11:46:55 -0600

Jeffrey,

[email-masked] wrote:                                             (Thu, 19 Sep 2002 12:07:11)

<snip>
> I don't recall ever seeing it.

Sept 2, 2002  (two weeks ago) on the thread entitled:

	M2PA - Retreival State

Just after draft 6 was announced.  Attached for your convenience.

--brian

Date: Mon, 2 Sep 2002 04:03:42 -0600
From: "Brian F. G. Bidulock" <[email-masked]>
To: "May, Howard" <[email-masked]>
Cc: "'Ming Lin'" <[email-masked]>, [email-masked]
Subject: Re: [Sigtran] M2PA - Retrieval State

Howard,

I agree with Ming.  There is no difference between RETRIEVAL state and
OOS state.  Q.703 gets (and even MTP3b) along quite nicely without an
LSC RETRIEVAL state: both only use an Out of Service state.  For consistency
with MTP2/MTP3b the RETRIEVAL state needs to be removed.

M2PA/Figure 7 should be made to be consistent with Figure 2/Q.703. Figure
2/Q.703 has no RETRIEVAL state.  The only states listed in Q.703 overview
are:

        Figure 2/Q.703               M2PA/Figure 7
        ------------------           ------------------
        Power Off                    IDLE
        Out of Service               OOS
        Initial Alignment            AIP, PROVING
        Aligned Ready                ALIGNED READY
        In Service                   INS
        Processor Outage             --
        Aligned Not Ready            --
        --                           RETRIEVAL

It would be good if M2PA could at least conform to the Q.703 state machine
overview diagram (even if it falls short of the detailed SDLs).  Several
things should be done to M2PA/Figure 7 to accomplish this:  RETRIEVAL state
should be removed (MTP3 does not distinguish it from OOS state).  PROVING
state should be removed--well collapsed with AIP--(MTP3 does not distinguish
Proving from Initial Alignment), and two states need to be added to the
diagram which MTP3 is concerned about: PROCESSOR OUTAGE and ALIGNED NOT READY.
PROCESSOR OUTAGE state results from local processor outage condition
experienced in the INS state.  ALIGNED NOT READY state results from local
processor outage condition experienced in the ALIGNED READY state.  Thus, the
diagram should be updated as follows:

                    +-----------+                                       
                    |  POWER    |                                       
                    |   OFF     |                                       
                    +-----------+                                       
                          |                                             
                          | Power On                                    
                          |                                             
        Flush Buffers     |  +-------------------------+                
        OR Retreival      |  |                         |                
               +-------+  |  |                         |                
               |       |  V  V                         |                
               |    +-----------+                      |                
               +--->|  OUT OF   |                      |                
  +---------------->|  SERVICE  |<--+                  |                
  |                 +-----------+   | Link Configured  |                
  |                       |   |     | (Associate)      |                
  |                       |   +-----+                  |                
  |                       |                            |                
  |                       | MTP3 Start                 |                
  |                       V                            |                
  |                 +-----------+                      |                
  |                 |  INITIAL  |                      |                
  +<----------------| ALIGNMENT |--------------------->+                
  |      MTP3 Stop  +-----------+     SCTP Comm Error  |                
  |   OR T1 Expiry        |  |     OR SCTP Comm Lost   |                
  |   OR T4 Expiry        |  |                         |                
  |   OR Receive LS OOS   |  +-------------------------|---------+      
  |                       | Send and                   |         |      
  |                       |      Receive LS Alignment  |         |      
  |                       V                            |         |      
  |                 +-----------+        LPO/LPR       |   +-----------+
  |                 |  ALIGNED  |<---------------------|-->|  ALIGNED  |
  +<----------------|   READY   |--------------------->+   | NOT READY |
  |      MTP3 Stop  +-----------+     SCTP Comm Error      +-----------+
  |   OR T3 Expiry        |        OR SCTP Comm Lost             |      
  |   OR Receive LS OOS   |                                      |      
  |                       | Receive LS Ready                     |      
  |                       | OR Receive User Data                 |      
  |                       |                                      |      
  |                       V                                      V      
  |                 +-----------+        LPO/LPR           +-----------+
  |                 |    IN     |<------------------------>| PROCESSOR |
  |                 |  SERVICE  |                          |   OUTAGE  |
  |                 +-----------+                          +-----------+
  |                       |                                      |      
  |                       |    MTP3 Stop                         |      
  |                       | OR Receive LS OOS                    |      
  |                       | OR SCTP Comm Error                   |      
  |                       | OR SCTP Comm Lost                    |      
  |                       | OR T6 Expiry                         |      
  |                       | OR T7 Expiry                         |      
  |                       | OR M2PA Link Failure                 |      
  |                       |                                      |      
  +<----------------------+<-------------------------------------+      

             Figure 7: M2PA Link State Transition Diagram               

Text should be updated to be consistent with this diagram.

--brian

May, Howard wrote:                                                                    (Mon, 02 Sep 2002 09:46:20)
> Dear Ming
> 
> I think Issue 18, included in your email below, is resolved by Toms
> correction (well done with the ascii art work Tom!).  Ming could you post a
> summary of the other problems you see with the Retrieval state.
> 
> I currently believe the Retrieval state to be worthwhile.  As the link can
> only leave the Retrieval state after an event from MTP3 it guarantees that
> MTP3 will be able to perform and complete retrieval procedures before the
> link comes back into service.   If the Retrieval state is not used then I
> think we would be left in a situation where the link could come back into
> service before Retrieval had been completed.  There is then an issue of
> either allowing MTP3 and M2PA to fight over messages in the TX buffer (MTP3
> trying to Retrieve them and M2PA trying to transmit them - clearly
> undesirable) or perhaps when the link fails moving messages left in the Tx
> buffer to another buffer until MTP3 decides whether it wants them or not (My
> gut feeling is that this is where more problems lie rather than the use of
> the Retrieval state)
> 
> Cheers
> 
> > -----Original Message-----
> > From: Ming Lin [mailto:[email-masked]]
> > Sent: 01 September 2002 05:08
> > To: Tom George
> > Cc: [email-masked]
> > Subject: Re: [Sigtran] I-D ACTION:draft-ietf-sigtran-m2pa-06.txt
> > 
> > 
> > Dear Tom,
> > 
> > I think we should remove RETRIEVAL state, this state will 
> > result in many problem but no use,
> > for example the No. 18 issue.
> > 
> > "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.]"
> > 
> > ----- Original Message ----- 
> > From: "Tom George" <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Friday, August 30, 2002 11:30 PM
> > Subject: Re: [Sigtran] I-D ACTION:draft-ietf-sigtran-m2pa-06.txt
> > 
> > 
> > > 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. *