Network Working Group                                      Tom George
INTERNET-DRAFT                                                Alcatel
                                                        Ken Morneault
                                                        Cisco Systems
                                                        Mallesh Kalla
                                                            Telcordia
                                                      Greg Sidebottom
                                                      Nortel Networks
                                                            Ram Dantu
                                                             IPmobile
                                                              
Expires September 2000                                 March 10, 2000


                  SS7 MTP2-User Peer-to-Peer Adaptation Layer
                  <draft-george-sigtran-m2peer-00.txt>


Status of This Memo

This document is an Internet-Draft and is in full conformance with all 
provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as 'work in progress.'

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

To learn the current status of any Internet-Draft, please check the
'1id-abstracts.txt' listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).














George, et al                                               [Page  1]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000


Abstract

This Internet Draft defines a protocol for adapting the SS7 MTP2 User
for signaling over an IP connection using the Simple Control
Transmission Protocol (SCTP).  This protocol is used between SS7
Signaling Points equipped with an IP connection (IPSPs). Signaling
points using this protocol are capable of MTP Level 3 routing. This
protocol may be used in a Signaling Gateway (SG). The SG receives SS7
signaling over a standard SS7 interface using the SS7 Message Transfer
Part (MTP) to provide transport, and has the capability to use MTP to
route signaling to IPSPs. The protocol thereby retains the features of
MTP Level 3, including Network Management.








































George, et al                                               [Page  2]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000


                        TABLE OF CONTENTS

1.  Introduction............................................. 4
  1.1  Scope................................................. 4
  1.2  Terminology........................................... 4
  1.3  Signaling Transport Architecture...................... 5
  1.4  Services Provided by the MTP2 User Adaptation Layer... 6
  1.5  Functions Provided by the MTP2 User Adaptation Layer.. 7
  1.6  Definition of the M2UA Boundaries..................... 7
2.  Protocol Elements........................................ 7
  2.1  Common Message Header................................. 8
  2.2  M2UA Messages......................................... 8
3.  Procedures...............................................10
  3.1  Procedures to Support MTP2 Features...................10
  3.2  Procedures to Support the MTP3/MTP2 Interface.........13
4.  Examples of MTP2 User Adaptation (M2UA) Procedures.......14
  4.1  Link Initialization (Alignment).......................15
  4.2  Message Transmission and Reception....................17
  4.3  Link Status Indication................................17
  4.4  Link Status Message (Processor Outage)................18
  4.5  Congestion Notification to Upper layer................19
  4.6  Link Deactivation.....................................20
  4.7  Link Changeover.......................................21
5.  Security.................................................22
6.  Acknowledgements.........................................22
7.  References...............................................22
8.  Author's Addresses.......................................22

























George, et al                                               [Page  3]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000


1. Introduction

1.1 Scope

There is a need for SCN signaling protocol delivery from an Signaling
Gateway (SG) to an IP Signaling Point (IPSP).  In other words, the
Signaling Gateway will transport MTP Level 3 messages to an IPSP.

The delivery mechanism should

*  Support the MTP Level 2 / MTP Level 3 interface boundary
*  Provide for peer-to-peer communication similar to that 
   provided by MTP Level 2.

The SG and IPSP function as traditional SS7 nodes using the IP network
as a new type of SS7 link.  This allows for full MTP Level 3 message
handling and network management capabilities.

Throughout this document, M2UA is used to refer to the MTP 2 User
Peer-to-Peer case. This should not be confused with the MTP 2 User
Backhauling case described in [6].


1.2 Terminology

MTP - The Message Transfer Part of the SS7 protocol [2]. 

MTP2 - MTP Level 2, the signaling network layer.

MTP3 - MTP Level 3, the MTP signaling link layer.

MTP2-User - A protocol that normally uses the services of MTP Level
2. The only MTP2 user is MTP3.

Signaling End Point (SEP) - A node in an SS7 network that originates
or terminates signaling messages.  One example is a central office
switch.

IP Signaling Point (IPSP) - An SS7 Signaling Point with an IP
connection used for SS7 over IP. An IPSP may or may not have a
traditional (non-IP) SS7 link.

Signaling Gateway - An SS7 Signaling Point that has both an IP
connection used for SS7 over IP, and a traditional (non-IP) link to an
SS7 network.

Signaling Transfer Point (STP) - A node in an SS7 network that routes
signaling messages based on their destination point code in the SS7
network.

