Subject: Re: [Sigtran] M2PA: Revised section 4.1

From: [email-masked]
Date: Wed, 12 Mar 2003 16:45:02 -0500

Tom,

Now that we have a Processor Outage state, we should probably change the 
following paragraph of section 4.1.4 from

"If the peer is in the IN SERVICE state, it uses the Remote Processor
Recovered Indication to notify its MTP3 that the remote processor
outage condition has ceased."

to

"If the peer is in the PROCESSOR OUTAGE state, it transitions to the 
IN SERVICE state and then uses the Remote Processor Recovered Indication 
to notify its MTP3 that the remote processor outage condition has ceased."

Barry Nagelberg

Tom George <[email-masked]>
Sent by: [email-masked]
 03/07/2003 10:15 PM

        To:     SIGTRAN e-mail list <[email-masked]>
        cc: 
        Subject:        [Sigtran] M2PA: Revised section 4.1

4.  Procedures

4.1 Procedures to Support MTP2 Features

4.1.1 Signal Unit Format, Delimitation, Acceptance

Messages for transmission across the network must follow the format
described in section 2.

SCTP provides reliable, in-sequence delivery. Therefore the related
functionality of MTP2 is not needed. SCTP does not provide functions
related to Link State Control in MTP2. These functions must be
provided by M2PA.

4.1.2 MTP and SCTP Entities

This section describes how M2PA relates MTP and SCTP entities.

Each MTP link corresponds to an SCTP association. To prevent duplicate
associations from being established, it is RECOMMENDED that each
endpoint know the IP address (or IP addresses, if multi-homing is
used) and port number of both endpoints. SCTP prevents two
associations with the same IP addresses and port numbers from being
established.

It is necessary for at least one of the endpoints to be listening on
the port on which the other endpoint is trying to establish the
association. Therefore, at least one of the port numbers SHOULD be the
M2PA registered port.

If only one association is to be established between these two IP
addresses, then the association SHOULD be established using the M2PA
registered port at each endpoint.

If it is desirable to create multiple associations (for multiple
links) between the two IP addresses, different port numbers can be
used for each association. Nevertheless, the M2PA registered port
number SHOULD be used at one end of each association.

Each combination of IP address/port for the two endpoints (i.e., each
association) MUST be mapped to the same Signaling Link Code (SLC) at
each endpoint, so that each endpoint knows which link is being created
at the time the SCTP association is established. However, M2PA does
not do any processing based on the SLC.

Following are examples of the relationships between associations and
links. Note that a link is an SCTP association identified by two
endpoints. Each endpoint is identified by an IP address and port
number. Each association is mapped to an SLC.

Figure 9 shows a case with two IPSPs, each with two IP addresses. Two
associations are the links that connect the two IPSPs. Since these
links are in the same link set, they MUST have different SLCs.

Table 1 shows the relationships in tabular form. Table 1 is only
conceptual. The actual method for mapping the SCTP associations to the
SLCs is implementation dependent.

                IPSP X                        IPSP Y

            +-------------+               +-------------+
            |             |     SCTP      |             |
            |         IPA | association 1 | IPB         |
            |   port = PW +---------------+ port = PW   |
            |     SLC = a |               | SLC = a     |
            |             |               |             |
            |             |               |             |
            |             |     SCTP      |             |
            |         IPC | association 2 | IPD         |
            |   port = PW +---------------+ port = PW   |
            |     SLC = b |               | SLC = b     |
            |             |               |             |
            |             |               |             |
            +-------------+               +-------------+

                IPx = IP address
                PW  = Registered port number for M2PA

            Figure 9. Two IPSPs with Two IP Addresses Each

            Table 1. Two IPSPs with Two IP Addresses Each

     +-------------+---------------------------------------+-----+
     | Association |      IPSP X       |      IPSP Y       | SLC |
     |             +------------+------+------------+------+     |
     |             | IP address | Port | IP address | Port |     |
     +=============+============+======+============+======+=====+
     |      1      |    IPA     |  PW  |    IPB     |  PW  |  a  |
     +-------------+------------+------+------------+------+-----+
     |      2      |    IPC     |  PW  |    IPD     |  PW  |  b  |
     +-------------+------------+------+------------+------+-----+

