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

From: [email-masked]
Date: Thu, 19 Sep 2002 13:41:25 -0400

Correction to the last comment: forgot LI octet.

Jeff
---------------------- Forwarded by Jeffrey Craig/Raleigh/TEKELEC on
09/19/2002 01:42 PM ---------------------------

Jeffrey Craig
09/19/2002 12:07 PM

To:    [email-masked]
cc:    [email-masked]

Subject:    Re: Comments on draft-bidulock-sigtran-m2pa-test-02.ps
       (Document link: Jeffrey Craig)

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 + li + m2pa_header = 2+1+1+16 = 20) 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:56:33 -0600

Jeffrey,

If you look at Figure 11/Q.703 (sheet 2 of 2) or Figure 11/T1.111.3 you will
see that the number of bits received (between flags) at the DAEDR must fall
between the limits proscribed by: N x 8 (5 <= N < m + 7)  Otherwise, the
SU is considered in error (pegged by the SUERM or AERM) and discarded.

5 octets is the minimum size of an SS7 SU (FISU including CRC) between
flags.  Why would M2PA act any differently?  An MSU in a DATA message with
less than 3 bytes is an error.

--brian

[email-masked] wrote:                     (Thu, 19 Sep 2002 13:41:25)

> > > >
> > > >This is the data portion of the DATA message.  The MSU if you will.  In this
> > > I haven't studied the relevant specs, but should M2PA/MTP2 validate L3 payload