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

From: Tom George <[email-masked]>
Date: Fri, 03 May 2002 13:31:01 -0500

Franz,

Thanks for the interest in M2PA. Comments below.

tomG.

Gaiser Franz wrote:
  [...]
> 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)?

I think the solution that makes the most sense is for the OOS end to
mark that it received a Link Status Alignment from the other end. If he
receives a Start before the other end's T1 expires, he can send Link
Status Alignment and the alignment procedure begins. Otherwise, T1
expires and it starts over. 

I can add this to the M2PA draft.

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

I might be misunderstanding what you are saying here. But I think we do
not want one end to be able to unilaterally begin proving by sending
Link Status Proving. There can be quite a lot of these messages. I would
like for the 2 sides to exchange Link Status Alignment messages within
period T1 as a way of making sure that both ends are ready to start
proving.

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

OK. I will add that to the draft.

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

If the messages are received by M2PA and the upper layer can't take
them, then they are lost and gone forever. If they stay in the SCTP
queue, then they will also be in the sending end's M2PA buffer and could
be retransmitted if necessary.

This is a situation where we wanted M2PA to have the ability to stop
SCTP from continuing to receive messages. But it was not a part of the
SCTP RFC.

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

Yes, Link Status In Service.

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

I did not put in an M2PA "excessive delay of acknowledgment timer"
because I think SCTP handles the timing issues. At this point, I would
say it is an implementation issue when you send back an ack, except that
you have to meet SS7 standards. 

If M2PA sends a Data or Status message, it should include an ack for
whatever messages it has received. 

If M2PA at one end is not sending any other Data or Status messages,
then it would not seem to be a problem for it to ack every incoming
message.

> Thanks & regards,
> Franz

-- 
* Tom George          972-519-3168           [email-masked]   *
* PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *

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