Subject: [Sigtran] WG Last Call on M2PA

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 2 Jul 2003 10:21:28 -0700

Hi Folks,

Now that the updated M2PA spec is out, let's do a WG Last Call on the
spec and see if we can approve it out of the WG.

Please have a look at http://ietf.org/internet-drafts/draft-ietf-sigtran-m2pa-09.txt
and bring any comments to the list, with the Subject of the email set to
"M2PA Last Call Comment".

Last Call will run to Wednesday, July 16th.

Cheers,

L. Ong

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 11 Jul 2003 22:41:30 -0600

I have been updating the M2PA-TEST spec and have noticed a few things in
M2PA-09...

M2PA-09 Says: (top of Page 27):

  The Link Status Ready message replaces the FISU of MTP2 that is sent
  at the end of the proving period. The Link Status Ready message is
  used to verify that both ends have completed proving. When M2PA starts
  timer T1, it SHALL send a Link Status Ready message to its peer in the
  case where MTP2 would send a FISU after proving is complete. M2PA MAY
  send additional Link Status Ready messages while timer T1 is running.

This is all that is mention on T1.

In MTP2 T1 is started when the state machine enters the "Aligned Ready"
or "Aligned Not Ready" state.  Only from the "Aligned Ready" state does
MTP2 send FISU.  From "Aligned Not Ready" state, it sends SIPO.  Also,
if data is pending transmission, MTP2 can enter the "Aligned Ready" state
by sending an MSU rather than a FISU.

The problem is that M2PA-09 says "When M2PA starts timer T1, it SHALL send
a Link Status message...", when in fact if M2PA follows Q.703 could start
T1 and send a DATA message, or could start T1 and send a PROCESSOR-OUTAGE
message.

Perhaps we could say:

  The Link Status Ready message replaces the FISU, the Data message replaces
  the MSU, and the Link Status Processor Outage message replaces the SIPO,
  that would be sent at the end of the proving period.  The Link Status Ready
  Data or Link Status Processor Outage message is used to verify that both
  ends have completed proving.  Whem M2PA starts timer T1, it SHALL send a
  Link Status Ready, Data or Link Status Processor Outage message to is peer
  in the case where MTP2 would send a FISU, MSU or SIPO ater proving is
  complete.  M2PA MAY send additional Link Status Ready, Data or Link Status
  Processor Outage messages while timer T1 is running.

Ok?

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 11 Jul 2003 23:03:37 -0600

The proving period MAY be omitted if this is allowed by the applicable
  MTP2 standard (e. g., [Q.2210]).

The reference should be Q.2140.

It should also be noted that the same approach MUST be followed on both sides
the link.  Otherwise, one side following Q.703 will have T3 timer expire
waiting for PROVING-NORMAL from the side foregoing proving.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 12 Jul 2003 00:29:21 -0600

M2PA-09 says:

> M2PA SHALL continue transmitting and acknowledging messages while it
> is in receive congestion.

Q.703 says:

| The receiving level 2 also withholds acknowledgement of the message signal
| unit, which triggered off the congestion detection, and of message signal
| units received during the congestion situation; that is fill-in signal units
| or message signal units are sent as usual, but with the backward sequence
| number and backwards indicator bit assigned the values which are contained
| in the last transmitted signal unit before the congestion is recognized.

It is rather important that the busy end not acknowledge messages while it is
in receive congestion.  This is because if the receive congestion results in
link failure, acknowledged messages caught at the congested receiver will be
unavailable for retransmission on an alternate link at the transmitter.

Also, delivering these messages to MTP3 late will aggravate missequencing of
these delayed messages with subsequent messages transmitted on the alternate
link after changeover.

Change M2PA to say:

< M2PA SHALL continue transmitting message while it is in receive congestion
< but MUST NOT acknowledge the message that triggered sending of the Link
< Status Busy message, nor any messages received before the sending of Link
< Status Busy Ended.

M2PA-09 says:

> When the peer M2PA receives the first Link Status Busy message, it
> SHALL start the Remote Congestion timer T6. Additional Link Status
> Busy messages received while T6 is running do not cause T6 to be
> reset.

Q.703 says:

| At the remote end of the signalling link, every reception of a link status
| singal unit containing indication "B" causes the excessive delay of
| acknolwedgement timer T7 to be restarted, if the timer is already running.
| In addition first reception of the link status signal unit containing a
| status indication "B" starts a longer supervision timer T7 (see 12.3) only
| if there are message signal units in the retransmission buffer.  Should
| timer T6 expire, link failure indication is generated.

Change M2PA to say:

< When the peer M2PA receives the first Link Status Busy message, it SHALL
< start the Remote Congestion timer T6 if there are messages in the
< retransmission buffer awaiting acknowledgement (i.e, T7 is running).
< In addition, M2PA will stop the T7 timer if it is running.  Additional Link
< Status Busy messages received while T6 is running do not cause T6 to be
< reset and do not cause T7 to be started.  Also, while T6 is running, T7
< SHALL NOT be started.

< When the peer M2PA receives the Link Status Busy Ended message and T6
< has not expired, it SHALL stop T6 if T6 is running and start T7 if there are
< messages awaiting acknowledgement in the retransmission buffer.

Now, I know that we said that Link Status messages are not used to acknowledge
DATA messages, but it makes sense to permit the Link Status Busy Ended message
to acknowledge outstanding User Data messages, so that upon its receipt, T7
might not need to be started if all messages in the retransmission buffer are
acknolwedged by the Link Status Busy Ended message.

