Subject: RE: [Sigtran] (M2PA) Comments on M2PA v8 - Last Call

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 24 Apr 2003 11:48:12 -0700

Hi Folks,

Since the comments are starting to roll in, let's consider
this a 2nd Last Call for M2PA, based on v8 now available.
Last Call will then close on Wednesday, May 7th.

Cheers,

L. Ong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, April 24, 2003 8:49 AM
To: [email-masked]
Subject: [Sigtran] (M2PA) Comments on M2PA v8

Comments on M2PA v8

General:

    Overall M2PA v8 looks good.

    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.

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.

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

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.

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.

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.

Regards,

Jeff

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