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

From: [email-masked]
Date: Thu, 19 Sep 2002 08:00:06 -0400

(I originally e-mailed Brian Bidulock directly, and he responded directly).

Jeffrey,

It would probably be worthwhile to discuss these on the WG list.
Please feel free to post responses on the SIGTRAN list where
applicable.

Following are some comments...

On Wed, 18 Sep 2002, [email-masked] wrote:

> Comments on draft-bidulock-sigtran-m2pa-test-02.ps
>
> General Comments
>
>     Thank you for making a M2PA test plan available. Your test cases
>     provide very good coverage and are clear and concise. My comments
>     and questions are intended to improve my understanding and as
>     constructive criticism.
>
>     In my opinion, it would improve clarity to describe M2PA states,
>     link status messages, and timers, rather than Q.781 states,
>     messages, and timers. In some cases, the names have changed
>     to protect the innocent.

Yes, I just didn't want to go through all the finger work.

>
>     In the following, where I say 'not a M2PA requirement' -- maybe
>     it SHOULD be listed in the draft as a requirement, but currently
>     it is not.
>
> 3.1.2 Timer T2
>
>     This is M2PA timer T1.

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.

>
> 3.1.3 Timer T3
>
>     Description paragraph appears incorrect. What is the difference
>     between this test case and 3.1.4? How does this test case
>     apply to M2PA?

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.

>
> 3.1.4 Timer T1 & Timer T4 (Normal)
>
>     This involves M2PA timers T3 and T4.

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.

>
>     The description paragraph does not match the M2PA draft in
>     that the ALIGNED READY state is exited based on received LSR
>     or received DATA, not a received LSPO. The draft does not
>     specify that LSPO is an exit event for ALIGNED READY. This
>     is a recurring theme in the following PO test cases.

Huh??

3.1.4 does not have LSPO.

>
> 3.1.7
> Figure 3.1.7-1 "Alignment" during normal proving
>
>     This figure does not match the test description: LSA should
>     be sent after IUT sends LSPN. This test case does not match
>     a M2PA requirement (draft does not mention proving restart).

Yes, I'll fix that.

>
> 3.1.8.1
> Figure 3.1.8-1. Normal alignment with PO set.
>
>     Can IUT issue a LSPO before or during proving?
>
>     Why doesn't this figure show the IUT sending a LSR to PT?

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.

>
> 3.1.8.2
> Figure 3.1.8-2. Normal alignment with PO set.
>
>     Why doesn't this figure show the PT sending a LSR to IUT?

Same thing the other way around.

>
> 3.1.9.1
> Figure 3.1.9-1. Normal alignment with PO set (Data).
>
>     Isn't this a fault-insertion test case, since DATA is sent
>     prior to receiving either LSR or DATA?
>
>     Can IUT issue a LSPO before or during proving?
>
>     Why doesn't this figure show IUT sending a LSR to PT?
>
>     Which state is IUT in when it receives DATA?

Again, LSPO is used instead of LSR.  On the PT side, DATA
is used instead of LSR.  Consider that even if the PT sends
LSR, that because it is sent on stream "0", DATA may arrive
before the LSR.  Because of this, DATA must be accepted as
an LSR and the state of the link on receipt of DATA is
normaly in-service (but in this case LPO).

>
> 3.1.9.2
> Figure 3.1.9-2 Normal alignment with PO set (Data).
>
>     Isn't this a fault-insertion test case, since DATA is sent
>     prior to receiving either LSR or DATA?

Same thing in opposite direction.

>
>
> 3.1.12.2
> Figure 3.1.12-2 "Out of Service" when "Aligned not ready"
>
>     Typo: looks like there is an extra ':start'.

Typo.  I'll fix it.

>
>     Why does PT send a READY when it is LPO?

I suppose it should be LPO.

>
> 3.1.13
> Figure 3.1.13-1 "Alignment" when "Aligned not ready"
>
>     Which state is IUT in when it receives the second ALIGNMENT?

ALIGNED-NOT-READY

>
>     The transition shown does not match a M2PA requirement. LSA
>     received in ALIGNED-READY does not cause transition to OOS.

I submitted a diagram.  M2PA needs an ALIGNED-NOT-READY state to
accomodate LPO.

>
> 3.1.16
>
>     This is not M2PA timer T1. M2PA has no equivalent to the timer
>     described.

Again, M2PA timers are to tbe aligned with Q.703 timers.

>
> 3.1.17
>
>     This test case is incorrect. M2PA proving does not start until
>     a LSA is received by IUT. M2PA Timer T1 should time-out in this
>     test case.

I believe, as with Q.781 proving is sufficient indication of alignment.

>
> 3.1.19
>
>     This test case is incorrect: PT should send PROVING-NORMAL.

I will fix that.

>
> 3.1.21
>
>     Figure does not match test case. Both sides should set emergency.

I will fix that.

>
> 3.1.24
>
>     This test case is incorrect: IUT M2PA timer T1 should timeout due
>     to no LSA received. Also, PT should send PROVING-NORMAL unless
>     ':set emergency'.
>

