Subject: M3UA interoperability testing report

From: [email-masked]
Date: Wed, 5 Sep 2001 12:00:33 -0400

Hi,

Could someone please direct me to  find the report of the May M3UA
interoperability testing?

Thanks
Ray

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Maria-Carmen Belinchon <[email-masked]>
Date: Wed, 05 Sep 2001 18:14:08 +0200

Here it is,
br,
MCarmen

Subject: Final report from the Interop Test
Date: Fri, 11 May 2001 18:38:40 +0200 (MEST)
From: ecejoz <[email-masked]>
Reply-To: [email-masked]
To: "sigtran" <[email-masked]>

Hi all from Madrid!

This is the final report from the 1st M3UA Interop Test.

15 companies and 31 people have been involved, with 16 different
implementations.

The version 5 of the protocol was tested and the 30% of the
implementations can support the mandatory functionality of
version 6 of the protocol.

· The implementations were programed in the following languages:

C : 16 implementations
C++ : 3 implementations

· The following Operating Systems were used:

Linux :  12
Solaris : 6
Windows NT : 1

· And the type of computers used were:

Laptops : 23
Work Stations : 6
Portable PC : 2

· The test were grouped into four configurations.

Approximately 25 issues and comments were found and discussed
daily with Greg Sidebottom by conference call.

A list of open issues and questions made by all the participants
is attached.

As Test Coordinator, I would like to thank Heinz Prantner for
the good job he has done with this documentation.

Also, I would like to thank the Interop Coordination Team for
being such a good proffesional people and share their knwoledge
with all of us. For so, thanks Barry Nagelberg, Michael Tuexen,
Kurt Kite and Heinz Prantner.

I would like to thank Greg Sidebottom for attending us in a
such a kind way.

The first configuration was successfully tested by
77 of the 120 possible pairs of implementations.

The second configuration was successfully tested by
33 of the 120 possible pairs of implementations.

The third configuration was successfully tested by
39 of the 120 possible pairs of implementations .

The fourth configuration was successfully tested by
30 of the 120 possible pairs of implementations.

· The configurations were designed as follows:

CONFIGURATION 1: 1+0 -  1 SG - 1 ASP

1.1. Association establishment, started by the ASP
1.2 Connection establishment
1.3 Activation of traffic between the two nodes
1.4 Sending data: from ASP to SGP
1.5 Sending data: from ASP to SGP
1.6 Deactivation of the traffic between the nodes
1.7 ASP disconnection
1.8 Close association
--- New Proposals
1.9 Restart of the ASP

***********************

CONFIGURATION 2: 1+1 -  1 SG - 2 ASP in the same AS

2.1 Activation of the traffic
2.2 Over ride of the ASP
2.3 Over ride of the ASP with Stand By
2.3.1 Just as V5
2.3.2 (Optional !!) AS V6 way
2.4 Load share
2.5 ASPs disconnection

***********************

CONFIGURATION 3: 1+0 -  1 SG - 1 ASP serving to two different ASs

3.1 ASP_ACTIVE msg with more than one Routing Context
        The SG sends DATA msgs to the different ASs with its
        different Routing Context
3.2 ASP_INACTIVE with more than one Routing Contexxt
        The Data msg should be refused when the AS is inactive.

************************

CONFIGURATION 4:  -  1 SG - 2 ASP serving to two different ASs.

4.1 Testing the MTP-PAUSE primitives with the DUNA message.
4.2 Testing the MTP-RESUME primitives with the DAVA message.
4.3 Testing the MTP-STATUS primitives with the DUPU and SCON
        messages.

_________________________

Issues found and comments during the M3UA bakeoff

Last updated: HP, Thursday, 18:00 MEZ