Figure 10 and Table 2 show an example with three IPSPs. Note that in
this example, the two links are in different link sets. Therefore, it
is possible that the values a and b MAY be equal.

                IPSP X                        IPSP Y

            +-------------+               +-------------+
            |             |     SCTP      |             |
            |         IPA | association 1 | IPB         |
            |   port = PW +---------------+ port = PW   |
            |     SLC = a |               | SLC = a     |
            |             |               |             |
            |             |               |             |
            |             |     SCTP      |             |
            |         IPC | association 2 |             |
            |   port = PW +-------+       |             |
            |     SLC = b |       |       |             |
            |             |       |       |             |
            |             |       |       |             |
            +-------------+       |       +-------------+
                                  |
                                  |
                                  |           IPSP Z
                                  |
                                  |       +-------------+
                                  |       |             |
                                  |       | IPD         |
                                  +-------+ port = PW   |
                                          | SLC = b     |
                                          |             |
                                          |             |
                                          |             |
                                          |             |
                                          |             |
                                          |             |
                                          |             |
                                          |             |
                                          +-------------+

                IPx = IP address
                PW  = Registered port number for M2PA

              Figure 10. One IPSP Connected to Two IPSPs

               Table 2. One IPSP Connected to Two IPSPs

     +-------------+---------------------------------------+-----+
     | Association |      IPSP X       |     IPSP Y/Z      | SLC |
     |             +------------+------+------------+------+     |
     |             | IP address | Port | IP address | Port |     |
     +=============+============+======+============+======+=====+
     |      1      |    IPA     |  PW  |    IPB     |  PW  |  a  |
     +-------------+------------+------+------------+------+-----+
     |      2      |    IPC     |  PW  |    IPD     |  PW  |  b  |
     +-------------+------------+------+------------+------+-----+

Figure 11 and Table 3 show two associations between the same IP
addresses. This is accomplished by using different port numbers for
each association at one endpoint.

                IPSP X                        IPSP Y

            +-------------+               +-------------+
            |             |     SCTP      |             |
            |         IPA | association 1 | IPB         |
            |   port = P1 +---------------+ port = PW   |
            |     SLC = a |               | SLC = a     |
            |             |               |             |
            |             |               |             |
            |             |     SCTP      |             |
            |         IPA | association 2 | IPB         |
            |   port = PW +---------------+ port = PW   |
            |     SLC = b |               | SLC = b     |
            |             |               |             |
            |             |               |             |
            +-------------+               +-------------+

               IPx = IP address
               P1  = Pre-selected port number
               PW  = Registered port number for M2PA

       Figure 11. Multiple Associations Between Two IP Addresses

        Table 3. Multiple Associations Between Two IP Addresses

     +-------------+---------------------------------------+-----+
     | Association |      IPSP X       |      IPSP Y       | SLC |
     |             +------------+------+------------+------+     |
     |             | IP address | Port | IP address | Port |     |
     +=============+============+======+============+======+=====+
     |      1      |    IPA     |  P1  |    IPB     |  PW  |  a  |
     +-------------+------------+------+------------+------+-----+
     |      2      |    IPA     |  PW  |    IPB     |  PW  |  b  |
     +-------------+------------+------+------------+------+-----+

The association SHALL contain two streams in each direction. Stream 0
is designated for Link Status messages. Stream 1 is designated for
User Data messages.

4.1.3  Link Alignment

The purposes of the alignment procedure are:

   (1) To provide a handshaking procedure so that both endpoints are
       prepared to send SS7 traffic, and to prevent traffic from being
       sent before the other end is ready.

   (2) To verify that the SCTP association is suitable for use as an
       SS7 link.