Association - An association refers to a SCTP association [5].

George, et al                                               [Page  4]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000

Stream - A stream refers to a SCTP stream [5].  


1.3 Signaling Transport Architecture

The architecture that has been defined [4] for SCN signaling transport
over IP uses multiple components, including an IP transport protocol,
the Simple Control Transmission Protocol (SCTP) and an adaptation
module to support the functions expected by a particular SCN signaling
protocol from its underlying protocol layer.

In reference to the SIGTRAN framework architecture [4], this document 
defines a SCN adaptation module that is suitable for the transport of 
SS7 MTP2 User.  The only SS7 MTP2 User is MTP3.

Figure 1 shows the seamless interworking at the MTP3 layer.  MTP3 is
adapted to the SCTP layer using the MTP2 User Adaptation Layer (M2UA).
All the primitives between MTP3 and MTP2 are supported by M2UA.  The
SCTP association acts as an SS7 link between the SG and the IPSP. The
association contains two streams, one in each direction.

In this example, the Signaling Gateway could be an STP.  Any of the
nodes in the diagram could have SCCP or other SS7 user parts. STPs may
or may not be present in the SS7 path between the SEP and the SG. The
IPSP may or may not have a termination to the SS7 network.


    ********  SS7   ***************   IP   ***************
    * SEP  *--------*     SG      *--------*    IPSP     *
    ********        ***************        ***************

    +------+                               +-------------+
    | TCAP |                               |    TCAP     |
    +------+                               +-------------+
    | SCCP |                               |    SCCP     |
    +------+        +-------------+        +-------------+
    | MTP3 |        |    MTP3     |        |    MTP3     | 
    +------+        +------+------+        +------+------+    
    | MTP2 |        | MTP2 | M2UA |        | M2UA | MTP2 |    
    +------+        +------+------+        +------+------+    
    | MTP1 |        | MTP1 | SCTP |        | SCTP | MTP1 | 
    |      |        |      +------+        +------+      |
    |      |        |      | IP   |        | IP   |      |
    +------+        +------+------+        +------+------+

    SEP   - SS7 Signaling Endpoint
    IP    - Internet Protocol
    IPSP  - IP Signaling Point
    SCTP  - Simple Control Transmission Protocol  
            (see Reference [5])

         Figure 1:  M2UA Symmetrical Peer-to-Peer Architecture

George, et al                                               [Page  5]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000



Figure 1 is only an example. Other configurations are possible. For
example, IPSPs without traditional SS7 links could use the protocol
layers MTP3/M2UA/SCTP/IP to route SS7 messages in a network with all
IP links.

1.3.1  UDP port

A request will be made to IANA to assign a UDP port for M2UA
peer-to-peer.

1.4 Services Provided by the MTP2 User Adaptation Layer

The SS7 MTP3/MTP2 (MTP2-User) interface is retained at the termination
point in the IP network. The M2UA protocol layer is required to
provide the equivalent set of services to its user as provided by MTP
Level 2 to MTP Level 3.

These services are described in the following subsections.

1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary

This interface is the same as the MTP2/MTP3 interface described in
[2], with the following exception:

* The interface must support the larger sequence numbers used by 
  SCTP. Reference [7] can be used as a guide for the MTP3 changes.

1.4.2 Support for peer-to-peer communication

In SS7, MTP Level 2 sends three types of messages, known as signal
units: Message Signal Units (MSUs), Link Status Signal Units (LSSUs),
and Fill-In Signal Units (FISUs).

MSUs originate at a higher level than MTP2, and are destined for a
peer at another node. Likewise, M2UA passes these messages from MTP3
to SCTP as data for transport across a link.

LSSUs allow peer MTP2 layers to exchange status
information. Analogous messages are needed for M2UA.

FISUs are sent when no other signal units are waiting to be sent. It
is unnecessary for M2UA to send FISUs, since their purpose is served
by the heartbeat messages in SCTP.

To perform the function of MTP2 in traditional SS7, the following
protocol element is defined.

Link Status

Provides a means for asychronous notification of link state to an M2UA

George, et al                                               [Page  6]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000

peer.  An example would be the reporting of a local processor outage.


1.5 Functions Provided by the MTP2 User Adaptation Layer

1.5.1 Mapping

