Subject: Re: [Sigtran] (M2PA) Comments on M2PA v8

From: Tom George <[email-masked]>
Date: Tue, 06 May 2003 17:46:11 -0500

Jeff,

Comments below....

[email-masked] wrote:
> 
> Comments on M2PA v8
> 
> General:
> 
>     Overall M2PA v8 looks good.

Thanks!

> 
>     The draft should state which values are used for the initial
>     FSN and BSN (0, -1). The fact that the values are the same
>     as those used by MTP2 is fine, but this is a key
>     interoperability issue, and should be highlighted, especially
>     considering that previous draft revisions used different values.

I would not want to use the draft to highlight differences from a
previous version of the draft. 

> 
> Page 21:
>    "Acceptance of a message is indicated by a successful receipt
>     of the message from SCTP."
> 
>     What is the scope of this 'acceptance'? Is this acceptance from
>     SCTP or from the peer? Please clarify.
> 
>     If this 'acceptance ' is from the peer, then acceptance is
>     indicated by the sending to the peer of a M2PA user data message
>     having a BSN value equal to or greater than the FSN of the
>     received message.

I was not trying to say anything profound. MTP2 has an explanation of
what constitutes acceptance of a message (Q.703 clause 4). It is a
little complicated because it has to identify the flag, delete the
inserted zero bits, etc. Because M2PA has a message-oriented layer
underneath it (SCTP), none of this is relevant. M2PA has a message when
it gets it from SCTP.

> 
> Page 27:
>    "(c) M2PA SHOULD continue running the T7 timer for messages sent
>         before the local processor outage."
> 
>     Since link status messages are transported by a different stream
>     than the user data messages, it is possible for the LSPO to be
>     received by the peer prior to the last user data message. As soon
>     as the peer receives the LSPO, it moves the link to the
>     PROCESSOR_OUTAGE state and informs its MTP3 of the remote
>     processor condition. At that point the peer M2PA must not send
>     received user data messages to MTP3, and so it should not ACK
>     those messages.
> 
>     This is already stated in the following draft paragraph:
> 
>    "(a) Any User Data messages received from the peer after the Link
>         Status Processor Outage MUST NOT be acknowledged and MUST be
>         buffered."
> 
>     If timer T7 is maintained for those user data messages, then the
>     link will likely fail due to T7 expiry. This is not acceptable.
>     Timer T7 should be disabled for all user data messsages in the
>     retransmit queue upon onset of local processor outage.
> 
>     I therefore request that the above paragraph '(c)' either be struck
>     from the draft or replaced with:
> 
>     "(c) Upon the onset of local processor outage M2PA SHOULD disable
>          the T7 timer for all messages that have been sent but not
>          acknowledged."

I think you are right.

> 
> page 26, 4.1.4:
> 
>     "When the condition ends, M2PA SHALL send a Link Status Processor
>     Recovered message to its peer."
> 
>     Which MTP2 message does the M2PA 'Link Status Processor Recovered'
>     message replace? Please describe this in the draft.

There is no MTP2 message that exactly corresponds with LS PR. I guess I
would say it replaces the FISU that is sent at the end of MTP2 PO. But
MTP2 does not require a FISU. It can send an MSU. In that case, LS PR
does not replace anything. It is just sent before the first User Data
message.

> 
> page 27, 4.1.5:
>     "The Link Status Busy message replaces the SIB message of MTP2.
>     The message SHOULD NOT be transmitted continuously. M2PA SHALL
>     send a Link Status Busy message to its peer at the beginning of
>     a receive congestion condition where MTP2 would send SIB. M2PA
>     MAY send additional Link Status Processor Outage messages as long
>     as that condition persists. When the condition ends, M2PA SHALL
>     send a Link Status Busy Ended message to its peer."
> 
>     The second-to-last sentence in the preceding paragraph incorrectly
>     refers to Link Status Processor Outage messages.

Oops. I will make the change.

> 
> page 29, 4.2.1:
> 
>     "M2PA SHOULD ignore the FSN and BSN contained in a Link Status
>     message."
> 
>     This sentence contradicts Q.703 Figure 13, Sheet 7 of 7, which
>     indicates that the BSN of the M2PA LSPR should be used by the
>     recipient to set the initial FSN upon exiting remote processor
>     outage condition.
> 
>     M2PA differs from MTP2 in that both sides buffer user data
>     received during processor outage. This difference needs to be
>     explained in detail in the draft. Processing of the buffered
>     messages needs to be explained for the cases of both FLUSH and
>     RESUME. As it stands now, the draft contradicts Q.703 and
>     does not explain how the M2PA peers keep sequence numbers
>     synchronized when existing from the processor outage condition.

I think you are right here, too. I will need to think about this one.

> Regards,
> Jeff

-- 
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas 75075  *
* 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

---

From: Tom George <[email-masked]>
Date: Tue, 27 May 2003 17:26:06 -0500

Jeff,

IMHO the best way to write this is to delete (c) in 4.1.4 and let M2PA
follow MTP2's behavior. 

tomG.

> [email-masked] wrote:
  [...]
> >          the T7 timer for all messages that have been sent but not
  [...]

---

From: Tom George <[email-masked]>
Date: Fri, 30 May 2003 17:25:27 -0500

Here is how I think I should fix this: 

1. Delete the sentence in 4.2.1 
"M2PA SHOULD ignore the FSN and BSN contained in a Link Status message." 
There is no harm in using those fields, as long as they are used
appropriately. This will also fix the inconsistency David Lehmann
pointed out.

2. In 4.1.4, M2PA should resynchronize its sequence numbers after PO the
same way MTP2 does. In the case of Q.703 Figure 13 sheet 7, the BSNR
would come from the LS Processor Recovered message instead of the first
MSU/FISU as in MTP2.

3. The statement in 4.2.1 
"For message types other than User Data, the Forward Sequence Number is
set to the FSN of the last User Data message sent."
needs some qualification. After PO, it is set as in item 2 above.

3. "Flush buffers" is going to mean about the same in M2PA as it does in
MTP2. It will have to apply to both M2PA and SCTP buffers. 

4. "Continue" after PO will mean that M2PA starts receiving and
processing the messages that were buffered and not acknowledged during
PO. 

tomG.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 30 May 2003 21:29:48 -0600

Tom,

Sounds good to me.

--brian

Tom George wrote:                                                                      (Fri, 30 May 2003 17:25:27)

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