Subject: [Sigtran] M2PA-04: little,private M2PA plugtest held - queries

From: Gaiser Franz <[email-masked]>
Date: Tue, 16 Apr 2002 13:50:00 +0200

Hi,

on Thursday April 11 and Friday April 12 a "little, private" M2PA plugtest 
was held between Radisys and Siemens at the Siemens facilities in Munich, 
Germany. M2PA version 4 was tested based on a modified test plan from the 
Dallas plugtest. Besides testing we discussed draft issues based on 
analysis made by Siemens prior to the testing. Questions and concerns to 
the authors are summarized in the following.

participants:
Franz Gaiser - Siemens
Roland Lueckert - Siemens
Vildana Mahmutovic - Siemens
Michael Tuexen (part) - Siemens
Heinz Prantner - Radisys

questions/concerns:

- Alignment (4.1.3):
The association is established. How about the situation when the peer sends the Link Status Alignment message and the local M2PA is in state OOS and has not yet received the Start Link command from MTP3. It is not clear in the draft  what does the local M2PA do with messages received in State OOS (store it or discard it)?
If the link Status alignment message is discarded, timer T1 will expire in the local M2PA because it has not both received and sent the link Status Alignment message as described in the draft and the alignment is stopped.
In a strict interpretation of the current draft a received LS Alignment message, where the local mtp3 did not start the link yet, would bypass the State Event Machine. We propose to handle the most likely case that the link activation will happen asynchronously that the first received Link Status Proving message is used to make a transition from state AIP to state Proving at the right site:

	Message Flow:

    MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
    ----        ----        ----        ----        ----        ----
                [OOS]                               [OOS]
        Start
       --------->
                [AIP]
                Start timer T1
                Send Link Status Alignment
                 ------------------------------------>
                                                      
                                       .
                                       .
                                       .
                                       .
                                                         Start
                                                       <---------
                                                    [AIP]
                                           Start timer T1
                                    Link Status Alignment
                 <------------------------------------
               [PROVING]
               Stop timer T1
               Start timer T2
                
                 Link Status Proving                  
                 ------------------------------------>
                                                [PROVING]
                                            Stop timer T1
                                           Start timer T2
                                                         
                                   Link Status Proving
                 <------------------------------------
                 ------------------------------------>
                 <------------------------------------

- Level 2 Flow Control (4.1.5 paragraph 5: When the peer M2PA receives the Link  Status Busy message ...):
If timer T6 expires, we are missing in the draft  that M2PA should inform the peer side by sending a Link Status Out Of Service message and that locally transition is made to state RETRIEVAL.

- Processor Outage (4.1.4):
In the situation when M2PA detects a local Processor Outage, in draft 04 it is new that M2PA shall stopp receiving incoming messages from SCTP. Could somebody explain why this sentence was added ?

- Sending/receiving messages (4.2.1):
Which message should be used to acknowledge an FSN when there is no outgoing data to send (Link Status In Service or Link Status Ready) ? We assume, that the Link Status In Service message is used. 
Also the handling of the acknowledgements is not clear. Should M2PA send an acknowledgement for each message (not useful), or should M2PA  send the acknowledgements window based (using a window  defined by a number of received messages before sending the acknowledgement or timer-based) ? 
As the size of the window at the peer has impact to the queue size at the sender the window size could be negogiated e.g. during alignment. 

Thanks & regards,
Franz

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