The above also kind of changes the idea of T7 metering the oldest message in
the retransmission buffer.  It would now measure the oldest message in the
retransmission buffer since the receipt of the last Link Status Busy Ended.

M2PA-09 says:

> The peer M2PA SHOULD continue transmitting and acknowledging messages
> while its T6 timer is running, i.e., while the other end is Busy.

But T6 is not necessarily running during the busy condition.

Change M2PA to say:

< The peer M2PA SHOULD continue transmitting and acknowledging messages
< while the other end is Busy: i.e, between receiving Link Status Busy
< and Link Status Busy Ended.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 12 Jul 2003 17:07:44 -0600

M2PA-09 says:

 While there is a remote processor outage condition:

   (a) Any User Data messages received from the peer after the Link
       Status Processor Outage MUST NOT be acknowledged and MUST be
       buffered.

   (b) M2PA SHOULD continue to acknowledge User Data messages received
       and accepted by MTP3 before the remote processor outage.

In Q.703 the side experiencing PO cannot send MSUs or FISUs without indicating a
recovery from processor outage.  M2PA can send User Data without indicating
processor recovery.  There is no reason for the receiver of User Data not to
process it even after receiving Link Status Processor Outage.

Otherwise, if (a) above is followed, MSUs in the transmission and retransmission
buffers at the time that local processor outage occured will be trapped.  If
User Data is acknowledged by the peer, they will be processed by the receiver.

Change M2PA to say:

 While there is a remote processour outage condition:

   (a) M2PA SHOULD continue to acknowledge User Data messages received
       and accepted by MTP3 regardless of the remote processor outage.

This allows the TB/RTB on the side experiencing processor outage to drain.

M2PA-09 says:

  Note that because the Link Status and User Data messages are sent on
  separate streams, it is possible for a User Data message sent after
  the Link Status Processor Recovered message to arrive before
  it. Therefore, when flushing buffers, M2PA must take care not to flush
  messages sent after the remote processor recovered. M2PA SHOULD NOT
  flush User Data messages with FSN greater than the FSN in the Link
  Status Processor Recovered message. 

MTP3 does not flush the RB after RPO or before RPR (just the RTB), unless it
uses the remote processor outage to local processor outage latching option, and
then it is only because of the LPO condition not the RPO condition.

With the change above, M2PA receives and acknowledges User Data before, during
and after remote processor outage, and comparison to any sequence numbers in the
Link Status Processor Recovered is unnecessary.

M2PA-09 says:

  When the local processor outage condition ends, M2PA SHALL send a Link
  Status Processor Recovered message to its peer. This message is used
  to signal in the end of the processor outage condition, instead of an
  MSU or FISU as in MTP2. The BSN value in this message is used by the
  peer to resynchronize its sequence numbers, if this is required by
  MTP2.

After a flush buffers operation, the side that experienced PO uses the first
received FISU/MSU to resync and discards the FISU/MSU.

ANSI T1.111.3/2000 Section 8 says:

  ... If level 3 requests level 2 [at the side experiencing processor outage] to
  clear its buffers of message signal units, level 2 begins to continuously
  transmit fill-in signal units and discards all message signal units that it
  has received from remote level 2 but not yet delivered to local level 3 and
  all message signal units that it has received from local level 3 but not yet
  transmitted on the link.  The first fill-in signal unit transmitted
  acknowledges all message signal units that have been accepted from remote
  level 2 including any mesage signal units for which acknowledgements were
  previously withheld because of level 2 congestion (see section 9).  Level 2
  then begins accepting message signal units from remote Level 2. When the next
  fill-in or message signal unit is received that passes the acceptance
  procedure of section 4 and sections 5 or 6,

   (1) all message signal units that are available for retransmission are
       discarded [clear RTB].

   (2) the forward sequence number and forward indicator bit of the
       transmitted fill-in signal units are set equal to the backward sequence
       number and backward indicator bit of the received signal unit,

   (3) normal transmission of message signal units and fill-in signal units is
       resumed, and

   (4) level 3 is notified that the buffer clearing has been completed and
       that normal operations has been resumed.

So, you see, the side experiencing the processor outage, after clearing buffers,
resynchronizes its FSN with the BSN of the first received FISU or MSU.  The side
experiencing processor outage could use the first User Data message received
after processor recovery to resyncronize.  However, if the peer has nothing to
send, processor recovery will be delayed.

Note, however, that resynchronization of sequence numbers for the transmit
direction is necessary because MTP2 traps messages in the TB/RTB of the side
experiencing processor outage because it must continuously transmit SIPO during
processor outage.  Permitting the draining of the TB/RTB with the change above
removes the need to flush the TB/RTB on the side experiencing processor outage,
as well as removing the need to resynchronize sequence numbers.

In the other direction, for messages queued to be sent to the side experiencing
processour outage, flushing and resynchronization is still necessary (actions
(1) to (4) per ANSI above).

However, Q.703 permits FISUs/MSUs received by the side experiencing remote
processor outage to discard the first and several subsequent FISU/MSUs when
recovering.  There is even a test case in Q.781 (8.9) that shows an MSU being
discarded (and negative acknowledged) in this fashion.  Because M2PA cannot
discard and expect retransmission of a message, and because sychronization is
not required when the TB/RTB of the side experiencing processor outage is
permitted to drain with the changes above, M2PA cannot permit messages to be
discarded in this fashion.