The M2UA layer must maintain a map of an SS7 link to an SCTP
association and to a stream within the association. The M2UA layer
must also maintain a map of an SS7 link to its corresponding IP
destination.
 
1.5.2 Flow Control / Congestion

It is possible for the M2UA layer to be informed of IP network
congestion by implementation-dependent means (e.g., an indication from
SCTP).  If the M2UA layer receives this indication, it notifies MTP3
so that MTP3 can invoke its congestion procedures. 

1.5.3 SCTP Stream Management

SCTP allows user specified number of streams to be opened during the
initialization.  It is the responsibility of the M2UA layer to ensure
proper management of the two streams allowed within each association.

1.5.4  Retention of MTP3 in the SS7 Network 

M2UA allows MTP3 to perform all of its Message Handling and Network
Management functions with IPSPs as with other SS7 nodes.


1.6 Definition of the M2UA Boundaries

1.6.1 Definition of the M2UA / MTP Level 3 boundary

The upper layer primitives provided by M2UA are the same as those
provided by MTP2 to MTP3 [2].

1.6.2 Definition of the Lower Layer Boundary between M2UA and SCTP

The upper layer and layer management primitives provided by SCTP are 
described in Reference [5] Section 9.


2.  Protocol Elements

This section describes the format of various messages used in this 
protocol.

All fields in an M2UA message must be transmitted in the network byte
order, i.e., most significant byte first, unless otherwise stated.


George, et al                                               [Page  7]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000


2.1 Common Message Header

The protocol messages for MTP2 User Adaptation require a message
header structure which contains a version, message type and message
length.  This message header is common among all SCN adaptation
layers. The header structure is shown in Figure 2.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |     Spare     |         Message Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Message Length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |


                 Figure 2:  Common Message Header


2.1.1  Version

The version field (vers) contains the version of the M2UA adapation 
layer.  The supported versions are:

      01   Release 1.0 of M2UA adaptation protocol

2.1.2  Message Type

The valid message types are defined below and the message contents are
described in Section 2.2.  Each message can contain parameters.

The following list contains the message types for the defined messages.


     MTP2 User Adaptatation Messages

        Data                     0601
        Link Status              0602

       
2.1.3  Message Length

The Message length defines the length of the message in octets, not 
including the header.


2.2 M2UA Messages

The following section defines the messages and parameter contents.  The

George, et al                                               [Page  8]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000

M2UA messages will use the command header and the M2UA specific header.

2.2.1 Data 

The Data message contains an SS7 MTP2-User message.  It is the
equivalent of a Message Signal Unit in MTP. The format for the Data
message is as follows:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   ...
   |                         Protocol Data                         |
                                   ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Note that the Protocol Data field contains only the MTP2-User
application message. The header transmitted by MTP2 (which includes
the Flag, BSN, BIB, FSN, FIB, LI) is not included in M2UA.

2.2.2  Link Status

The MTP2 Link Status message can be sent between M2UA peers to
indicate link status. It is the equivalent of the Link Status Signal
Unit in MTP.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            State                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The valid values for State are shown in the following table. All
values defined in the MTP2 Link Status Signal Unit have an equivalent
in this M2UA Link Status message. This does not imply that all values
must be used by M2UA.

   Define    Value  Description
		     
   STATUS_O   0x0   Status indication O  - Out of alignment
   STATUS_N   0x1   Status indication N  - Normal alignment status
   STATUS_E   0x2   Status indication E  - Emergency alignment status
   STATUS_OS  0x3   Status indication OS - Out of Service
   STATUS_PO  0x4   Status indication PO - Processor Outage
   STATUS_B   0x5   Status indication B  - Busy




George, et al                                               [Page  9]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000

3.  Procedures

3.1 Procedures to Support MTP2 Features

3.1.1 Signal Unit Format, Delimitation, Acceptance

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

SCTP provides message delimitation, sequence numbering, and error
correction. Therefore the header transmitted by MTP2 (which includes
the Flag, BSN, BIB, FSN, FIB, LI) is not needed in M2UA.

3.1.2 Link Alignment

MTP3 can request that an SS7 link be brought into alignment ([2]
Q.703, section 7).  During alignment, communication to the other end
of the link is tested for a period of time to make sure that the link
is ready for traffic. Once the link is aligned, proving begins. During
proving, messages are sent from both ends of the link to verify that
the link is capable of sustaining traffic. 