Link alignment takes place after the association is established. If
SCTP fails to establish the association, and M2PA has received a Start
Request from its MTP3, then M2PA SHALL report to MTP3 that the link is
out of service. 

The link begins in the Out of Service state (see section 4.1.6 Link
Out of Service). After the association is established, M2PA SHALL send
a Link Status Out of Service message to its peer. Prior to receiving a
Start Request from MTP3, M2PA MAY periodically send Link Status Out of
Service messages.

Once the association is established and M2PA has received a Start
Request from MTP3, M2PA sends the Link Status Alignment message to its
peer. If M2PA has not already received the Link Status Alignment
message from its peer, then M2PA starts timer T2.

(Note that if the remote M2PA has not received a Start Request from
its MTP3, it will not send the Link Status Alignment message to the
local M2PA. Eventually timer T2 in the local M2PA will expire. If the
remote M2PA receives a Start Request from its MTP3 and sends Link
Status Alignment before the local M2PA's timer T2 expires, the
alignment procedure can continue.)

M2PA stops timer T2 when it has received a Link Status Alignment, Link
Status Proving Normal, or Link Status Proving Emergency message from
its peer.

If timer T2 expires, then M2PA SHALL place the link out of service
(see section 4.1.6 Link Out of Service).

Note: Between the time M2PA sends Link Status Alignment to its peer
and receives either Link Status Alignment, Link Status Proving Normal,
or Link Status Proving Emergency from its peer, M2PA may receive Link
Status Out of Service from its peer. This message is ignored. After
receiving a Link Status Alignment, Link Status Proving Normal, or Link
Status Proving Emergency message from its peer, receipt of a Link
Status Out of Service message causes M2PA to place the link out of
service (see section 4.1.6 Link Out of Service).

When M2PA has sent Link Status Alignment and has received either a
Link Status Alignment, Link Status Proving Normal, or Link Status
Proving Emergency message, it has completed alignment. M2PA starts the
aligned timer T3 and the proving period timer T4, and moves to the
Proving state. Note that timer T3 is started even if reception of a
Link Status Proving message caused the transition to the Proving
state.

M2PA stops timer T3 when it receives a Link Status Proving Normal or
Proving Emergency message.

If timer T3 expires, then M2PA SHALL place the link out of service
(see section 4.1.6 Link Out of Service).

During the proving period (i.e., after M2PA starts the proving period
timer T4), M2PA sends Link Status Proving messages to its peer at an
interval defined by the protocol parameter Proving_Interval. M2PA
sends either the Proving Normal or Proving Emergency message,
according to the Emergency and Emergency Ceases commands from
MTP3. M2PA uses the value of T4 corresponding to the Normal or
Emergency condition. However, if M2PA receives a Link Status Proving
Emergency message from its peer, then M2PA SHALL initiate the
Emergency proving period value for T4, but it SHALL continue to send
the Proving message (Normal or Emergency) determined by its own upper
layer MTP3.

When the proving period timer T4 expires, M2PA changes to the Aligned
Ready state. M2PA SHALL start the timer T1 and send a Link Status
Ready message to its peer. The Link Status Ready message is used to
verify that both ends have completed proving. M2PA MAY send additional
Link Status Ready messages while timer T1 is running.

M2PA SHALL stop timer T1 when it receives a Link Status Ready or User
Data message from its peer. If timer T1 expires, then M2PA SHALL place
the link out of service (see section 4.1.6 Link Out of Service).

Note that if M2PA has already received a Link Status Ready message
from its peer when its timer T4 expires, there is no need to start
timer T1. M2PA can just send Link Status Ready to the peer and
continue along.

When all of the following are true:

   (a) M2PA has received a Start Request from MTP3.

   (b) M2PA's proving period T4 has expired.

   (c) M2PA has sent a Link Status Ready to its peer.

   (d) M2PA has received a Link Status Ready OR User Data
       message from its peer.

   (e) M2PA has not received Link Status Out of Service from its peer
       since it received Link Status Alignment. 

   then M2PA SHALL send Link In Service to its MTP3. 