M2PA-09 says:

  If M2PA receives a Flush command from MTP3, M2PA SHALL discard the
  incoming messages that were queued and unacknowledged during the
  processor outage condition. Furthermore, M2PA SHALL discard messages
  in the transmit and retransmit queues as required by MTP2. 

To handle flushing and resynchronization properly in both directions, change the
above to read as follows:

Change M2PA to say:

  If M2PA receives a Flush command from MTP3, M2PA SHALL discard the
  incoming messages that were queued and unacknowledged during the
  processor outage condition.  Furthermore, the M2PA experiencing
  processor outage SHALL NOT discard message from the transmit and
  retransmit queues and SHALL NOT perform procedures to resynchronize
  sequence numbers, but SHALL continue normal transmission of User Data.
  The M2PA experiencing remote processor outage, SHALL discard messages in
  the transmit and retransmit queues as required by MTP2, and MAY perform
  resynchronization of sequence numbers using the BSN from the received
  Link Status Processor Recovered message.  However, during
  resychronization, M2PA SHALL NOT discard any received User Data
  messages.

As Q.2140 handles processor outage by putting the link out of service, also add:

  When M2PA experiences a local processor outage, it MAY put the link out
  of service by sending a Link Status Out of Service message if allowed by
  the applicable MTP2 standard (e.g, [Q.2140]).

I think that wraps up processor outage problems.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 14 Jul 2003 04:04:30 -0600

M2PA-09 says:

  If M2PA receives a User Data message with an FSN that is out of order,
  M2PA SHALL place the link out of service (see section 4.1.6 Link Out
  of Service).

This conflicts with Q.703 that ignores an MSU that contains an FSN that
is other than the next expected FSN (i.e, out of order).  This makes it
difficult to implement (and is probably the last thing standing in the
way of implementing) something like the following (that was requested by
ITU):

                           _________________
                          |                 |
                          |       IWF       |
                          |_________________|
                          |        |        |
                          |  MTP2  |  M2PA  |
                          |________|________|
                               |       |
                           ____|       |___

If M2PA discards the message as Q.703 does, and the other end of the
link was actually broken, the link will be go out of service in due
course anyway.

Change to:

  If M2PA receives a User Data message with an FSN that is out of order,
  M2PA SHALL discard the message.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 14 Jul 2003 04:09:38 -0600

M2PA-09 says:

  Note: For the Japanese version of MTP defined in [JT-Q704], MTP3
  retrieves both unsent and unacknowleged messages for transmission on
  the alternate link(s). In this version of MTP, if M2PA receives a
  Retrieval Request and FSNC request with no FSNC value, or with an
  invalid FSNC, then M2PA SHALL retrieve from its buffers and deliver to
  MTP3 in order:

     (a) any transmitted but unacknowledged User Data messages.

     (b) any untransmitted User Data messages.

JT-Q703 does not have a Retrieval Request and FSNC request.  Only a
Retrieval Request.

Change M2PA to say:

  Note: For the Japanese version of MTP defined in [JT-Q704], MTP3
  retrieves both unsent and unacknowleged messages for transmission on
  the alternate link(s). In this version of MTP, if M2PA receives a
  Retrieval Request then M2PA SHALL retrieve from its buffers and
  deliver to MTP3 in order:

     (a) any transmitted but unacknowledged User Data messages.

     (b) any untransmitted User Data messages.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 14 Jul 2003 04:25:16 -0600

M2PA-09 says:

 It is not necessary to put the message length in the LI octet as in
 MTP2. The LI octet is included because the two spare bits in the LI
 octet are used by MTP3 in at least one national version of SS7 to
 carry MTP3 information. For example, the Japanese TTC standard uses
 these spare bits as an MTP3 Message Priority field. See [JT-Q704],
 section 14 "Common Characteristics of message signal unit formats",
 section 14.2 (A) "Priority Indicator (PRI)". For versions of MTP that
 do not use these two bits, the entire octet is spare.

and

   PRI - Priority used only in national MTP defined in [JT-Q704].
         Spare for other MTP versions.

These bits are defined in JT-Q703, not JT-Q704.

Change JT-Q704 to JT-Q703 above and add [JT-Q703] to the references.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 14 Jul 2003 04:56:24 -0600

M2PA-09 says:

  The Data field contains the following fields of the MTP Message Signal
  Unit (MSU):
  
     - Length Indicator (LI), including the two undefined bits between
       the SIO and LI fields.
     - Service Information Octet (SIO)
     - Signaling Information Field (SIF)
  
  The MTP MSU is described in Q.703 [Q.703], section 2.2 "Signal Unit
  Format", and T1.111.3 [T1.111] section 2.2 "Signal Unit Format".
  
  M2PA SHALL NOT add padding to the MTP3 message. 
  
  Note that the Data field SHALL NOT contain other components of the MTP
  MSU format:
  
     - Flag
     - Backward Sequence Number (BSN)
     - Backward Indicator Bit (BIB)
     - Forward Sequence Number (FSN)
     - Forward Indicator Bit (FIB)
     - Check bits (CK) 

  The Data field SHALL be transmitted in the byte order as defined by
  MTP3. 

  Therefore in M2PA the format of the LI octet is:

      0               
      0 1 2 3 4 5 6 7 
     +-+-+-+-+-+-+-+-+
     |PRI|   spare   | (followed by SIO, SIF) 
     +-+-+-+-+-+-+-+-+

  Since the LI octet is not used for a message length, there is no need
  to support the expanded LI field in Q.703 [Q.703] Annex A. Therefore
  the LI field in M2PA is always one octet.