Proving may take place for a Normal or (shorter) Emergency time
period. MTP3 determines whether the alignment procedure is Normal or
Emergency, and informs M2UA through the Emergency and Emergency Ceases
commands.

To begin alignment in M2UA, M2UA sends the Associate primitive to
SCTP. The association shall contain one stream in each direction. If
SCTP fails to establish the association, M2UA shall report to MTP3
that the link is out of service.

Once the association is established, M2UA sends Link Status SIO to its
peer at an implementation-dependent rate. If the remote end sends a
Link Status of SIN, SIE, or SIO before time interval T2 elapses, the
link is in an aligned state. If the remote end does not send one of
those Link Status messages before T2, M2UA shall report to MTP3 that
the link is out of service.

When the link gets to an aligned state, M2UA sends Link Status SIN or
SIE (for Normal or Emergency proving) at an implementation-dependent
rate. If the remote end sends a Link Status of SIN, SIE, or SIO before
time interval T3 elapses, the link is in proving state. If the remote
end does not send one of those Link Status messages before T3, M2UA
shall report to MTP3 that the link is out of service.

While in the proving state, M2UA continues to send SIN/SIEs for a
period of T4. If T4 elapses and the link has not failed, proving is
complete. The link is ready for traffic.

When proving is complete, M2UA may send a Status primitive to SCTP to
determine if the smoothed round-trip time and other status data are

George, et al                                              [Page  10]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000

acceptable. Sending of the Status primitive is optional. Use of the
Status information is implementation dependent.

3.1.3 Processor Outage

A processor outage occurs when M2UA cannot transfer messages to MTP3.

When M2UA detects a local processor outage (e.g., by receiving a 
Local Processor Outage from MTP3), it sends a Link Status message to 
its peer with status PO. It discards any messages received.

The peer M2UA, upon receiving the Link Status PO message, notifies 
its MTP3. It ceases sending Data messages.

When the processor outage ceases, MTP3 sends a Local Processor 
Recovered indication to M2UA. The local M2UA notifies its peer by 
sending the next Data message. The peer notifies its MTP3 that the 
remote processor outage has ceased.

3.1.4 Level 2 Flow Control

Congestion control is provided by SCTP. Any congestion control 
procedures in M2UA are implementation dependent.

MTP3 expects notification of link congestion.  For example, this is
accomplished by two messages 1) Link Congestion Onset 2) Link
Congestion Abated.  For example, congestion could be detected if M2UA
receives a failure response when it attempts to send a message to SCTP
(this is implementation dependent, and it is assumed that the SEND
Failure has an error code that indicates congestion).  M2UA reports
Link Congestion Onset to MTP3. Subsequently M2UA can poll the status
of SCTP.  When SCTP is no longer congested, M2UA reports Link
Congestion Abated to MTP3. If the congestion condition should
continue, the link will be taken out of service.  In this case, it is
possible to start the link changeover procedure.

The US National version of SS7 has congestion levels [3]. For US
National SS7, the Indication primitive for Congestion Onset should
report the congestion level.

3.1.5 Error monitoring

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

3.1.6 MTP2 Timers in M2UA

This section explains which MTP2 timers are needed in M2UA.

3.1.6.1  T2 Not Aligned, T3 Aligned

Timers T2 and T3 are used to verify that the other end of the link is

George, et al                                              [Page  11]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000

communicating. In MTP2, if either of timers T2 or T3 expire, alignment
is not possible, so MTP2 reports to MTP3 that the link is out of
service ([2] Q.703, Figures 8 and 9).

Timer T2 is used to verify that the remote end responds to the initial
attempt to align the link. Timer T3 is used to verify that the remote
end is proving the link along with the local end. 

Both timers T2 Not Aligned and T3 Aligned are implemented in M2UA.

Recommended value of T2 is 5-150 seconds.
Recommended value of T3 is 1-2 seconds.

3.1.6.2  T4 Proving Period

Since M2UA directs the Proving procedure, timer T4 Proving Period is
implemented in M2UA as in MTP2.

Recommended values are:

    normal proving period: 7.5-9.5 seconds
    emergency proving period: 400-600 milliseconds

3.1.6.3  T1 Alignment Ready

In MTP2, timer T1 is started when alignment is complete. If T1 expires
before an MSU or FISU is received, MTP2 LSC reports to MTP3 that the
link is out of service ([2] Q.703, Figure 8).