Authors: Michael Tuexen
         Barry Nagelberg
         Heinz Prantner
         Jaime Olivares
         Kurt Kite

 Introduction:

   Issues found during the bake-off based on the m3ua draft version 5 will
   be collected here in case they are not covered by draft version 6. The
   issue list is updated once or twice a day based on the findings and after
   discussion by the bake-off participants. They then will be further discussed
   via phone conference with Greg Sidebottom and updated with his comments,
   statements. Each update will be made available to the bake-off participants
   on the local ftp server and - of course - to Greg via email.

 Issues:

 001   Notify message: the draft SHOULD specify the case where there is no
                       Routing Context specified in the notify message.
                       (similar to the wording at asp active)

       [Greg] will be covered by Version 7

 002   At receiption of the ASP-UP the SG updates the AS State to inactive.
       At least one implementation sends a Notify prior to ASP UP ACK, which
       is discarded in the ASP since the AS is in the down state until
       the receiption of the ASP UP ACK.

       [Greg] Version 7 will state something like "... MUST send Ack before
        Notify...."

 003   paragraph 4.3.3.6 says the Notify message ... is sent ... should be
       rephrased to MUST be sent or SHOULD be sent...

       [Greg] tends to 'SHOULD'

 004   some discussion started whether the ASP UP changes the AS state and of
       which one (which As). and then do we have to send NOTIFY  for all ASs
       ...?

       [Greg] needs to be distinguished between static configuration
         (preconfigured Application Server) and dynamic configuration
         (by Version 6 utilities like REG DEREG messages):

         - in static configuration you know the relation between AS ASP and
           the AS becomes inactive at the reception of the first ASP_UP
           message for that AS.

         - in dynamic configuration the ASP_UP comes before the REG so the
           SG does not know the relation. you wait for REG or ACTIVE message
           for state change of AS. Version 7 will cover further clarification.

         - potentialy new ERROR code needed for ASP ACT without RC in
           absence of static configuration....

 005   7.1 add text to clarify the usage of protocol identifier:

         the proposed M3UA id SHOULD be used or 0 for unspecified. Other values
         MUST not be used.

       [Greg] Ok.

 006  in case the sending of the NOTIFY message is mandatory, a procedure
      description, what to do in the ASP on receiption of the notify, would
      be applicable.

       [Greg] The Notify message was intended for Management Information
         (LM, System Management). Version 7 will state something like that.

TUESDAY

 007 ASP ACT without RC

     chapter 4.3.3.4 endof paragraph one states that the receiver must know
     which AS the ASP is member.. but it does not say that they have to be
     updated with new state information....

     [Greg] will add text for clarification, as well some description
      for ack before notify similar to asp_up

 008 DAUD DUNA DATA SCON ..

      Network Appearance Optional => misleading, its optional when the SG
      appears not more than in one network... otherwise mandatory
      (well, it is the ASP reporting for an AS which has only one
         network appearance)

      [Greg] .. will make addition to 3.3.1 (DATA), 3.4.1 (DUNA), 3.4.2
             (DAVA), 3.4.3 (DAUD), 3.4.4 (SCON), 3.4.5 (DUPU), 3.4.6
             (DRST) to specify that the attribute *optional* for the
             network apearance parameter only
             applies to "single networked" scenarios. in that case
             you may or may not have the param.

 009 zero length optional parameter

     parameter appears with tag and length only, where the length indicates
     header length only (zero length parameter value) ...
      that should be ok for info strings or diagnostics
     which are already defined to be length 0 to n bytes, so its not really
     an issue...

      [Greg] given the nature of TLVs, a parameter with length 4 should
            be acceptable.

 010 byte definition for protocol data

     During the phone conference this issue came up: The illustration
     of the byte definition for the routing labels (itu and ansi)
     are still subject for controversy. A decision has to be made
     whether the draft should contain the illustration of byte
     ordering for the payload data. In case the graphic remains
     it must made clear that it is for illustration purpose
     only and the implementor is not required to make any changes
     to the byte stream as it is defined in itu and ansi
     specifications. Furthermore, the itu point code format should be
     illustrated as 14 bit values without structures, since the
     q.704 does not specify any structure, and structures (which do
     exist outside Q.704) may vary.