------

LI is not an octet, it is a field.  One that happens to not be included
in the M2PA Data field.

Change to:

------

  The Data field contains the following fields of the MTP Message Signal
  Unit (MSU):
  
     - the Message Priority field (PRI)
     - Service Information Octet (SIO)
     - Signaling Information Field (SIF)
  
  The MTP MSU is described in Q.703 [Q.703], section 2.2 "Signal Unit
  Format", and T1.111.3 [T1.111] section 2.2 "Signal Unit Format".
  The Japanese TTC standard uses the PRI field as an MTP3 Message
  Priority field [JT-Q703].  For versions of MTP that do not use these
  two bits, the entire first octet of the Data field is spare.

  The format of the first octet of the Data field is:

      0               
      0 1 2 3 4 5 6 7 
     +-+-+-+-+-+-+-+-+
     |PRI|   spare   | (followed by SIO, SIF) 
     +-+-+-+-+-+-+-+-+
  
     PRI - Priority used only in national MTP defined in [JT-Q703].
           Spare for other MTP versions.

  Note that the Data field SHALL NOT contain other components of the MTP
  MSU format:
  
     - Flag
     - Backward Sequence Number (BSN)
     - Backward Indicator Bit (BIB)
     - Forward Sequence Number (FSN)
     - Forward Indicator Bit (FIB)
     - Length Indicator (LI)
     - Check bits (CK) 

  The Data field SHALL be transmitted in the byte order as defined by
  MTP3. 

  M2PA SHALL NOT add padding to the MTP3 message. 

------

This could be less confusing that saying on the onset that the LI field
is part of the Data field and then going on to explain how it isn't.

--brian

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

---

From: Andrew Booth <[email-masked]>
Date: Wed, 16 Jul 2003 17:47:30 -0400

Hi Brian,

If the side in RPO is sending data acknowledgments then it must also be 
delivering these messages to MTP3.  Is there some guarantee that MTP3 
will accept messages from a link that it has marked as blocked?  Or am I 
misunderstanding the intent of your proposal?

Andrew

-- 
Andrew Booth, Software Developer
Signaling Systems Group, Performance Technologies
613-237-4344

Visit www.pt.com/mailing.html to subscribe to our Packets & Signals eLetter.

---

From: Andrew Booth <[email-masked]>
Date: Wed, 16 Jul 2003 18:11:04 -0400

Hi Brian,

Comments inline.

>unavailable for retransmission on an alternate link at the transmitter.
Are you assuming here that the Busy end is not delivering messages to MTP3?

>But T6 is not necessarily running during the busy condition.
I don't understand this comment.  T6 is started when LSB is received and 
stopped when LSBE is received.  Doesn't that mean that T6 is always 
running if the peer is busy?

Thanks for any info.

Regards,
Andrew

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 16 Jul 2003 18:57:58 -0600

Andrew,

Andrew Booth wrote:                                                                 (Wed, 16 Jul 2003 18:11:04)
> Are you assuming here that the Busy end is not delivering messages to MTP3?

Not really assuming.  Q.703 only sends SIB when it is in Congestion Discard.
Meaning that it is receive congested to the point that it is discarding
messages.  So I suppose the discarded messages cannot be delivered to MTP3.
Messages in queue (causing the congestion) are still delivered.

Also, Q.703 does not stop sending SIB until there is no receive congestion.
So the receive side passes through Congestion Accept to No Congestion before
it will stop SIBing.  This is the necessary hysteresis to avoid congestion
thrashing.

-X-snip-X-
> running if the peer is busy?

Q.703 on "first reception of status indication "B" starts a longer supervision
timer T6 (see 12.3) only if there are message signal units in the
retransmission buffer".  That is, T6 is only running if the remote is in
receive congestion and the local side has unacknowledged messages.  There is
the case where the remote is congested and there are no unacknowledged
messages. (The last acknowledge message triggered the receive congestion
discard situation.)  In this latter case, Q.703, T1.111.3 do not start T6.

So it is not true that T6 is always running when the peer is in receive
congestion.  In some cases the peer has send BUSY and T6 is not running.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 16 Jul 2003 19:11:43 -0600

Andrew,

Yes, we discussed this.  The proposal was to permit both situations.

If you have a MTP3 that will not accept MSUs after RPO you have another
problem: messages send by the remote before sending LSPO, but which arrived
at the peer after the LSPO because the LPSO was received (and supposedly
expedited) on stream 0.

To accomodate such implementations of MTP3 (completely valid implementations
from the SS7 standards perspective), it would be a better idea to send LSPO
on stream 1.  Then LSPR also should be sent on stream 1, otherwise there is
the possibiliy that User Data sent after sending LSPR will arrive before the
LSPR.

The side experiencing PO should accept the acknowledgement of any message
sent before or during PO.  This permits the TB/RTB to drain and has no
interaction with L3.

The statement below really says that the side experienceing RPO SHOULD
continue to acknowledge menssages received and accepted by MTP3.  If MTP3
will not accept messages during the RPO condition, then of course they 
cannot be acknowledged.  However, if MTP3 is accepting messages during
RPO (as some equally valid implementations do), then they SHOULD be
acknowledged.

This leaves both options open.  The current M2PA-09 text does not leave the
option open to continue delivering to MTP3 during RPO if MTP3 is still ready
to accept messages.