If there is a local processor outage condition during the alignment
procedure, M2PA sends Link Status Processor Outage to its peer. When
the local processor outage condition ends, then M2PA SHALL send Link
Status Processor Recovered to its peer. M2PA SHALL attempt to complete
the alignment procedure during the local processor outage
condition. If the local processor outage condition exists when M2PA
completes Proving, M2PA shall enter the ALIGNED NOT READY state.

If M2PA receives a Link Status Processor Outage during alignment, and
M2PA had received a Start Request from its MTP3, M2PA SHALL report
Remote Processor Outage to MTP3. M2PA SHALL attempt to complete the
alignment procedure during the remote processor outage condition.

If M2PA receives a Stop command from its MTP3 during alignment, M2PA
SHALL terminate the alignment procedure and place the link out of
service (see section 4.1.6 Link Out of Service).

Anomalous messages received during alignment SHOULD be
discarded. Examples include:

   (a) User Data received before proving begins.

   (b) Link Status Alignment received before or during proving.

Recommended values:

   T1 Ready - Range: 40-50 seconds. Default: 45 seconds.

   T2 Not Aligned - Range: 5-150 seconds. Default: 60 seconds.

   T3 Aligned - Range: 1.0-1.5 seconds. Default: 1.0 seconds.

   T4 Normal - Range: 7.5-9.5 seconds. Default: 8 seconds.

   T4 Emergency - Range: 400-600 milliseconds. 
                  Default: 500 milliseconds.

   Proving_Interval - implementation dependent.

4.1.4 Processor Outage

A processor outage occurs when M2PA cannot transfer messages because
of a condition at a higher layer than M2PA.

When M2PA detects a local processor outage, it sends a Link Status
Processor Outage message to its peer. While in a local processor
outage condition:

   (a) M2PA MAY send additional Link Status Processor Outage messages
       as long as there is a local processor outage and the link is in
       service. If the link is out of service, M2PA SHOULD locally
       mark that it is in local processor outage.

   (b) M2PA SHALL NOT send User Data messages to SCTP for
       transmission.

   (c) Any User Data messages received from the peer MUST NOT be
       acknowledged and MUST be buffered.

   (d) M2PA SHOULD continue to acknowledge User Data messages received
       before the local processor outage.

   (e) M2PA SHALL stop the Remote Congestion timer T6 (see section
       4.1.5 Level 2 Flow Control) if it is running.

The peer M2PA, upon receiving the Link Status Processor Outage
message, SHALL report Remote Processor Outage to its MTP3. While there
is a remote processor outage condition:

   (a) M2PA SHALL NOT send User Data messages to SCTP for
       transmission.

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

   (c) M2PA SHOULD continue to acknowledge User Data messages received
       before the remote processor outage.

   (d) M2PA SHALL stop the Remote Congestion timer T6 if it is
       running.

   (e) M2PA SHALL stop timer T7, if it is running.

MTP3 may send a Flush Buffers or Continue command to M2PA as part of
its processor outage procedure (See section 4.2.4 Flush Buffers and
Continue). The use of Flush Buffers and Continue is specified in Q.703
[Q.703] and T1.111.3 [T1.111].

Alternatively, MTP3 may perform data retrieval as part of a changeover
procedure.

When the processor outage ceases, MTP3 sends a Local Processor
Recovered indication to M2PA. The local M2PA SHALL notify its peer by
sending a Link Status Processor Recovered message. M2PA SHALL restart
timer T7 for any messages in its retransmission buffer. The local M2PA
SHALL resume receiving and transmitting messages.

If the peer is in the IN SERVICE state, it uses the Remote Processor
Recovered Indication to notify its MTP3 that the remote processor
outage condition has ceased. 

4.1.5 Level 2 Flow Control

The determination of receive congestion in M2PA is implementation
dependent. 

If M2PA determines that it is in receive congestion for an
association, M2PA SHALL send a Link Status Busy message to its peer on
that association. M2PA SHALL continue to acknowledge incoming
messages.

