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

From: [email-masked]
Date: Thu, 19 Sep 2002 09:43:36 -0400

Hello Brian,

My comments are embedded in the following...

Regards,

Jeff

"Brian F. G. Bidulock" <[email-masked]> on 09/18/2002 07:01:07 PM

Please respond to [email-masked]

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

>Please respond to [email-masked]
>To:  [email-masked]
>cc:
>Subject:   Re: Comments on draft-bidulock-sigtran-m2pa-test-02.ps
>
>
>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.
>

Yes. M2PA timer T1 should be changed to T2 to match Q.703.

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

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.

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

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)

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

I am referring to the test case description paragraph following
the section header: "...or a status 'Processor Outage' message...."

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

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

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

I agree, as described previously.

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

The M2PA draft should change to match this behavior -- that is,
reception of a LSPx during AIP causes a transition to PROVING.

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

The M2PA draft should change to match this behavior -- that is,
reception of a LSPx during AIP causes a transition to PROVING.

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

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.

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

I disagree. LPO does not mean that MTP3 is unavailable.
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.

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

If you say so.

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

We are in passionate agreement.

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

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)?

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

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)?

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

I haven't studied the relevant specs, but should M2PA/MTP2 validate L3 payload
length beyond a non-zero check?

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

Thanks.
I'm glad this exercise has found some of the interop issues with the current
version of M2PA.

>
>--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: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Sep 2002 08:47:00 -0600

Jeffrey,

More comments below...

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

<snip>
> Yes. M2PA timer T1 should be changed to T2 to match Q.703.

<snip>
> and stops at the transition to INS. T1 timeout causes transition

<snip>
> 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>
> the section header: "...or a status 'Processor Outage' message...."

But no LSPO is sent as part of the test.

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

> then transition to OUT_OF_SERVICE.
> 

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

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

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