Subject: [Sigtran] M2PA draft "7b" - section 4.1

From: Tom George <[email-masked]>
Date: Fri, 11 Apr 2003 15:49:52 -0500

I tried to post a revised M2PA draft that removed the Q.703 duplication.
But it was not posted because there is a size limit. So here is section
4 and 4.1. I will send 4.2 in another message. I am trying to get a
consensus on whether this is the direction for draft version 8. 

4.  Procedures

Since M2PA provides MTP3 with an interface and functionality like
MTP2, its internal functioning is similar to that of MTP2. 

Except as modified in this document, M2PA SHOULD follow the
requirements of the applicable MTP2 specification. These may include
[Q.703] or [T1.111].

When referring to MTP2 terminology in this document, the terminology
of [Q.703] is used. This does not imply that the requirements of
[Q.703] are to be followed.

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 of user
messages. 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.

Since SCTP provides delivery of messages, there is no need for M2PA to
delimit its messages with a flag as in MTP2. Furthermore, M2PA does
not need to perform zero bit insertion and deletion on its messages. 

Since SCTP uses a checksum to detect transmission errors, there is no
need for an M2PA checksum as in MTP2. This also eliminates the need
for the error rate monitors of MTP2.

Since SCTP provides reliable delivery and ordered delivery, M2PA does
not perform retransmissions. This eliminates the need for the forward
and backward indicator bits in MTP2 signal units.

Acceptance of a message is indicated by a successful receipt of the
message from SCTP.

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 Status Out of Service message replaces the SIOS message of
MTP2. Unlike MTP2, the message SHOULD NOT be transmitted
continuously. After the association is established, M2PA SHALL send a
Link Status Out of Service message to its peer. Prior to the beginning
of alignment, M2PA MAY send additional Link Status Out of Service
messages.

The Link Status Alignment message replaces the SIO message of
MTP2. This message is sent to signal the beginning of the alignment
procedure. The Link Status Alignment message SHOULD NOT be transmitted
continuously. M2PA MAY send additional Link Status Alignment until it
receives Link Status Alignment, Link Status Proving Normal, or Link
Status Proving Emergency from the peer.

The Link Status Proving Normal message replaces the SIN message of
MTP2. The Link Status Proving Emergency message replaces the SIE
message of MTP2. 

During the proving period (i.e., after M2PA starts the proving period
timer T4), M2PA SHALL send Link Status Proving messages to its peer at
an interval defined by the protocol parameter Proving_Interval. 

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. M2PA
MAY send additional Link Status Ready messages while timer T1 is
running.

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. When the condition
ends, M2PA SHALL send a Link Status Processor Recovered message to its
peer.

4.1.5 Level 2 Flow Control

The Link Status Busy message replaces the SIB message of MTP2. Unlike
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.

4.1.6  Link Out of Service

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

When M2PA places a link in the OUT OF SERVICE state, M2PA SHOULD NOT
terminate the SCTP association.

4.1.7 SCTP Association Problems

The SCTP association for a link may become unusable, such as when one
of the following occurs:

   - SCTP sends a Send Failure notification to M2PA.

   - SCTP sends a Communication Lost notification to M2PA.

   - SCTP sends a Communication Error notification to M2PA.

   - The SCTP association is lost.

If the SCTP association for a link becomes unable to transmit or
receive messages, M2PA SHALL report to MTP3 that the link is out of
service and enter the OUT OF SERVICE state.

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