M2PA MAY send additional Link Status Busy messages as long as it is in
receive congestion.

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

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.

If timer T6 expires, M2PA SHALL place the link out of service
(see section 4.1.6 Link Out of Service).

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

The peer M2PA SHALL NOT fail the link due to expiration of timer T7
excessive delay of acknowledgement (see section 4.2.1 Sending and
receiving messages) while its T6 timer is running, i.e., while the
other end is Busy.

If M2PA is no longer in receive congestion for the association, M2PA
SHALL send a Link Status Busy Ended message to its peer on that
association.

When the peer M2PA receives the Link Status Busy Ended message, it
SHALL stop timer T6.

Recommended values:

   T6 Busy - Range: 1-6 seconds. Default: 4.5 seconds.

4.1.6  Link Out of Service

When M2PA places a link in the OUT OF SERVICE state, 

   (1) M2PA SHALL send a Link Status Out of Service message to its
       peer.

   (2) M2PA SHALL send an Out of Service indication to its upper layer
       MTP3. M2PA MAY send additional Link Status Out of Service
       messages to its peer while it remains in the OUT OF SERVICE
       state.

   (3) M2PA SHOULD NOT terminate the SCTP association.

M2PA waits for an MTP3 Start command to begin the alignment procedure.

During the Out of Service state M2PA SHOULD ignore received Link
Status Out of Service messages. M2PA SHOULD respond to all other
received messages by sending a Link Status Out of Service message.

4.1.7 Error Monitoring

If M2PA loses the SCTP association for a link, M2PA SHALL report to
MTP3 that the link is out of service.

4.1.8  Transmission and Reception Priorities

In MTP, Link Status messages have priority over User Data messages
([Q.703], section 11.2). To achieve this in M2PA, M2PA SHALL send
Link Status and User Data messages on separate streams in its SCTP
association. M2PA SHALL send all messages using the ordered delivery
option of SCTP.

M2PA SHOULD give higher priority to Link Status messages than to User
Data messages when sending messages to SCTP.

M2PA SHOULD give higher priority to reading the Link Status stream
than to reading the User Data stream.

M2PA SHOULD give higher priority to receiving notifications from SCTP
than to reading either the Link Status stream or the User Data stream.

4.1.9  M2PA Version Control

A node upgraded to a newer version of M2PA SHOULD support the older
versions used on other nodes with which it is communicating. If that
is the case, then alignment can proceed normally.

In particular, it is recommended that for future modifications to this
protocol:

- Any newer version SHOULD be able to process the messages from an
  older version.

- A newer version of M2PA SHOULD refrain from sending messages to an
  older version of M2PA messages that the older version cannot
  process.

- If an older version of M2PA receives a message that it cannot
  process, it SHOULD discard the message.

- In cases where different processing is done in two versions for the
  same format of a message, then the newer version SHOULD contain
  procedures to recognize this and handle it appropriately.

In case a newer version of M2PA is incompatible with an older version,
the newer version SHOULD recognize this and prevent the alignment of
the link. If a Link Status Alignment message with an unsupported
version is received by the newer version, the receiving end's M2PA
SHOULD reply with a Link Status Out of Service message and not
complete the alignment procedure.

-- 
* 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: Thu, 13 Mar 2003 13:34:56 -0600

Barry,

That sounds better. Combining this with your other comment, the last 2
paragraphs in that section would now say this:

===================
When the processor outage ceases, MTP3 sends a Local Processor
Recovered indication to M2PA. The local M2PA SHALL notify its peer by
sending a Link Status Processor Recovered message. The local M2PA
SHALL resume receiving and transmitting messages.

If the peer is in the PROCESSOR OUTAGE state, it enters the IN SERVICE
state and uses the Remote Processor Recovered Indication to notify its
MTP3 that the remote processor outage condition has ceased. M2PA SHALL
restart timer T7 for any messages in its retransmission buffer.
===================

tomG.

> to notify its MTP3 that the remote processor outage condition has ceased."
  [...]