M2UA does not send FISUs. The purpose of FISUs is served by the
Heartbeats in SCTP. SCTP uses the Heartbeats to determine if
communication has been lost on the connection.  M2UA does not need to
verify that the link is in service. Therefore it is not necessary to
implement timer T1 in M2UA.

3.1.6.4  T5 Sending SIB

Since SCTP provides congestion control, it is not necessary to
implement timer T5 in M2UA.

3.1.6.5  T6 Remote Congestion

MTP2 uses T6 to determine if a link has been congested so long that it
should be failed.

Since SCTP determines when an association has failed, it is not
necessary to implement timer T6 in M2UA.

3.1.6.6  T7 Excessive Delay of Acknowledgement

SCTP performs acknowledgements and retransmissions. Therefore it is
not necessary to implement timer T7 in M2UA.

George, et al                                              [Page  12]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000



3.2 Procedures to Support the MTP3/MTP2 Interface

3.2.1  Sending/receiving messages

If MTP3 sends a message for transmission to M2UA, M2UA adds the M2UA 
header to the message, then passes the message to SCTP using the SEND 
primitive.

If M2UA receives a Data message from SCTP, M2UA removes the M2UA 
header and passes the message to MTP3.

3.2.2  Link activation and restoration

If MTP3 requests that M2UA activate or restore a link by a Start 
command, M2UA shall follow the alignment procedure in section 3.1.2.

3.2.3  Link deactivation

If MTP3 requests that M2UA deactivate a link by a Stop command, M2UA 
shall send a TERMINATE primitive to SCTP.

3.2.4  Flush buffers

The Flush Buffers request from MTP3 is not supported by SCTP.

3.2.5 Changeover

The objective of the changeover is to ensure that signaling traffic
carried by the unavailable signaling link is diverted to the
alternative signaling link as quickly as possible while avoiding
message loss, duplication, or mis-sequencing.  For this purpose, the
changeover procedure includes data retrieval, which is performed
before reopening the alternative signaling links to the diverted
traffic.  Data retrieval consists of identifying all those messages in
the retransmission buffer of the unavailable signaling link which have
not been received by the far end.  Retrieval includes transferring the
concerned messages to the transmission buffers of the alternative
links.  In order to support changeover in M2UA, the SCTP Stream
Sequence Numbers must be used in place of the Forward and Backward
Sequence Numbers (FSN/BSN) of SS7.

Stream Sequence Numbers used by SCTP are 16 bits long.  MTP2's Forward
and Backward Sequence Numbers are only seven bits long.  Hence it is
necessary to modify MTP3 to accomodate the larger SSNs.  Reference [7]
section 9.8.1 should be used as a guide for the MTP3 changes. Only the
Extended Changeover Order and Extended Changeover Acknowledgement
messages from [7] are used. These messages have a 24-bit field for the
sequence number. The upper 8 bits of the 24 bit field should be set to
0, and the SSN placed in the lower 16 bits.


George, et al                                              [Page  13]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000

For data retrieval, MTP3 requests Backward Sequence Number (BSN) from
M2UA.  This is the sequence number of the last message received by the
local end.  During normal period, SCTP delivers ordered messages to
the application.  However, during congestion or failure condition, the
sequence numbers of the acknowledged messages can have gaps.  In
particular, the SACK (selective acknowledgement message) message can
have several of these gaps.  Hence, it is important to scan through
these gaps and find the sequence number before first gap.  This is the
number from which the remote end has to transmit the messages.  So
this is the number considered as the Backward Sequence Number and
communicated to the remote end.  In a similar way, the remote end also
detects the BSN and indicates to the local end. As soon as the MTP3 of
the local end receives this BSN, MTP3 retrieves all the unacknowledged
messages starting from BSN.  This is accomplished through a Retrieve
FSN request.  After all the messages are sent from M2UA to MTP3, a
Retrieval Complete indication is sent.

Note that the sequence numbers and messages requested by MTP3 are sent
from SCTP to M2UA in the Communication Lost primitive. Retrieval of
messages is an optional feature in SCTP. To perform data retrieval, it
is necessary that this option be implemented, and that the SSNs of the
messages are identified.


4.  Examples of MTP2 User Adaptation (M2UA) Procedures

In general, messages passed between MTP3 and M2UA are the same as
those passed between MTP3 and MTP2.  M2UA interprets messages from MTP3
and sends the appropriate message to SCTP. Likewise, messages from
SCTP are used to generate a meaningful message to MTP3.