This also allows the M2PA working with an MTP3 that accepts MSUs during RPO
to not look in the sequence numbers of LSPO and LSPR sent on stream 0 to
determine which received messages preceded or followed the RPO condition and
which were between LSPO and LSPR (becaues they are all delivered to MTP3).

Make sense?

--brian

Andrew Booth wrote:                                                                 (Wed, 16 Jul 2003 17:47:30)

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

---

From: Tom George <[email-masked]>
Date: Thu, 17 Jul 2003 16:20:52 -0500

Brian,

I don't have a problem with your suggested paragraph, except that is a 
bit wordy. I put in the qualification "in the case where MTP2 would send 
a FISU after proving is complete" to cover the cases you mention. Send 
LS Ready when MTP2 would send the FISU. Elsewhere in the document it 
says to send LS PO where MTP2 sends SIPO, and User Data where MTP2 sends 
an MSU.

But the judge of readability is the reader. Let me know if you still 
think I should change it.

tomG.

-- 
* 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.  I do not purport to    *
*   advertise or represent its position, operations, or activities.   *

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 17 Jul 2003 17:52:23 -0600

Tom,

Maybe change "would send" to "sends"???

Also, it may only send additional LSR where MTP2 sends additional FISU?

I think the intent is unchanged, maybe we can find clearer wording for the
final.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Andrew Booth <[email-masked]>
Date: Fri, 18 Jul 2003 13:24:34 -0400

Hi Brian,

Thanks for the clarifications, they make sense.

I still have some concerns about your proposal though. As you pointed 
out, an MTP2 that is sending SIB is in congestion discard. Since the 
busy MTP2 is discarding messages then it should be able to alleviate 
receive congestion. Since M2PA is not able to discard messages though 
I'm not sure what the analogue of "congestion discard" should be. The 
options seem to be:
1) pass the messages to MTP3 and continue to ack them, hoping that 
receive congestion will abate (thus allowing the RB to drain)
2) queue the messages at M2PA without acknowledgment and hope that 
receive congestion abates (here the RB grows and so do the TB/RTB of the 
sender)
3) introduce retransmissions to M2PA so the M2PA layer can discard 
messages (for behaviour more like MTP2). This option is here only for 
completeness since I don't think anyone really wants to see 
retransmissions in M2PA.

I think either option (1) or (2) is acceptable in that if the link fails 
any undelivered messages can be retrieved from the sending side.
It seems to me that your are advocating option (2), but I don't see how 
this is going to allow receive congestion to clear, it seems like the RB 
at the Busy M2PA will just keep growing if it can't deliver messages to 
MTP3. This also means that if the link fails then the changeover has to 
recover more messages from the senders TB/RTB, introducing a larger 
burst to the alternate links. Also, if you ever have to drop a message 
due to lack of resources then you have no choice but to fail the link or 
silently lose messages... and if you're busy it is probably the most 
likely time to run out of resources.

Thoughts?
Andrew

---

From: Andrew Booth <[email-masked]>
Date: Fri, 18 Jul 2003 13:46:53 -0400

Hi Brian,

I agree that it makes sense to support both scenarios, where the MTP may 
accept user data after RPO or not.  Do both approaches work with the 
transparent interworking function you mentioned earlier?  It seems like 
in that case the interworking function could not properly process Data 
received after RPO without leaving RPO.

More comments inline.