I believe, as with Q.781 proving is sufficient indication of alignment.

> 3.1.28
>
>     This test case does not match a M2PA requirement. Receipt of LSA
>     during INS does not cause a transition to RETRIEVAL or any other
>     state.

But it should not be ignored nevertheless.  LSA is sufficient indication
that the peer M2PA has restarted.

>
> 3.1.30.2
> Figure 3.1.30-2. Deactivation during LPO
>
>     Why is '!rpo' shown occuring after LSO is sent? This suggests that
>     the LSO is acted upon prior to the LSPO.

Stupid IUT-T Q.703 SDLs...

>
> 3.1.31.2
> Figure 3.1.31-2 Deactivation during RPO
>
>     This test case does not match a M2PA requirement. Upon receiving
>     a LSO, regardless of LPO, the link transitions to RETRIEVAL.

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?

>
> 3.1.32.2
> Figure 3.1.32-2 Deactivation during the proving period
>
>     The diagram does not match the test steps. Why does IUT send a LSO
>     after receiving ':start'? If the association was not available when
>     ':start' was received, then ':out of service' should have been
>     generated after the ':start'.

You must understand that :start is issued at the interface to MTP3
yet, OUT-OF-SERVICE is observed on the line (by the PT).  The timing
of these two events are independent.  I could reverse them in the
diagram for readibility, but this is how they were actually observed
by the test script.

>
> 3.1.33
>
>     This test case does not match a M2PA requirement. Receipt of LSA
>     during ALIGNED-READY does not cause a transition to RETRIEVAL or
>     any other state.

But must.  M2PA needs to be corrected.

>
> 3.2.2
>
>     M2PA does not require that LSPO be ignored during AIP. The state
>     can be recorded and acted upon later.

If M2PA does not ignore this sequence of events, it will behave in a
manner different from Q.703 and unexpected by L3.

>
> 3.2.3
>
>     M2PA does not require that LSPO be ignored during PROVING. The state
>     can be recorded and acted upon later.
>
>     Received LSR during PROVING is not really ignored, though no state
>     transition occurs until T4 timeout (PROVING --> INS).

If M2PA does not ignore this sequence of events, it will behave in a
manner different from Q.703 and unexpected by L3.

>
> 3.2.4
>
>     How does this test case differ from 3.2.3?

One is supposed to be "Aligned" state and the other "Proving".

>
> 3.2.6
> Figure 3.2.6-1. Unexpected events while "aligned not ready".
>
>     Why does IUT never issue a LSR? Where in the M2PA draft does it say
>     that no LSR is generated if LPO is in effect?

Comments above on LSPO instead of LSR apply.

>
> 3.3.2
>
>     Why are ACKs received in ALIGNED-READY state?
>     Shouldn't IUT move to the INS state after receiving the first ACK
>     (User Data)?

These acks are invalid.  The description should say that the test case
starts in the Aligned Ready state.

>
> 3.5.3
>
>     What is meant by 'payload'? Does the payload include the M2PA header?
>     Should step three say that a M2PA User Data message having a length
>     less than or equal to the size of the M2PA header should not be
ACK'd?

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.

>
> 3.10.2
>
>     Why does PT send LSB? Figure seems to show ACK after T7 expiry.

Because it is congested.  Perhaps you would like to see a :make cong
discard?
Yes, the message is acked, but only after it is sure that the ITU's T7
would
have expired it it were running.

Good comments.

--brian

> Regards,
> Jeff

--
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: [email-masked]
Date: Thu, 19 Sep 2002 17:07:03 -0400

Hello Brian,

Taking into account some of the Q.703 issues we've been discussing,
the state transition diagram needs the following changes:

1) T1 expiry needs to become T2 expiry.
   (timeout waiting for LSA)

2) T4 expiry needs to become T3 expiry
   (new timer for M2PA, timeout waiting on LSPx).

3) T3 expiry needs to become T1 expiry
   (Timeout waiting for LSR needs to change to match Q.703 T1.
    The recommended time values also needs to change. T1 is started
    upon INITIAL_ALIGNMENT and is stopped on entry to IN_SERVICE
    or PROCESSOR_OUTAGE)

4) Need a transition arrow from ALIGNED_NOT_READY to OUT_OF_SERVICE
   upon 'SCTP Comm Error' or 'SCTP Comm Lost' or 'LS Out of Service'
   or 'LS Alignment'.

5) Arrows between INITIAL_ALIGNMENT and ALIGNED_READY and between
   INITIAL_ALIGNMENT and ALIGNED_NOT_READY need to have events
   changed to 'Send and Receive LS Alignment and T4 expiry'.

6) 'LS Alignment', 'LS Proving' events need to be added to the transition
   arrows from IN_SERVICE and PROCESSOR_OUTAGE to OUT_OF_SERVICE.

Regards,

Jeff

"Brian F. G. Bidulock" <[email-masked]>@ietf.org on 09/19/2002
01:46:55 PM

Please respond to [email-masked]

Sent by:    [email-masked]

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

Jeffrey,

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

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

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

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

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