Note that throughout this section, the primitives between MTP3 and
M2UA are named using the MTP terminology [1][2]. Communications
between M2UA and SCTP are named using SCTP terminology.



















George, et al                                              [Page  14]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000

4.1  Link Initialization (Alignment)

An example of the message flow to bring an SS7 link in-service is
shown below. Proving is done by both ends of the link. To simplify the
diagram, proving is shown on one end only.


    MTP3        M2UA        SCTP        SCTP        M2UA        MTP3
    ----        ----        ----        ----        ----        ----

     Out of Service
     <------------

     Emergency OR
     Emergency Ceases
     ------------>

     Start
     ------------>

                 Associate
                 ------------>

                             (SCTP Association
                              procedure)

                 Communication Up        Communication Up
                 <------------           ------------>


Even though the SCTP association is established, it is important that
M2UA not send MTP3 data at this point. It must be confirmed that both
ends of the link are ready for traffic. Otherwise, messages could be
lost. Therefore proving begins at this time:



















George, et al                                              [Page  15]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000


    MTP3        M2UA        SCTP        SCTP        M2UA        MTP3
    ----        ----        ----        ----        ----        ----

                 Link Status SIO
                 ------------------------------------>

                                       Link Status SIN
                 <------------------------------------

                 Link Status SIN
                 ------------------------------------>

                                       Link Status SIN
                 <------------------------------------

                 Link Status SIN
                 ------------------------------------>
                 ------------------------------------>
                 ------------------------------------>
                 :
                 ------------------------------------>

                 Link Status SIN messages are sent for M seconds 
                 (see Note A).

                 Status
                 ------------>

     Indication
     (Link In Service) 
     <------------

Note A: Timer value M is implementation-dependent.

At this point, MTP3 may begin sending data messages.

















George, et al                                              [Page  16]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000

4.2  Message Transmission and Reception

Messages are transmitted using the Data Request primitive from MTP3 to
M2UA. The diagram shows the case where the Link is In Service. The
message is passed from MTP3 of the source to MTP3 of the destination.


    MTP3        M2UA        SCTP        SCTP        M2UA        MTP3
    ----        ----        ----        ----        ----        ----

     Message for 
     transmission
     ------------>

                 Send
                 (Data Message)
                 ------------>

                             (SCTP sends message)

                                         Receive
                                         ------------>

                                                  Received message
                                                     ------------>


4.3  Link Status Indication

If SCTP sends a Communication Lost primitive to M2UA, M2UA notifies
MTP3 that the link is out of service. MTP3 responds in its usual way.


    MTP3        M2UA        SCTP        SCTP        M2UA        MTP3
    ----        ----        ----        ----        ----        ----

                 Communication Lost
                 <------------

     Link Out 
     of Service
     <------------











George, et al                                              [Page  17]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000

4.4  Link Status Message (Processor Outage)

This example shows how M2UA responds to a local processor outage. MTP3
notifies M2UA of the outage by a Request primitive. M2UA sends a Link
Status message to its peer. The peer M2UA notifies MTP3 of the
outage. MTP3 can then follow the processor outage procedures in [2].


    MTP3        M2UA        SCTP        SCTP        M2UA        MTP3
    ----        ----        ----        ----        ----        ----

     Local Processor 
     Outage
     ------------>

                 Link Status
                 ------------>

                             (SCTP sends message)

                                         Receive
                                         ------------>

                                                  Remote Processor
                                                  Outage
                                                     ------------>



























George, et al                                              [Page  18]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000

4.5  Congestion Notification to Upper layer

MTP3 layer expects notification of the link congestion.  For example,
this is accomplished by two messages 1) Link Congestion Onset 2) Link
Congestion Abated.  Congestion is assumed if M2UA layer notices
repeated failures to send requests to SCTP (this is implementation
dependent and it is assumed that the SEND Failure has an error code
"life time expired").  Subsequently M2UA can start polling status of
SCTP.  If all the messages are successfully transmitted over a period
of time (implementation dependent) then it is assumed that the
congestion is abated.  If the congestion condition should continue,
the link will be taken out of service.  In this case, it is possible
to start the link changeover procedure.

The US National version of SS7 has congestion levels. For US National
SS7, the Indication primitive for Congestion Onset should report the
congestion level.