>at the peer after the LSPO because the LPSO was received (and supposedly
Agreed.  They have to queued also, and will potentially be lost by a flush.

>the possibiliy that User Data sent after sending LSPR will arrive before the
I'm solidly on the fence here.  I agree that M2PA gets more complicated 
if LSPO/LSPR are not sent on the data stream, I have mixed feelings 
about whether the potential performance benefits outweigh the complexity.

>RPO (as some equally valid implementations do), then they SHOULD be
Sounds good.

>option open to continue delivering to MTP3 during RPO if MTP3 is still ready
Sounds good to me.  It seems important though to keep the text that 
describes how the receive buffers are handled in PO for implementations 
that cannot deliver DATA after RPO.

>which were between LSPO and LSPR (becaues they are all delivered to MTP3).
Yes, thanks.

Andrew

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 18 Jul 2003 11:54:31 -0600

Andrew,

Andrew Booth wrote:                                                                 (Fri, 18 Jul 2003 13:24:34)
> receive congestion will abate (thus allowing the RB to drain)

In some implementations Congestion Discard only occurs once it is not
possible to pass messages to MTP3 (e.g. queues to MTP3 from MTP2 are full)
leaving the only choice to discard.

> receive congestion abates (here the RB grows and so do the TB/RTB of the 

This is what I was proposing instead of (1).  M2PA's RB will not grow
after LSB is sent.  This is because the sender MUST stop sending User
Data once LSB is received.  The sender's TB/RTB will grow, but that is
what happens in Q.703 after SIB anyway.

> completeness since I don't think anyone really wants to see 

Not necessary, (2) works fine.

> at the Busy M2PA will just keep growing if it can't deliver messages to 

The RB should not grow after LSB.  The sender SHOULD NOT transmit messages
after receiving LSB.  Yes, Q.703 keeps sending event after SIB, but the
other end is dicarding so they are useless transmission at that point.  There
is no reason for the sender to keep sending after LSB and before LSBE.

> This also means that if the link fails then the changeover has to 
> burst to the alternate links.

This is no different than Q.703.  Q.703 withhold acknowledgements and discards
messages during receive congestion.  It even discards them, so the NACK when
busy ends causes a burst on the same link even if changeover has not occured.
Q.703 receiver in congestion does not ack messages, so TB/RTB growth in M2PA
will be no worse than Q.703.

> Also, if you ever have to drop a message due to lack of resources then you
> have no choice but to fail the link or silently lose messages... and if
> you're busy it is probably the most likely time to run out of resources.

We'll just say that when the M2PA peer receives LS Busy, that it MUST NOT
send User Data until it receives LS Busy Ended.  That will curtail RB growth,
and follow Q.703 closely.

In addition the the changes I mentioned before, change:

  The peer M2PA SHOULD continue transmitting and acknowledging messages
  while its T6 timer is running, i.e. while the other end is busy.

 to:

  The peer M2PA SHOULD continue receiving and acknowledging messages while
  the other end is busy, but MUST NOT send User Data after receiving Link
  Status Busy and before receiving Link Status Busy Ended.

It think it was a type to say "transmitting" here anyway.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 18 Jul 2003 12:00:53 -0600

Andrew,

Andrew Booth wrote:                                                                 (Fri, 18 Jul 2003 13:46:53)
> received after RPO without leaving RPO.

I think so.  The clearing buffers is the same.  The side in RPO is just
permitted to acknowledge messages where it was not before.

It is still there except for:
> >>>                                                 ... M2PA SHOULD NOT

The reason I removed this is that RPO latching to LPO option does exactly
that: flushes data messags with FSN greater than the FSN in the Link Status
Processor Recovered message.  What messages are flushed are really the
business of the flusher.

--brian

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

---

From: Andrew Booth <[email-masked]>
Date: Fri, 18 Jul 2003 14:10:30 -0400

Hi Brian,

I handn't understood that you wanted the remote end to stop sending to 
the busy end.  Now that I understand that part your proposal makes a lot 
of sense.

Thanks for the clarification.

Andrew

---

From: Andrew Booth <[email-masked]>
Date: Fri, 18 Jul 2003 15:24:09 -0400

Hi Brian,

Some comments and questions below. I'll assume that M2PA continues to 
use separate stream 0 for LS PO and LS PR, and stream 1 for data.

>permitted to acknowledge messages where it was not before.
Maybe I'm misunderstanding the role of the interworking function, but I 
assume it's for inline tunneling of MTP2 to M2PA with no MTP3 point code.

The case I'm wondering about is if the M2PA link receives LSPO followed 
by Data (suppose the messages were sent in the other order).
Once LSPO is passed to the interworking function I assume that it will 
send SIPO on the MTP2 link, after that if the IWF receives the Data from 
M2PA there's nothing it can do with it... if it sends to MTP2 the the 
MTP2 will see RPO as ended. On the other hand the message has been 
acknowledged by M2PA, if the link ends up dropping or if one side tries 
a sequenced changeover then the message is lost forever. This can be 
avoided if M2PA does not try to deliver the Data after RPO.

So I guess I'm wondering if the IWF is an example of an upper layer 
where it would be better not to pass data after RPO.

>Processor Recovered message.  What messages are flushed are really the
For MTP's that can't send data after RPO, doesn't this case also come up 
when exiting from RPO? e.g. if one side receives LSPO then sometime 
after MTP3 T1 has expired it receives data and LSPR (again, that were 
sent in the wrong order). Then the DATA message is in the RB and should 
probably not be flushed when the MTP3 issues a flush buffers (or clear RTB).

In fact even if LSPR and data are sent on the same stream, there is the 
following scenario (I don't know how easy it is for this to happen, we 
may have to assume a retransmit of the LSPR so the LSPR and data arrive 
together after a changeback)...
Suppose that the end in RPO receives an LS PR which it forwards to MTP3, 
then receives data (which goes in the RB) and only then receives the 
flush/clear RTB from MTP3... In this case we probably want to flush the 
old messages in the RB but not the ones sent after LS PR...

Just wondering if the text on flushing buffers when exiting PO still has 
some use. Maybe an advisory comment would be enough...

Thoughts?
Andrew

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 18 Jul 2003 13:39:57 -0600

Andrew,

Andrew Booth wrote:                                                                 (Fri, 18 Jul 2003 15:24:09)
> where it would be better not to pass data after RPO.

Oh, that IWF.  An IWF would probably be better to translate RPO into OOS.

[snip]
> some use. Maybe an advisory comment would be enough...

Sure.  Just as long as the sender will generate acknowledgements in RPO
I don't have a problem.  Also, T6 does not always run when in RPO.
Did you want to propose some alternate text to the text I proposed below?

--brian

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

---

From: Andrew Booth <[email-masked]>
Date: Fri, 18 Jul 2003 17:34:03 -0400

Hi Brian,

>Did you want to propose some alternate text to the text I proposed below?
What do you think of the following proposal, does it sum up both our points?
As a miscellaneous note I changed the LS PR to LS PO in the final 
paragraph; the motivation is that I think the FSN in the LSPO and LSPR 
should be the same (the side in LPO shouldn't be sending data) and 
because the Flush could arrive before the LS PR in which case the old 
text is clearly wrong. I'm not sure though if that change was the right 
one. Please let me know what you think.

Thanks,
Andrew

4.1.4 Processor Outage

The Link Status Processor Outage message replaces the SIPO message of
MTP2. Unlike MTP2, the message SHOULD NOT be transmitted
continuously. M2PA SHALL send a Link Status Processor Outage message
to its peer at the beginning of a processor outage condition where
MTP2 would send SIPO. M2PA MAY send additional Link Status Processor
Outage messages as long as that condition persists.

Some MTP3 implementations may be able to accept received User Data
while in Remote Processor Outage while others may not. While there
is a remote processor outage condition:

(a) M2PA SHOULD continue to acknowledge User Data Message received and
accepted by MTP3 regardless of the remote processor outage.

(b) Any User Data messages received from the peer after
the Link Status Processor Outage that may not be passed to MTP3
MUST NOT be acknowledged and MUST be buffered.

If M2PA receives a Flush command from MTP3, M2PA SHALL
discard the incoming messages that were queued and unacknowledged during the
processor outage condition. Furthermore, M2PA SHALL discard messages in the
transmit and retransmit queues as required by MTP2. Similar behaviour
is appropriate in response to corresponding primitives in other SS7 variants
such as the ANSI Clear RTB primitive.

Note that because the Link Status and User Data messages are sent on 
separate
streams, it is possible for a User Data message sent after the Link Status
Processor Recovered message to arrive before it. Therefore, when flushing
buffers, M2PA must take care not to flush messages sent after the remote
processor recovered. M2PA SHOULD NOT flush User Data messages with FSN 
greater
than the FSN in the last received Link Status Processor Outage message.
Note that similar conditions could occur if User Data is received after Link
Status Processor Recovered but before the Flush command from MTP3. Similar
behaviour is appropriate in response to comparable primitives in other 
SS7 variants,
such as the ANSI Clear RTB primitive.

---

From: Tom George <[email-masked]>
Date: Wed, 23 Jul 2003 15:32:44 -0500

Brian,

Maybe this?

=====
The Link Status Ready message replaces the FISU of MTP2 that is sent
at the end of the proving period. The Link Status Ready message is
used to verify that both ends have completed proving. When M2PA starts
timer T1, it SHALL send a Link Status Ready message to its peer in the
case where MTP2 would send a FISU after proving is complete. If the
Link Status Ready message is sent, then M2PA MAY send additional Link
Status Ready messages while timer T1 is running.

In the case that MTP2 sends an MSU or SIPO message at the end of
proving, M2PA SHALL send (respectively) a User Data or Link Status
Processor Outage message.
=====

tomG.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 23 Jul 2003 16:37:41 -0600

Tom,

Poifect!

--brian

---

From: Tom George <[email-masked]>
Date: Wed, 23 Jul 2003 17:42:55 -0500

My JT-Q703 (that reference needs to be changed, too) has both in Figure 
13-6/JT-Q703 (sheet 4 of 4).

The "Retrieval Request and FSNC" erases the messages in the RTB up to 
where FSN = FSNC. The The "Retrieval Request" skips that part and just 
retrieves everything in the RTB.

I should update the text to note that both kinds of requests are 
allowed, instead of saying that all of the messages are always retrieved.

tomG.

---

From: Tom George <[email-masked]>
Date: Wed, 23 Jul 2003 17:58:18 -0500

Brian,

Correct. The values are defined in JT-Q704, but the format is in 
JT-Q703. The new text says:

=====
It is not necessary to put the message length in the LI octet as in
MTP2. The LI octet is included because the two spare bits in the LI
octet are used by MTP3 in at least one national version of SS7 to
carry MTP3 information. For example, the Japanese TTC standard uses
these spare bits as an MTP3 Message Priority field. See [JT-Q703],
section 2.3.10 "Priority Indicator (PRI:Priority Indicator)". The
values of this field are in [JT-Q704], section 14 "Common
Characteristics of message signal unit formats", section 14.2 (A)
"Priority Indicator (PRI)". For versions of MTP that do not use these
two bits, the entire octet is spare.
=====

The new reference says:
=====
   [JT-Q703]
        TTC, "Message Transfer Part Signalling Link," TTC Standard
        JT-Q703, Telecommunication Technology Committee (TTC), version
        3 (April 27, 1994).
=====

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 23 Jul 2003 17:00:45 -0600

Tom,

The way the text sounded to me was that it was saying that when a
"Retrieval Request and FSNC" was received without an FSNC rather
than when a plain "Retrieval Request" was received...

Just a nit, really.

--brian

Tom George wrote:                                                                      (Wed, 23 Jul 2003 17:42:55)

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

---

From: Tom George <[email-masked]>
Date: Thu, 24 Jul 2003 13:59:04 -0500

Brian,

It is a nit, but the way I had the text washed over the fact that there 
were two different requests. Here is my suggested new wording:

=====
The Japanese TTC version of MTP defined in [JT-Q703] has a Retrieval
Request (as well as Retrieval Request and FSNC). The Retrieval Request
allows MTP3 to retrieve both unsent and unacknowleged messages for
transmission on the alternate link(s). In this version of MTP, if M2PA
receives a Retrieval Request, then M2PA SHALL retrieve from its
buffers and deliver to MTP3 in order:

tomG.

---

From: Tom George <[email-masked]>
Date: Thu, 24 Jul 2003 14:29:14 -0500

Brian,

Your explanation is better. I will change my wording to yours.

tomG.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 24 Jul 2003 13:45:01 -0600

Tom,

Sounds good.

--brian

Tom George wrote:                                                                      (Thu, 24 Jul 2003 13:59:04)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 24 Jul 2003 13:48:45 -0600

Andrew,

No that doesn't sound right.  The side in LPO must be able to drain it's TB to
the peer and the peer needs to acknowledge messsages received after LPO but
before LPR if its MTP3 is able to do so.  That's what started this thread off
in the first place.

--brian

Andrew Booth wrote:                                                                 (Fri, 18 Jul 2003 17:34:03)

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

---

From: Tom George <[email-masked]>
Date: Fri, 25 Jul 2003 14:58:55 -0500

Brian,

Done.

tomG.

---

From: Andrew Booth <[email-masked]>
Date: Tue, 29 Jul 2003 14:19:14 -0400

Hi Brian,

Sorry for the slow reply.

I was thinking mostly about letting the RTB drain and forgot about the 
TB.  So if you want to let the TB drain, use the BSN in the LS PR is 
used to resynchronize sequence numbers as in the original text.  Is the 
rest of the proposed text ok?

In any case we could allow the side in LPO to continue to send the TB 
and RTB to the peer.  This leaves the M2PA in RPO with the freedom to 
deal with the messages as their interface to MTP3 allows e.g. if the 
peer cannot deliver these messages to MTP3 then they will be flushed 
after MTP3 T1.   This is not explicitly mentioned below, but could be. 
 The only disadvantage would be increased bandwidth use if the messages 
end up getting flushed.

After thinking some more about it though I think there are some 
complications that come from passing messages to MTP3 while in RPO.  I 
wonder if the details of this interface should be left as implementation 
dependent i.e. don't include the possibility in the text and leave the 
implementer to forge ahead with their own MTP3/M2PA interface...  I 
think in this case the semantics of the MTP3/M2PA interface are slightly 
different that usual.  Anyone who will use such an interface will still 
be able to use the usual MTP3/MTP2 interface as a reference.

If we are going to mention the possibility of passing data to the MTP3 
while in RPO, should we also warn about some of the issues that must be 
dealt with?  In particular, the M2PA that is passing data to the MTP3 
while in RPO must continue to interact properly with MTP3 procedures 
that may be going on e.g. sequence, time controlled or emergency 
changeover.  I don't think this is well covered in the MTP2 specs, since 
the posibility of getting data in RPO is limited to messages that 
arrived before the first SIPO.  In particular:
- data must not be delivered to MTP3 if the remote end has been 
performing a time controlled changeover and its T1 has expired
- data must not be delivered to MTP3 after a BSNT request has been anwered
- data must not be delivered to MTP3 after the local MTP3 has responded 
to a changeover order with an emergency changeover response
I'd rather avoid the whole issue.

Thoughts?
Andrew

---

From: Tom George <[email-masked]>
Date: Tue, 29 Jul 2003 17:02:34 -0500

Brian,

The old text about ignoring the BSN in the LS messages has been taken 
out in version 9. We explicitly mention that the BSN in the LS PO 
message can be used, but there is no reason to restrict the use of the 
BSN in other LS messages.

Right?

tomG.

   [...]
> retransmission buffer since the receipt of the last Link Status Busy Ended.
   [...]

---

From: Tom George <[email-masked]>
Date: Tue, 29 Jul 2003 17:04:48 -0500

Brian,

I incorporated your recommendations.

Here is the new text for section 4.1.5:
=====
4.1.5 Level 2 Flow Control

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 Busy messages as long as that condition
persists. When the condition ends, M2PA SHALL send a Link Status Busy
Ended message to its peer.

M2PA SHALL continue transmitting messages while it is in receive
congestion, but MUST NOT acknowledge the message that triggered the
sending of the Link Status Busy message, nor any messages received
before the sending of Link Status Busy Ended.

When the peer M2PA receives the first Link Status Busy message, it
SHALL start the Remote Congestion timer T6 if there are messages in
the retransmission buffer awaiting acknowledgement (i.e., T7 is
running).  In addition, M2PA SHALL stop the T7 timer if it is running.
Additional Link Status Busy messages received while T6 is running do
not cause T6 to be reset and do not cause T7 to be started.  Also,
while T6 is running, T7 SHALL NOT be started.

When the peer M2PA receives the Link Status Busy Ended message and T6
has not expired, it SHALL stop T6 if T6 is running and start T7 if
there are messages awaiting acknowledgement in the retransmission
buffer.

The peer M2PA SHOULD continue receiving and acknowledging messages
while the other end is busy, but MUST NOT send User Data messages
after receiving Link Status Busy and before receiving Link Status Busy
Ended.
=====

Here is the old (version 9) text for reference:
=====
4.1.5 Level 2 Flow Control

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 Busy messages as long as that condition
persists. When the condition ends, M2PA SHALL send a Link Status Busy
Ended message to its peer.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 29 Jul 2003 16:05:53 -0600

Tom,

Right.  That was my thinking too.

--brian

Tom George wrote:                                                                      (Tue, 29 Jul 2003 17:02:34)

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

---

From: Tom George <[email-masked]>
Date: Thu, 31 Jul 2003 17:29:15 -0500

Brian, Andrew, et. al.,

So where do we stand on this issue? If it is true that some MTP3 
implementations would accept incoming messages during RPO and some would 
not, then we should probably cover both cases.

tomG.

   [...]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 31 Jul 2003 16:50:31 -0600

Tom,

See the original note on this thread for suggested changes.

--brian

Tom George wrote:                                                                      (Thu, 31 Jul 2003 17:29:15)

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