Subject: [Sigtran] M2PA testing at Plugtest

From: Richard Knowles <[email-masked]>
Date: Fri, 11 Oct 2002 12:05:46 -0700 (PDT)

Sigtran Plugtest Participants,

We have some questions concerning draft-bidulock-sigtran-m2pa-test.02
and its use at the Plugtest.  We are concerned that this proposed
test draft contains important exceptions from version 6 of the M2PA draft.
They are:

1.  In the change history (section 1.1.1) items 3. and 4. says it
    anticipates the future draft 7 with regard to DATA-ACK without
    incrementing FSN and STATUS ignoring FSN & BSN.  Are we agreeing on
    this?
2.  Section 3.1.2 mentions a T2 timer, but page 21 of draft 6 describes
    the Alignment Process and T2 is not defined or discussed.  T2 is a
    good idea but it is not currently defined in draft 6.  Are we missing
    something on this?
3.  There are many test cases that require a specially instrumented test
    tool to create errorneous and exceptional test scenarios.  What is the
    strategy for executing these test cases?  Will such a testbed be
    available in the plugtest?

Thank you.
-- 

Richard Knowles
Javier Kim
Adax, Inc. 614 Bancroft Way
Berkeley, CA 94710

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 11 Oct 2002 15:57:33 -0600

Richard,

Richard Knowles wrote:                          (Fri, 11 Oct 2002 12:05:46)
>     incrementing FSN and STATUS ignoring FSN & BSN.  Are we agreeing on

It is logically impossible to both increment FSN on LS and ignore them at the
same time.  Draft6 says:

"M2PA should ignore the FSN and BSN contained in a Link Status message."

But, if the peer is incrementing FSN when sending LS, how is the receiver to
ignore them?  It must track the FSN if it is incremented by the peer.

As well, LS would have to be acked if the FSN is incremented.  I don't think
that "acking" an LS is "ignoring" the FSN and BSN.

This is an inconsistency in Draft6.  Probably the best way to handle this for
the testing would be to not increment FSN on LS and truly ignore the FSN and
BSN in LS.

>     good idea but it is not currently defined in draft 6.  Are we missing

In Draft6, timer T2 is mis-named timer T1.  You will also find in Draft6 that
timer T1 is mis-named timer T3.

We agreed some time ago to align M2PA timer names with MTP2 timer names,
however, this inconsistency should be corrected in the next draft.

Just s/\<T1\>/T2/g and s/\<T3\>/T1/g

It is actually timer T3 in the test spec (and MTP2) that has no equivalent yet
in M2PA.  T3 is the maximum time that M2PA will wait after sending LS emergency
or normal proving for an LS emergency or normal proving from the peer before
it fails the link.  It is an essential timer in MTP2 as it ensures that T4 is
not started too early (particularly when emergency proving).

>     available in the plugtest?

The test program that I use merely sends M2PA messages directly to SCTP from
a user-space program to effect the tests.  You can find the Draft4 test-00
version of a loopback test program here:

           http://www.openss7.org/strss7/test/test-m2pa.c

This program is based on STREAMS version of SCTP and M2PA, but could be
adapted fairly easily to sockets approaches (it uses a poll loop anyway).  I
believe it could even be adapted in short order for user space SCTP and M2PA
implementations.

Unfortunately, the test program is not GPL, but OpenSS7 Corporation will offer
free license to use or modify and use this test program in the upcoming ETSI
plugtest.

I will bring a version of this program with me that will be able to generate
the PT side of the test cases.

--brian

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