In the example below, M2UA has sent a message to SCTP.


    MTP3        M2UA        SCTP        SCTP        M2UA        MTP3
    ----        ----        ----        ----        ----        ----

                 Implementation dependent 
                 indication of congestion 
                 <------------

     Congestion Onset
     <------------

                 Status
                 ------------>
                 Status
                 ------------>
                 :
                 :
                 Status
                 ------------>
                 polled for certain time until
                 congestion ceases -
                 implementation dependent

     Congestion Abatement
     <------------








George, et al                                              [Page  19]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000

4.6  Link Deactivation

The MTP3 can request that a SS7-IP link be taken out-of-service.  It
uses the Release Request message as shown below.


    MTP3        M2UA        SCTP        SCTP        M2UA        MTP3
    ----        ----        ----        ----        ----        ----

     Stop
     ------------>

                 Terminate
                 ------------>

                           (SCTP performs its
                           termination procedure)

                 Communication Lost
                 <------------

     Link Out of Service
     <------------






























George, et al                                              [Page  20]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000

4.7  Link Changeover

In this example, MTP3 performs a changeover because the link went out
of service. MTP3 selects a different link for retransmitting the
unacknowledged messages.

Note that the sequence numbers and messages requested by MTP3 are sent
from SCTP to M2UA in the Communication Lost primitive.


    MTP3        M2UA        SCTP        SCTP        M2UA        MTP3
    ----        ----        ----        ----        ----        ----

                 Communication Lost
                 <------------

     Link Out of Service
     <------------

     Retrieve BSN
     ------------>

                 (M2UA locates
                  first gap in
                  received messages)

     Indicate BSN
     <------------


     XCO (BSN) on another link
     ------------------------------------------------------------>

                                                      Retrieve BSN
                                                     <------------

                                                      Indicate BSN
                                                     ------------>

                                                         XCA (BSN)
     <------------------------------------------------------------

     Retrieve FSN
     ------------>

                 (M2UA locates
                  first gap in
                  acknowledgements)

     Retrieved Message
     <------------
     

George, et al                                              [Page  21]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000

     Retrieved Message
     <------------

     Retrieval Complete
     <------------

     Send messages on another link.


5. Security

SCN adaptation layers rely on SCTP to provide security.
 

6.  Acknowledgements

The authors would like to thank Ian Rytina and HannsJuergen
Schwarzbauer for their valuable comments and suggestions.


7.  References

[1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling 
    System No. 7 (SS7)'

[2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 
    (SS7) - Message Transfer Part (MTP)'

[3] Bellcore GR-246-CORE 'Bell Communications Research Specification
    of Signaling System Number 7', Volume 1, December 1995

[4] RFC 2719, Framework Architecture for Signaling Transport, 
    October 1999

[5] Simple Control Transmission Protocol,
    draft-ietf-sigtran-sctp-07.txt, March 2000

[6] SS7 MTP2-User Adaptation Layer, draft-ietf-sigtran-m2ua-00.txt, 
    March 2000

[7] ITU-T Recommendation Q.2210, 'Message transfer part level 3
    functions and messages using the services of ITU-T 
    Recommendation Q.2140'


8.  Author's Addresses

Tom George                                        Tel: +1-972-519-3168
Alcatel USA                          EMail: tom.george@usa.alcatel.com
1000 Coit Road          
Plano, TX 75075    
USA

George, et al                                              [Page  22]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  Mar 2000

Ken Morneault                                     Tel: +1-703-484-3323
Cisco Systems Inc.                           EMail: kmorneau@cisco.com
13615 Dulles Technology Drive
Herndon, VA. 20171
USA

Malleswar Kalla                                   Tel: +1-973-829-5212
Telcordia Technologies             EMail: kalla@research.telcordia.com
MCC 1J211R
445 South Street
Morristown, NJ 07960
USA

Greg Sidebottom                                   Tel: +1-613-763-7305
Nortel Networks                     EMail: gregside@nortelnetworks.com
3685 Richmond Rd,
Nepean, Ontario 
Canada  K2H5B7

Ram Dantu, Ph.D.                    Tel: +1-972-234-6070 extension 211
IPmobile                                    EMail: rdantu@ipmobile.com
1651 North Glenville, Suite 216
Richardson, TX 75081
USA

This Internet Draft expires September 2000.



























George, et al                                              [Page  23]