WEDNESDAY

 011 ASP Maintenance Message with RC acknowledged without RC

      ASP ACTIVE sent with a RC can be acknowledged
      without having the optional RC in the ACK.

      [Greg] spec will clarify: ACK MUST have RC in ACK

 012 multiple occurance of same tlv

      nothing against it.

      [Greg] draft will clarify: .... MAY have duplicate params ....

       brings up another issue about contradictionary params...

 014 ASP1 is ACTIVE
     ASP2 is DOWN
     ASP2 sends UP
     The SG sends UP_ACK but no Notify since the AS did not change state

     by the way: not all comments are issues for the draft, but for the
     purpose of keeping track of history they are mentioned here.

 015 first ASP sends UP OVERIDE STB before ACT has announced himself
        ACK with ACTIVE OVERIDE

 016 SG receives DATA from STB ASP
     or SG receives DATA from INACTIVE ASP

     clarify draft

      do you have to check the state when receiving data ?

      option one: the Sg checks the ASP state on receiption of
                  each DATA message.

                  pro: detect "babbling idiot" (cite Brian Bidulock) as soon
                       as possible.

                  con: performance overhead due to routing table
                       lookups. Since there are not too many
                       AS's per ASP expected it should not be
                       too much of an overhead...

                  con: potentially additional mechanism needed for
                       apropriate reaction on fault detection.
                       one possibility could be the sending of
                       an Notify Active in response to the inactive
                       sender (who talks while sleeping).

      option two: the ASP does not check the ASP state on receiption
                  of data messages.

      [Greg] needs further investigation ...

 017 ACTIVE ASP receives NOTIFY (ALT_ASP_ACTIVE)

      Does this change the state of the ASP within the ASP?
      Yes, if overide, ASP changes state.

      [Greg] if not yet there, spec needs to specify this.
        ASP has to check the state with its neighbour ASP...

 018 ASP sends ASP_ACTIVE
     SG responds ACTIVE_ACK on Stream 0
     SG sends DATA on Stream 1
     assume DATA received before ACK
     DATA is lost because ASP is inactive

      [Greg] yes, message is lost
         make note about it in draft

 019 follow up question to issue 004:

     in case there is no preconfiguration:

     ASP1 sends ASP UP (we dont know which As belongs to)
     ASP1 sends REG
     ASP2 sends ASP UP (ditto)
     ASP1 sends ACTIVE
     we cannot send Notify to ASP2 since we dont know....

     [Greg] proposals for issue 4 should cover that

 020 two ASP in loadshare mode

     (1) one ASP goes down, the AS remains active with one ASP only
     (2) the AS is up as soon as one ASP is Active

     both rules, scenarios have been questioned

     or, what is the difference between 2+2 and 3+1 (n+k)

 021 Error Response and Acknowledgement

     It occured that some implementations (at least one) did send an error
message
     in response to a state maintenance message AND an acknowledgement
     after the error. does not seem right.

     Relation between any msg and an error response is given by
     optional diagnostic info only.
     Perhaps we may need mandatory diagnostic infos in some cases.

     has been discussed already on the mailing list...

     how about negative acks

THURSDAY

 022 receiption of ASP_ACTIVE without having configuration information

        neither static configuration nor REG has been received
        at receiption of ASP_ACTIVE

     [Greg] needs clarification, oob asp active
        asp active pragraph update. discard message
        in that case.

 023 "AS Restart"

       In case one AS loses connectivity with the SGP(s) some
       guidelines similar to mtp restart what to do would be
       appreciated. E.g. Should the ASPs hold back the ACTIVE message
       and request the DPC states via AUDIT before going active?

       proposals with pros cons

       Correlate MTP Restart in SG with above (1.4.3.2)

 024 DAUD message from the SG to the ASP in case it received an SCON from ASP

      Since the SCON can be sent from the ASP to the SG it should be
      allowed to query the congestion state by the SG to the ASP.

     [Greg] Check for usefulness

 025 4.3.3.1 (Version 6) last two paragraphs:

     The handling of an unexpected ASP-Up message, described in these
     paragraphs, does not explain the desired behavior, in case the
     ASP represents more than one AS, and the ASP states are different,
     e.g. AS1 is active, AS2 is inactive.

 026 3.4.4 sending SCON message from ASP to SG indicating M3UA or ASP
        congestion.

     The proposal for sending a SCON message from the ASP to the
     SG for indicating M3UA or ASP congestion seems fragile. The
     SCON, similar to the MTP message TFC, indicates congestion
     towards an AS. Detection of congestion towards the AS
     should lead to an traffic reduction at the originators.
     Traffic towards the AS should be responded with TFCs. The
     effective way to ease the load for the ASP seems to be
     the closing of the receiver window in sctp (on upper
     layer request), which should lead to an congestion
     indication on the other side (the SG) from sctp to
     the upper layer. The SG, receiving traffic destined to
     the congested assoc, should respond appropriatly to
     the originator.

     The only case, where the SCON sent by the ASP seems
     applicable, is when the AS is geographically seperated
     from the ASP and the ASP detects overload towards the
     AS. In any case, I would propose to relate the
     SCON to the AS (RC) rather than DPC.

     Just a thought, has not been discussed at the
     bakoff yet.

 027 Audit Destination (the SG) from the ASP

     Is it possible to audit the dpc of the SG from
     the ASP (without having the ASP knowing whether it is the
       SG behind this Point Code )

Best Regards

 /Interop Coordination Team

        - Barry Nagelberg
        - Kurt Kite
        - Jaime Olivares
        - Heinz Prantner
        - Michael Tuexen

[email-masked] wrote:

> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]
---