[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 RFC 3331

Network Working Group                                   Ken Morneault
INTERNET-DRAFT                                          Cisco Systems
                                                        Mallesh Kalla
                                                            Telcordia
                                                      Greg Sidebottom
                                                      Nortel Networks
                                                            Ram Dantu
                                                              Alcatel


Expires in six months                                   October 1999



                  SS7 MTP2-User Adaptation Layer
                  <draft-ietf-sigtran-m2ua-01.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).




Abstract

This Internet Draft defines a protocol for backhauling of SS7 MTP2
User signaling messages over IP using the Simple Control Transmission
Protocol (SCTP).  One application of this protocol would be to use it
between a Signaling Gateway (SG) and Media Gateway Controller (MGC).
In this case, the Signaling Gateway would be acting as a Signaling
Link Terminal.  Another application of this protocol would be to use
it between a SG and a SCP.  In either application, it is assumed that
the SG receives SS7 signaling over a standard SS7 interface using the
SS7 Message Transfer Part (MTP) to provide transport.


Morneault, et al                                                [Page 1]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999


                        TABLE OF CONTENTS

1.  Introduction..............................................2
  1.1  Scope..................................................2
  1.2  Terminology............................................3
  1.3  Signaling Transport Architecture.......................3
  1.4  Services Provide by the M2UA Adaptation Layer..........4
  1.5  Function Provided by the M2UA Layer....................6
  1.6  Definition of the M2UA Boundaries......................7
2.  Protocol Elements.........................................8
  2.1  Common Message Header..................................8
  2.2  M2UA Message Header....................................9
  2.3  M2UA Messages.........................................10
3.  Procedures...............................................17
  3.1  Procedures to Support Service in Section 1.4.1........17
  3.2  Procedures to Support Service in Section 1.4.2........17
  3.3  Procedures to Support Service in Section 1.4.3........17
4.  Examples of MTP2 User Adaptation (M2UA) Procedures.......22
  4.1  Establishment of associations between SG and MGC......22
       examples
  4.2  MTP Level 2 / MTP Level 3 Boundary Examples...........23
  4.3 Layer Management Communication Examples................25
5.  Security.................................................31
6.  Acknowledgements.........................................31
7.  References...............................................31
8.  Author's Addresses.......................................32




1.  Introduction

1.1 Scope

There is a need for SCN signaling protocol delivery from an Signaling
Gateway (SG) to a Media Gateway Controller (MGC) or Signaling Control
Point (SCP).  The delivery mechanism should meet the following criteria:

*  Support for MTP Level 2 / MTP Level 3 interface boundary
*  Support for communication between Layer Management modules on SG and
   MGC
*  Support for management of active associations between the SG and MGC

In other words, the Signaling Gateway will transport MTP Level 3 messages
to a Media Gateway Controller (MGC) or Signaling Control Point (SCP).






Morneault, et al                                                [Page 2]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999


1.2 Terminology

MTP2-User - A protocol that normally uses the services of MTP Level 2
(i.e. MTP3).

Interface - For the purposes of this document, an interface is a SS7
signaling link.

Association - An association refers to a SCTP association.  The
association will provide the transport for the delivery of protocol
data units for one or more interfaces.

Stream - A stream refers to a SCTP stream.  For the purposes of this
document, a stream will be mapped to a SS7 signaling link, or interface.

Backhaul - Refers to the transport of signaling from the point of
interface for the associated data stream (i.e., SG function in the MGU)
back to the point of call processing (i.e., the MGCU), if this is not
local [4].

Application Server (AS) - A logical entity serving a specific application
instance.  An example of an Application Server is a MGC handling the
MTP Level 3 and call processing for SS7 links terminated by the Signaling
Gateways.  Practically speaking, an AS is modeled at the SG as an ordered
list of one or more related Application Server Processes (e.g., primary,
secondary, tertiary, €).

Application Server Process (ASP) - A process instance of an Application
Server.  Examples of Application Server Processes are primary or backup
MGC instances.

Application Server Process Path (ASP Path or just Path) - A Path to a
remote Application Server Process instance.  A Path maps 1:1 to an SCTP
association.

Fail-over - The capability to re-route signaling traffic as required
to a next-preferred Application Server Process within an Application
Server in the event of failure or unavailability of the currently used
Application Server Process (e.g., from primary MGC to back-up MGC).
Fail-over may also apply upon the return to service of a previously
unavailable Application Server Process.

Signaling Link Terminal (SLT) - Refers to the means of performing all
of the functions defined at MTP level 2 regardless of their
implementation [2].






Morneault, et al                                                [Page 3]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

1.3 Signaling Transport Architecture

The architecture that has been defined for SCN signaling transport
over IP uses multiple components, including an IP transport
protocol, a signaling common transport 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.

1.3.1  Case 1:  SG to MGC

In a Signaling Gateway, it is expected that the SS7 signaling is
received over a standard SS7 network termination, using the SS7 Message
Transfer Part (MTP) to provide transport of SS7 signaling messages to
and from an SS7 Signaling End Point (SEP) or SS7 Signaling Transfer
Point (STP).  In other words, the SG acts as a Signaling Link Terminal
(SLT) [2].  The SG then provides interworking of transport functions
with IP Signaling Transport, in order to transport the MTP3 signaling
messages to the MGC where the peer MTP3 protocol layer exists, as shown
below:

    ******    SS7    ******      IP     *******
    *SEP *-----------* SG *-------------* MGC *
    ******           ******             *******

                                        +----+
                                        |S7UP|
                                        +----+
    +----+                              |MTP |
    |S7UP|                              |L3  |
    +----+         +----+----+          +----+
    |MTP |         |MTP |M2UA|          |M2UA|
    |L3  |         |    +----+          +----+
    |L2  |         |L2  |SCTP|          |SCTP|
    |L1  |         |L1  +----+          +----+
    |    |         |    |UDP |          |UDP |
    +----+         +---------+          +----+

    SEP  - SS7 Signaling Endpoint
    UDP  - User Datagram Protocol
    SCTP  - Simple Control Transmission Protocol
           (Refer to Reference [5])

      Figure 1:  M2UA in the SG to MGC Application

Note: STPs may be present in the SS7 path between the SEP and the SG.





Morneault, et al                                                [Page 4]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

1.3.2  Case 2:  SG to IPSCP

The following figure shows the seamless interworking at MTP3 layer.
MTP3 is adapted to SCTP layer using MTP2 User Adaptation Layer.  In this
example, the Signaling Gateway can be a STP.  All the primitives between
MTP3 and MTP2 are supported using MTP2 User Adaptation Layer (MTP2UA).
In the following example, the Signaling Gateway could also have SCCP
layer for providing Gateway Screening functionality for the IPSCP.

    ******  SS7  ******     IP      ************
    *SEP *-------* SG *-------------*   IPSCP  *
    ******       ******             ************

    +----+                           +---------+
    |TCAP|                           |   TCAP  |
    +----+                           +---------+
    |SCCP|                           |   SCCP  |
    +----+    +---------+            +---------+
    |MTP |    |   MTP   |            |   MTP   |
    |L3  |    |   L3    |            |    L3   |
    |L2  |    +----+----+            +----+----+
    |L1  |    |MTP |M2UA|            |M2UA|MTP |
    |    |    |L2  +----+            +----+L2  |
    |    |    |L1  |SCTP|            |SCTP|L1  |
    |    |    |    |----|            |----|    |
    |    |    |    |UDP |            |UDP |    |
    +----+    +----+----+            +----+----+

    SEP   - SS7 Signaling Endpoint
    IPSCP - IP Signaling Control Point
    UDP   - User Datagram Protocol
    SCTP  - Simple Control Transmission Protocol
            (Refer to Reference [5])

      Figure 2:  M2UA in the SG to IPSCP Application

Note that in this case, the SCTP association acts as a SS7 link between
the SG and IPSCP.  The IPSCP may or may not have a termination to the
SS7 network.

1.3.3  UDP port

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

1.4  Services Provided by the M2UA Adaptation Layer

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



Morneault, et al                                                [Page 5]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

This includes the following services:

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

Also provision is made for protocol elements that enable a seamless, or
as seamless as possible, operation of the MTP2-User peers in the SS7 and
IP domains.  This includes

Data

Provides the ability to transport MTP2 User information (in this case,
MTP Level 3 PDUs).

Link Establish

Provides the ability to request MTP Level 2 to bring SS7 links
in-service.

Link Release

Provides the ability to request MTP Level 2 to take SS7 links out-of-
service.  Also, provides mechanism for MTP2 to autonomously indicate
that SS7 link(s) have gone out-of-service.

Link State

Provides the ability to request state change or information on a
per link basis.  Some examples would be the forcing of Local Processor
Outage or flushing buffers.

Link Status

Provides a means for asychronous notification of link state changes to
be reported to the upper layer (MTP Level 3).  An examples would be the
reporting of remote processor
outage event.

Data Retrieval

Provides a mechanism to perform SS7 link changeover procedure in
the case of a SS7 link failure.

1.4.2  Support for communication between Layer Management modules
       on SG and MGC

It is envisioned that the M2UA layer needs to provide some messages that
will facilitate communication between Layer Management modules on the SG
and MGC.

To facilitate reporting of errors that arise because of backhauling MTP
Level 3 scenario, the following primitive is defined:


Morneault, et al                                                [Page 6]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

M-ERROR

The M-ERROR message is used to indicate an error with a received
M2UA message (e.g., interface identifier value is not known to the SG).

1.4.3  Support for management of active associations between SG and MGC

The M2UA layer on the SG keeps the state of various ASPs it is associated
with.  A set of primitives between M2UA layer and the Layer Management
are defined below to help the Layer Management manage the association(s)
between the SG and the MGC.

M-SCTP ESTABLISH

The M-SCTP ESTABLISH primitive is used to request, indicate and confirm
the establishment of SCTP association to a peer M2UA node.

The M2UA layer may also need to inform the status of the SCTP
association(s) to the Layer Management.  This can be achieved using
the following primitive.

M-SCTP STATUS

The M-SCTP STATUS primitive is used to request and indicate the status
of underlying SCTP association(s).

The Layer Management may need to inform the M2UA layer of a user status
(i.e., failure, active, etc.), so that messages can be exchanged between
M2UA layer peers to stop traffic to the local M2UA user.  This can be
achieved using the following primitive.

M-ASP STATUS

The M-ASP STATUS primitive is used by the Layer Management to indicate
the status of the local M2UA user to the M2UA layer.

1.5  Functions Provided by the M2UA Layer

1.5.1  Mapping

The M2UA layer must maintain a map of a Interface ID to a physical
interface on the Signaling Gateway.  A physical interface would be a
V.35 line, T1 line/timeslot, E1 line/timeslot, etc.   The M2UA layer
must also maintain a map of Interface ID to SCTP association and to a
stream within the association.








Morneault, et al                                                [Page 7]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

1.5.2  Status of ASPs

The M2UA layer on the Signaling Gateway must maintain the state of one or
more Application Server Process(es) it is associated with.  The state of
an ASP changes because of reception of peer-to-peer messages or reception
of indications from the local SCTP association.  ASP state transition
procedures are described in Section Section 3.3.

1.5.3  Flow Control / Congestion

It is possible for the M2UA layer to be informed of IP network congestion
by means of an implementation-dependent function  (i.e. an indication
from the SCTP).  If the M2UA layer receives this indication, the action(s)
taken are implementation dependent.

1.5.4  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 these streams.  SCTP streams provide a means for
avoiding head of line blocking.  For that reason, a stream will be used
per SS7 signaling link terminated by the Signaling Gateway.  The SS7
signaling link can be identified by the optional Interface Identifier
in the M2UA specific message header (refer to Section 2.2).

1.5.5  Seamless SS7 Network Management Interworking

If the SG loses the SCTP association to the MGC, it should follow
MTP 2 processor outage procedures [2].

1.5.6  Management Inhibit/Uninhibit

Local Management may wish to stop traffic across an SCTP association in
order to temporarily remove the association from service or to perform
testing and maintenance activity.  The function could optionally be used
to manage the start of traffic on to a newly-available SCTP association.

1.6  Definition of the M2UA Boundaries

1.6.1  Definition of the M2UA / MTP Level 3 boundary

DATA
ESTABLISH
RELEASE
STATE
STATUS
RETRIEVAL
DATA RETRIEVAL
DATA RETRIEVAL COMPLETE




Morneault, et al                                                [Page 8]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999


1.6.2  Definition of the M2UA / MTP Level 2 boundary

DATA
ESTABLISH
RELEASE
STATE
STATUS
RETRIEVAL
DATA RETRIEVAL
DATA RETRIEVAL COMPLETE

1.6.3  Definition of the Lower Layer Boundary between M2UA and SCTP

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

1.6.4  Definition of Layer Management / M2UA Boundary

M-ERROR
M-SCTP ESTABLISH
M-SCTP STATUS
M-ASP STATUS


2.0  Protocol Elements

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

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.

    0     7 8    15 16           31
   +---------------+---------------+
   | Vers | Spare  |   Msg 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


Morneault, et al                                                [Page 9]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999


2.1.2  Message Type

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

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

     MTP2 User Adaptatation (MAUP) Messages

        Data Request                               0601
        Data Indication                            0602
        Establish Request                          0603
        Establish Confirm                          0604
        Release Request                            0605
        Release Confirm                            0606
        Release Indication                         0607
        State Request                              0608
        State Confirm                              0609
        State Indication                           060a
        Data Retrieval Request                     060b
        Data Retrieval Confirm                     060c
        Data Retrieval Indication                  060d
        Data Retrieval Complete Indication         060e

     Application Server Process Maintenance (ASPM) Messages

        ASP Up (ASPUP)                             0301
        ASP Down (ASPDN)                           0302
        ASP Active (ASPAC)                         0401
        ASP Inactive (ASPIA)                       0402

     Management (MGMT) Messages

        Error                                      0001

2.1.3  Message Length

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

2.2  M2UA Message Header

In addition to the common message header, there will be a M2UA specific
message header.  The M2UA specific message header will immediately
follow the common message header, but will only be used with MAUP and
MGMT messages.

This message header will contain the Interface Identifier.  The Interface
Identifier identifies the physical interface at the SG for which the
signaling messages are sent/received.  Or, the Interface Identifier

Morneault, et al                                               [Page 10]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999


can be left empty (a null string of length zero).  The Interface Identifier
follows the same endpoint naming scheme provided in MGCP [7].  For example,
if a Signaling Gateway terminates a E1 and the SS7 signaling link is one
timeslot 16, the interface identifier could be the following:

       e1/16@sgw1.example.net

The use of wildcards is not acceptable.

Note:  The Interface Identifier string should be padded to 32-bit
boundaries.  The length field indicates the end of the string.


    0            15 16           31
   +---------------+---------------+
   |   Tag (0x1)   |     Length    |
   +-------------------------------+

   |    Interface Identifier       |

   +-------------------------------+

     Figure 3  M2UA Message Header

The Tag value for Interface Identifier is 0x1.  The length provides the
length of the Interface Identifier string in bytes.

2.3 M2UA Messages

The following section defines the messages and parameter contents.  The
M2UA messages will use the command header and the M2UA specific header.

2.3.1 MTP2 User Adaptation Messages

2.3.1.1 Data (Request, Indication)

The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU).  The
Data message contains the protocol data.

The format for the Data Message parameters is as follows:

    0            15 16           31
   +-------------------------------+
                   ...
   |        Protocol Data          |
                   ...
   +---------------+---------------+


The Protocol Data field contains the MTP2-User application message.


Morneault, et al                                               [Page 11]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

2.3.1.2  Establish (Request, Confirmation)

The Establish Request message is used to establish the channel or to
indicate that the channel has been established.  Note that the gateway
may already have the channel established at its layer.  If so, upon
receipt of an Establish Request, the gateway takes no action except to
send an Establish Confirm.

    0            15 16           31
   +---------------+---------------+
   |             State             |
   +---------------+---------------+

The valid values for State are shown in the following table.

         Define            Value          Description
   ESTABLISH_NORMAL        0x0     Follow normal procedure for
                                    establishing a SS7 link
   ESTABLISH_EMERGENCY     0x1     Follow emergency procedure for
                                    establishing a SS7 link


2.3.1.3  Release (Request, Indication, Confirmation)

This Release Request message is used to release the channel.  The Release
Confirm and Indication messages are used to indicate that the channel has
been released.

    0            15 16           31
   +---------------+---------------+
   |            Reason             |
   +---------------+---------------+

The valid values for Reason are shown in the following table.

      Define     Value           Description
   RELEASE_MGMT   0x0     Management layer generated release.
   RELEASE_PHYS   0x1     Physical layer alarm generated release.
   RELEASE_SIOS   0x2     Receipt of SIOS
   RELEASE_OTHER  0x3     Other reason SS7 link out-of-service

(should we keep it simple, or provide list of reasons that would
enable debugging)

2.3.1.4  State (Request, Confirm)

The State Request message can be sent from a MGC to cause an action
on a particular SS7 link supported by the Signaling Gateway.  The
gateway sends a State Confirm to the MGC if the action has been success-
fully completed.  The State Confirm reflects that state value received
in the State Request message.


Morneault, et al                                               [Page 12]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999


    0            15 16           31
   +---------------+---------------+
   |             State             |
   +---------------+---------------+

The valid values for State are shown in the following table.

         Define           Value        Description
   STATUS_LOC_PROC_SET     0x0      Request local processor outage.
   STATUS_LOC_PROC_CLEAR   0x1      Request local processor outage
                                    recovered.
   STATUS_EMER_SET         0x2      Request emergency alignment
                                    procedure.
   STATUS_EMER_CLEAR       0x3      Request normal alignment (cancel
                                    emergency) procedure.
   STATUS_FLUSH_BUFFERS    0x4      Flush transmit and retransmit buffers.
   STATUS_CONTINUE         0x5      Continue.

2.3.1.5  State Indication

The MTP2 State Indication message can be sent from a gateway to a call
agent to indicate a condition on a channel.

    0            15 16           31
   +---------------+---------------+
   |             State             |
   +---------------+---------------+

The valid values for State are shown in the following table.

       Define            Value          Description
   EVENT_ENTER_LPO        0x0      Entered local processor outage.
   EVENT_EXIT_LPO         0x1      Exited local processor outage.
   EVENT_ENTER_CONG       0x2      Entered a congested state.
   EVENT_EXIT_CONG        0x3      Exited a congested state.
   EVENT_PHYS_UP          0x4      Physical interface up.
   EVENT_PHYS_DOWN        0x5      Physical interface down.
   EVENT_PROTOCOL_ERR     0x6      Protocol error occurred.
   EVENT_REM_ENTER_CONG   0xc      Remote entered congestion.
   EVENT_REM_EXIT_CONG    0xd      Remote exited congestion.
   EVENT_REM_ENTER_PO     0xe      Remote entered processor outage.
   EVENT_REM_EXIT_PO      0xf      Remote exited processor outage.


2.3.1.6  Retrieval (Request, Confirm)

The MTP2 Retrieval Request message is used during the MTP Level 3
changeover procedure to request the BSN, to retrieve PDUs from the
retransmit queue or to flush PDUs from the retransmit queue.



Morneault, et al                                               [Page 13]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

    0            15 16           31
   +---------------+---------------+
   |             Action            |
   +---------------+---------------+
   |            fsn_bsn            |
   +---------------+---------------+

The valid values for Action are shown in the following table.

        Define         Value       Description
   ACTION_RTRV_BSN      0x1     Retrieve the backward sequence number.
   ACTION_RTRV_MSGS     0x2     Retrieve the PDUs from the retransmit
                                queue.
   ACTION_DROP_MSGS     0x3     Drop the PDUs in the retransmit queue.

In the Retrieval Request message, the fsn_bsn field contains the FSN of
the far end if the action is ACTION_RTRV_MSGS.

When the Signaling Gateway sends a Retrieval Confirm to this request,
it echos the action and puts the BSN in the fsn_bsn field if the action
was ACTION_RTRV_BSN.

2.3.1.7  Retrieval Indication

The Retrieval Indication message is sent by the Signaling Gateway
with a PDU from the retransmit queue.  The Retrieval Indication
message does not contain the Action or fsn_bsn fields, just a PDU from
the retransmit queue.

    0            15 16           31
   +---------------+---------------+
   |                               |

   .       PDU from retransmit     .
   .           queue               .

   |                               |
   +---------------+---------------+


2.3.1.8  Retrieval Complete Indication

The MTP2 Retrieval Complete Indication message is exactly the same as
the MTP2 Retrieval Indication message except that it also indicates that
it contains the last PDU from the retransmit queue.

2.3.2  Application Server Process Maintenance (ASPM) Messages

The ASPM messages will only use the common header.




Morneault, et al                                               [Page 14]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

2.3.2.1  ASP UP (ASPUP)

The ASPUP message is used to indicate to a remote M2UA peer that the
layer is ready to receive traffic or maintenance messages.

The ASPUP message contains the following parameters:

     Adaptation Layer Identifer (optional)
     SCN Protocol Identifier (optional)

The Adaptation Layer Identifier is a string that identifies the
adaptation layer.  This string must be set to "M2UA" which means
the length will be 4.

The Protocol Identifier field contains the identity of the specific SCN
signaling protocol being transported.  The Protocol ID defines the
protocol type, variant, and version, and thereby specifies the components
and encoding of the PROTOCOL DATA field.  The Protocol Identifier also
defines what SCN protocol message components are included in the PROTOCOL
DATA.

(Ed. Note: Need encoding of mime-type value or OID or fixed
string/integer that will be administered outside of this document
(IANA). Also, perhaps bring in text from Christian's mime document - See
"draft-ietf-sigtran-mime-isup.txt" for an example of an application/ISUP
media type defined according to the rules defined in RFC 2048.?)

The format for the ASPUP message is as follows:


    0            15 16           31
   +---------------+---------------+
   |   Tag (0x2)   |    Length     |
   +---------------+---------------+

   |  Adaptation Layer Identifier  |

   +---------------+---------------+
   |   Tag (0x3)   |    Length     |
   +---------------+---------------+

   |      Protocol Identifier      |

   +---------------+---------------+
   |   Tag (0x4)   |    Length     |
   +---------------+---------------+

   |          INFO String          |

   +---------------+---------------+

Note:  Strings are padded to 32-bit boundaries.  The length field
indicates the end of the string.

Morneault, et al                                               [Page 15]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

2.3.2.2  ASP Down (ASPDN)

The ASPDN message is used to indicate to a remote M2UA peer that the
layer is not ready to receive traffic or maintenance messages.

The ASPDN message contains the following parameters:

     INFO String

The format for the ASPDN message is as follows:


    0            15 16           31
   +---------------+---------------+
   |   Tag (0x4)   |    Length     |
   +---------------+---------------+

   |          INFO String          |

   +---------------+---------------+

#####
We discussed adding a reason code.  Reason could be failure or
management inhibit.
#####

2.3.2.3  ASP Active (ASPAC)

The ASPAC message is sent by an ASP to indicate to an SG that it is
the active ASP to be used from within a list of primary and back-up ASPs
for a particular signaling mapping relationship.

The ASPAC message contains the following parameters:

     Controlled/Forced flag (C/F flag)
     INFO String

The format for the ASPAC message is as follows:


    0            15 16           31
   +---------------+---------------+
   |            C/F flag           |
   +---------------+---------------+
   |   Tag (0x4)   |    Length     |
   +---------------+---------------+

   |          INFO String          |

   +---------------+---------------+

Morneault, et al                                               [Page 16]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999


The valid values for C/F flag are shown in the following table.

        Define         Value       Description
   FORCED               0x0     Force sending of all messages to ASP
   CONTROLLED           0x1     Only send "new work" to ASP


2.3.2.4  ASP Inactive (ASPIA)

The ASPIA message is sent by an ASP to indicate to an SG that it is
no longer the the active ASP to be used from within a list of primary
and back-up ASP for a particular signaling mapping relationship.  The
SG will respond with an ASPIA message and either buffer or discard
incoming messages for a timed period and then discard.

The ASPIA message contains the following parameters:

     INFO String

The format for the ASPIA message is as follows:


    0            15 16           31
   +---------------+---------------+
   |   Tag (0x4)   |    Length     |
   +---------------+---------------+

   |          INFO String          |

   +---------------+---------------+

2.3.3  Layer Management (MGMT) Messages

2.3.3.1  Error (ERR)

The ERR message is sent when an invalid value is found in an incoming
messages.

The ERR message contains the following parameters:

     Error Code

The format for the ERR message is as follows:


    0     7 8    15 16           31
   +---------------+---------------+
   |           Error Code          |
   +---------------+---------------+



Morneault, et al                                               [Page 17]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

The Error Code can be one of the following values:

     Invalid Version                        0x1
     Invalid Interface Identifier           0x2
     Invalid SCN Version                    0x3
     Invalid Adaptation Layer Identifier    0x4
     Invalid Stream Identifier              0x5
     Invalid Message Type                   0x6

3.0  Procedures

The M2UA layers needs to respond to various primitives it receives from
other layers as well as messages it receives from the peer-to-peer
messages.  This section describes various procedures involved in
response to these events.

3.1  Procedures to Support Service in Section 1.4.1

These procedures achieve the M2UA layer's "Transport of MTP Level 2 /
MTP Level 3 boundary" service.

3.1.1  MTP Level 2 / MTP Level 3 Boundary Procedures

On receiving a primitives from the local layer, the M2UA layer will
send the corresponding MAUP message (see Section 2) to its peer.  The
M2UA layer must fill in various fields of the common and specific headers
correctly.  In addition the message needs to be sent on the SCTP stream
that corresponds to the SS7 link.

3.1.2  MAUP Message Procedures

On receiving MAUP messages from a peer M2UA layer, the M2UA layer on an
SG or MGC needs to invoke the corresponding layer primitives to the
local MTP Level 2 or MTP Level 3 layer.

3.2  Procedures to Support Service in Section 1.4.2

3.2.1  LM primitives procedures

On receiving these primitives from the local layer, the M2UA layer will
send the corresponding LM message (Error) to its peer.  The M2UA layer
must fill in the various fields of the common and specific headers
correctly.

3.2.2 LM message procedures

Upon receipt of LM messages the M2UA layer must invoke the corresponding
Layer Management primitives (M-ERROR) to the local layer management.

3.3 Procedures to Support Service in Section 1.4.3

These procedures achieve the M2UA layer's "Support for management of
active associations between SG and MGC" service.

Morneault, et al                                               [Page 18]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

3.3.1 State Maintenance

3.3.1.1  ASP States

The state of the each ASP is maintained in the M2UA layer on the SG. The
state of an ASP changes due to events. The events include:

   * Reception messages from peer M2UA layer
   * Reception of indications from layers below

The ASP state transition diagram is shown in Figure 4.  The possible
states of an ASP are:

ASP-DOWN: Application Server Process is unavailable.  Initially all ASPs
  are in this state.

ASP-UP: Application Server Process is available but application traffic is
  stopped.

ASP-ACTIVE: Application Server Process is available and application
  traffic is active.  At most one ASP per AS can be in the active state.

                 Figure 4: ASP State Transition Diagram

                               +-------------+
                     |-------->|             |
                     |         |  ASP-ACTIVE |
                     |         |             |
                     |         |             |
                     |         +-------------+
                     |             ^     |
                     |      ASP    |     | ASP
                     |      Active |     | Inactive
                     |             |     v
                     |         +-------------+
                     |         |             |
         ASP Down /  |         |             |
          SCTP CDI   |         |  ASP-UP     |
                     |         |             |
                     |         |             |
                     |         +-------------+
                     |             ^    |
                     |        ASP  |    | ASP Down /
                     |        Up   |    | SCTP CDI
                     |             |    v
                     |         +-------------+
                     |         |             |
                     |-------->|             |
                               |  ASP-DOWN   |
                               |             |
                               |             |
                               +-------------+

Morneault, et al                                               [Page 19]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

SCTP CDI: Local SCTP layer's Communication Down Indication to the Upper
  Layer Protocol (M2UA) on an SG. SCTP will send this indication when
  it detects the loss of connectivity to ASP's SCTP layer.

3.3.1.2  AS States

The state of the AS is maintained in the ITUN layer on the SG.

The state of an AS changes due to events. These events include:

   * ASP state transitions
   * Recovery timer triggers

The possible states of an AS are:

AS-DOWN: Application Server is unavailable.  This state implies that all
  ASPs are in the ASP-DOWN state for this AS.

AS-UP: One or more ASPs are in the ASP-UP state.

AS-ACTIVE: Application Server is available and application traffic is
  active.  This state implies that one ASP is in the ASP-ACTIVE state.

AS-PENDING: Currently Active ASP became inactive or SCTP association with it
  is lost. A Recovery timer will be started and in coming SCN messages will
  be queuedby the SG. If an ASP becomes Active before the recovery timer
  expires, AS will move to AS-ACTIVE state and all the queued messages will
  be sent to the active ASP. If the recovery timer expires before an ASP
  becomes active, SG stops queuing messages and discards all queued messages.
  AS will move to AS-UP if at least one ASP is in ASP-UP state, otherwise it
  will move to AS-DOWN state.

If T(r) expires before an ASP becomes active, the SG stops queuing messages
and  discards all previously queued messages.  The AS will move to AS-UP if
at least one ASP is in ASP-UP state, otherwise it will move to AS-DOWN state.



















Morneault, et al                                               [Page 20]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999


      +----------+  one ASP trans ACTIVE   +-------------+
      |          |------------------------>|             |
      |  AS-UP   |                         |  AS-ACTIVE  |
      |          |                         |             |
      |          |<                       -|             |
      +----------+ \                     / +-------------+
         ^   |      \ Tr Trigger        /       ^    |
         |   |       \ at least one    /        |    |
         |   |        \ ASP in UP     /         |    |
         |   |         \             /          |    |
         |   |          \           /           |    |
         |   |           \     /---/            |    |
 one ASP |   |            \   /         one ASP |    | ACTIVE ASP
 trans   |   | all ASP     \-/----\     trans   |    | trans to UP or
 to UP   |   | trans to     /      \    ACTIVE  |    | ACTIVE ASP
         |   | DOWN        /        \           |    | SCTP CDI
         |   |            /          \          |    |
         |   |           /            \         |    |
         |   |          /all ASP       \        |    |
         |   v         / trans to       \       |    v
      +----------+    /  DOWN            \ +-------------+
      |          |<--/                    -|             |
      | AS-DOWN  |                         | AS-PENDING  |
      |          |                         |  (queueing) |
      |          |<------------------------|             |
      +----------+    Tr Trigger no ASP    +-------------+
                       in UP state or
                     prev ACTIVE ASP trans
                        to DOWN state

      Tr = Recovery Timer

                 Figure 5: AS State Transition Diagram

Note: If AS moves from AS-PENDING state to AS-UP or AS-DOWN states, the
Layer Management on MG may take appropriate SCN notification actions.

3.3.2 ASPM procedures for primitives

Before the establishment of an SCTP association the ASP state at both the
SG and ASP is assumed to be "Down".

When the M2UA layer receives an M-SCTP ESTABLISH request primitive from
the Layer Management, the M2UA layer will try to establish an SCTP
association with the remote M2UA peer.  Upon reception of an eventual
SCTP-Communication Up confirm primitive from the SCTP, the M2UA layer
will invoke the primitive M-SCTP ESTABLISH confirm to the Layer Management.





Morneault, et al                                               [Page 21]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

Alternatively, if the remote M2UA-peer establishes the SCTP association
first, the M2UA layer will receive an SCTP Communication Up indication
primitive from the SCTP. The M2UA layer will then invoke the primitive
M-SCTP ESTABLISH indication to the Layer Management.

Once the SCTP association is established, The M2UA layer at an ASP will
then find out the state of its local M2UA-user from the Layer Management
using the primitive M-ASP STATUS.  Based on the status of the local
M2UA-User, the local ASP ITUN Application Server Process Maintenance (ASPM)
function will initiate the ASPM procedures, using the ASP-Up/-Down/-Active/
-Inactive messages to convey the ASP-state to the SG - see Section 3.3.3.

If the M2UA layer subsequently receives an SCTP-Communication Down
indication from the underlying SCTP layer, it will inform the Layer
Management by invoking the M-SCTP STATUS indication primitive.  The state
of the ASP will be moved to "Down" at both the SG and ASP.

At an ASP, the Layer Management may try to reestablish the SCTP association
using M-SCTP ESTABLISH request primitive.

3.3.3 ASPM procedures for peer-to-peer messages

3.3.3.1 ASP UP

The SG will mark the path as up if an explicit ASP UP (ASPUP) message is
received and internally the path is allowed to come up (i.e., not in a
locked local maintenance state). An ASP UP (ASPUP) message will be sent
to acknowledge the received ASPUP. The SG will respond to a ASPUP with a
ASPDN message if the path is in a locked maintenance state.

The SG will send a ASPUP message in response to a received ASPUP message
from the MGC even if that path was already marked as UP at the SG.

The paths are controlled by the MGC. The SG will only send ASPUP in
response to the reception of a ASPUP message.

The MGC will send ASPUP messages every 2 (add text regarding this being
a configurable timer) seconds until the path comes up (i.e. until it
receives a ASPUP message from the SG for that path).  The MGC may decide
to reduce the frequency (say to every 5 seconds) if the an acknowledge-
ment is not received after a few tries.

The MGC should wait for the ASPUP message from the SG before transmitting
ASP maintenance messages (ASPIA or ASPAC) or M2UA messages or it will
risk message loss.  The ASPUP message received from the SG is not
acknowledged by the MGC.

3.3.3.2 ASP Down

The SG will mark the ASP as down and send a ASPDN message to the MGC if
one of the following events occur:

Morneault, et al                                               [Page 22]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

     - a ASP Down(ASPDN) message is received from the MGC,
     - the ASP is locked by local maintenance.

The SG will also send a ASPDN message when the ASP is already down and
a ASPDN) message is received from the MGC.

The MGC will send ASPDN whenever it wants to take down a ASP.  Since the
ASPDN messages to the SG or the ASPDN responses from the SG can be lost
(for example, during a MGC node failover), the MGC can send ASPDN messages
every 2 seconds until the path comes down (i.e. until it receives a ASPDN
message from the SG for that path).

3.3.4  ASP Version Control

If a ASP Up message with an unknown version is received, the receiving
end will respond with an Error message.  This will indicate to the
sender which version the receiving node supports.

This is useful when protocol version upgrades are being performed.  A
node with the newer version should support the older versions used on
other nodes it is communicating with.

The version field in the Error message header associated with the will
indicate the version supported by the node.

3.3.5  ASP Inactive

When a ASPIA message is received, message transmission to that ASP ceases.
The SG will either discard all incoming messages or start buffering the
incoming messages for N seconds after which messages will be discarded.

If the ASP is down, all of the Paths that were supported by that ASP
are, by default, down.

3.3.6  ASP Active

When a ASP Active (ASPAC) message is received, the SG will start routing
to that ASP.  Reception of a ASPAC message overrides any previous ASPAC
messages and results in the ASP associated with the ASPAC message to
become the newly active ASP.

4.0  Examples of MTP2 User Adaptation (M2UA) Procedures

4.1  Establishment of associations between SG and MGC examples

An example of the message flows for establishing active associations between
SG and MGC is shown below.

                  SG                  ASP1

                        <----------- ASP Up
                  ASP Up ---------->
                  (ACK)
                        <----------- ASP Active
              ASP Active ---------->
              (ACK)

Morneault, et al                                               [Page 23]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999


An example of message flows for establishment of associations with two
ASPs and the message flows for take-over of the primary (ASP1) by the
secondary (ASP2).

                 SG                    ASP1               ASP2

                        <----------- ASP Up
                  ASP Up ---------->
                  (ACK)
                        <------------------------------ ASP Up
                  ASP Up ------------------------------>
                  (ACK)
                        <----------- ASP Active
              ASP Active ---------->
              (ACK)
                              ...

                        <----------- ASP Inactive
            ASP Inactive ---------->
            (ACK)

                         (this message is optional)
            ASP Inactive ------------------------------>
                        <------------------------------ ASP Active
              ASP Active ------------------------------>
              (ACK)

An example of message flows for establishment of associations with two
ASPs and the message flows for controlled take-over of the primary (ASP1)
by the secondary (ASP2).  In this case, the SG sends new work to ASP2.

                 SG                    ASP1               ASP2

                        <----------- ASP Up
                  ASP Up ---------->
                  (ACK)
                        <------------------------------ ASP Up
                  ASP Up ------------------------------>
                  (ACK)
                        <----------- ASP Active
              ASP Active ---------->
              (ACK)
                              ...

                        <------------------------------ ASP Active
                                                        (New Work)
              ASP Active ------------------------------>
              (ACK)

                        <----------- ASP Inactive
            ASP Inactive ---------->
            (ACK)


4.2  Case 1:  SG to MGC, MTP Level 2 to MTP Level 3 Boundary Procedures

4.2.1  SS7 Link Alignment

The MGC can request that a SS7 link be brought into alignment using the
normal or emergency procedure.  An example of the message flow to bring
a SS7 link in-service using the normal alignment procedure is shown
below.

            SG                             MGC

                        <----------- Establish Request (ESTABLISH_NORMAL)
        Establish Response ---------->


An example of the message flow to bring a SS7 link in-service using the
emergency alignment procedure.

           SG                             MGC

                        <----------- Establish Request (ESTABLISH_EMER)
        Establish Response ---------->



Morneault, et al                                               [Page 24]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

4.2.2  SS7 Link Release

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

            SG                             MGC

                        <------------ Release Request (RELEASE_MGMT)
        Release Response  ------------>

The SG can autonomously indicate that a SS7 link has gone out-of-service
as shown below.

            SG                             MGC

        Release Indication ------------>
      (RELEASE_PHYS)


4.2.3  Set and Clear Local Processor Outage

to be added

4.2.4  Notification of Processor Outage (local or remote)

to be added

4.2.5  Flush Buffers or Continue

to be added

4.2.6  SS7 Link Changeover

An example of the message flow for a changeover is shown below.

            SG                             MGC

                         <---------- Retrieval Request (MTP2_RTRV_BSN)
        Retrieval Confirm  ---------->
        (with BSN)
                         <---------- Retrieval Request (MTP2_RTRV_MSGS
                                                         with FSN)
        Retrieval Confirm  ---------->

        Retrieval Ind    ----------->
        Retrieval Ind    ----------->
        Rtrvl Complete Ind ---------->

Note:  The number of Retrieval Indication is dependent on the number of
messages in the retransmit queue that have been requested.  Only one
Retrieval Complete Indication should be sent.


Morneault, et al                                               [Page 25]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

4.3  Case 2:  SG to IPSCP, MTP Level 2 to MTP Level 3 Boundary Procedures

4.3.1  Message Transmission

Messages are transmitted using the Data Request primitive from MTP3 to
MTP2UA.

             MTP2UA          MTP3

               <------------- Message For Transmission (Data Request)

4.3.2  Message Reception

Messages are received using the Data Indication primitive from MTP2UA to
MTP3.

             MTP2UA          MTP3

                ------------> Received Message (Data Indication)

4.3.3  Link Status Indication

The MTP2UA layer sends Link_In_Service and Link_out_Of_Service after
receiving indication from SCTP layer.

  MTP3        MTP2UA       SCTP         SCTP          MTP2UA       MTP3

               <--------------
                Communication Up
                Link proving is done
                By MTP2UA at this moment.
   <---------------
    Link_In_Service

               <--------------
                Communication Lost
   <---------------
    Link Out of Service


4.3.4  Link Alignment

The MTP3 layer in the IPSCP can request that a SS7 link be brought into
alignment using the normal or emergency procedure.  An example of the
message flow to bring a SS7 link in-service using the normal alignment
procedure is shown below.

            MTP2UA                             MTP3

                        <----------- Establish Request (ESTABLISH_NORMAL)
        Establish Response ---------->





Morneault, et al                                               [Page 26]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999


An example of the message flow to bring a SS7 link in-service using the
emergency alignment procedure.

           MTP2UA                             MTP3

                        <----------- Establish Request (ESTABLISH_EMER)
        Establish Response ---------->

4.3.5  Link Proving (During Emergency)

There are two alignment procedures used: normal alignment and emergency
alignment.  During normal alignment, communication to other end is tested
for a period of time for making sure that the communication link does
satisfy the performance requirements of the application.  The examples
are RTT and packet loss.  Normal alignment is used when there are other
links associated with the affected link.  The other links should be to
the same destination.  Emergency alignment is used when there are no other
links to the same destination.  During emergency, link is not tested for
long period of time but instead, an indication from SCTP layer is used to
bring the link in service.

 MTP3        MTP2UA       SCTP        SCTP         MTP2UA       MTP3

   ------------->
     Emergency        Disable Proving

              <-------------
               Communication UP
              -------------->
                   Status (validate the SCTP association meets
                           application requirement)

   <-------------
    Link_In_Service

4.3.6  Link Proving (Emergency Ceased)

One function of the adaptation layer is to make sure that the link meets
the performance requirements of the application.  This is usually done
by proving the link.  For example, for proving the link, we need the
adaptation layer to issue an heartbeat/RTT to its peer.  This is done
before declaring link is in service to its application.  For this purpose,
the existing "status" command is used.  Note that how to the link meets
performance requirements is implementation dependent.  Also, the proving
period can be configurable.







Morneault, et al                                               [Page 27]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999


 MTP3        MTP2UA       SCTP        SCTP         MTP2UA       MTP3

   ------------->
     Emergency        Enable Proving
      ceased

             <---------------
              Communication UP
             --------------->  RTT
                  Status      -------->
                  RTTs are    -------->
                  Sent for a  -------->
                  Period of   .........
                  3 seconds   -------->
                               RTT
   <--------------
    Link_In_Service (After checking that link is sane)

4.3.7  Congestion Notification to Upper layer

MTP3 layer expects notification of the link congestion.  For example, this
is accomplished by two messages:  I) Link Congested ii) Link Congestion
Ceased.  Congestion is assumed if MTP2UA 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 MTP2UA 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 link change over procedure.

 MTP3        MTP2UA       SCTP        SCTP         MTP2UA       MTP3

              <--------------
               Send Failure
              <--------------
               Send Failure
              <--------------
               Send Failure
               ("N" consecutive fails)
               (implementation specific)
  <-------------
   Congestion Detected
               ------------->
                  Status
               ------------>
                  Status
               ------------->
               polled for certain time
               till the congestion ceased
               (implementation specific)
  <--------------
   Congestion ceased

Morneault, et al                                               [Page 28]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

4.3.8  Link Change Over due to Congestion

Due to sustained congestion, MTP2UA can take the link out of service.
Next, MTP2UA sends an indication to MTP3 regarding link is out service
due to congestion.  In this context, MTP3 can initiate a link change
over to its peer.

 MTP3        MTP2UA       SCTP        SCTP         MTP2UA       MTP3

              <--------------
               Send Failure
              <--------------
               Send Failure
              <--------------
               Send Failure
               ("N" consecutive fails)
               (implementation specific)
  <--------------
    Congestion Detected
                ------------>
                 Terminate
                <------------
                 Terminate Successful
                <------------
                 Communication Lost
  <---------------
    Link Out of Service


4.3.9  Link Release

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

            MTP2UA                            MTP3

                        <------------ Release Request
        Release Response  ------------>

The SG can autonomously indicate that a SS7 link has gone out-of-service
as shown below.



Morneault, et al                                               [Page 29]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999


            MTP2UA                             MTP3

        Release Indication ------------>
      (Link_Out_Of_Service)

NOTE: We may be able to effective use of "State" primitives here.
      For further investigation

4.3.10  Link Change Over

The objective of the change over 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, the SCTP TSN must be mapped to FSN/BSN of SS7.

Transmit Sequence Numbers used by SCTP (Signaling Control Transport
Protocol) are of sixteen bits.  MTP2's forward and backward sequence
numbers of only seven bits.  Hence it is required to map the sixteen bit
TSN to seven bit FSN/BSN.  For simplicity, it is assumed that only least
seven significant seven bits of TSN are used.  There can be a
configuration, where the links in the link set are of not equal bandwidth.
Further investigation is required for this scenario.

         15                       8                    0
          ----------------------------------------------
          0  0  0  0  0  0  0  0  0  X  X  X  X  X  X  X
          -----------------------------------------------

                                     <------FSN/BSN----->

In order to convert TSN to FSN and BSN, the following formula is used:

          FSN, BSN = (Transmit Sequence Number - 1) MODULO 255


For data retrieval, MTP3 requests Backward Sequence Number (BSN) from
MTP2UA.  This 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


Morneault, et al                                               [Page 30]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

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 local
end. As soon, the MTP3 of local end receives this BSN, MTP3 retrieves all
the unacknowledged messages starting from BSN.  This is accomplished
through "Retrieve FSN" message.  After all the messages are sent from
MTP2UA to MTP3, a retrieval complete message is sent.


 MTP3        MTP2UA       SCTP        SCTP         MTP2UA       MTP3

               <-------------
                Communication Lost
   <--------------
   Link Out of Service

   --------------> Find the gaps
   Retrieve BSN    in the rcvd. Msgs
                   And locate the first gap
  <---------------
   Indicate BSN
   ---------------------------------------------------------------->
                                                             COO (BSN)
                                                        <-----------
                                                          Retrieve BSN
                                                        ----------->
                                                          Indicate BSN
  <-----------------------------------------------------------------
                                                             COA (BSN)

  --------------------->Go through the transmit
   Retrieve FSN         queue and find unack. Msgs.
  <--------------------- FSB Not retrievable (in case)
  <--------------------- Retrieved Message
  <----------------------Retrieved Message
          ...
  <----------------------Retrieval Complete


4.4 Layer Management Communication Examples

An example of the message flows for communication between Layer Manage-
ment modules between SG and MGC is shown below. An active association
between MGC and SG is established (section 4.1) prior to the following
message flows.

                  SG                       MGC

                        <----------- Establish Request
                   Error ---------->
                   (Invalid Interface Id)

Morneault, et al                                               [Page 31]


Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999

5.0  Security

SCN adaptation layers rely on SCTP to provide security.

6.0  Acknowledgements

The authors would like to thank Ian Rytina for his valuable comments and
suggestions.

7.0  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] Framework Architecture for Signaling Transport, draft-ietf-sigtran-
    framework-arch-03.txt, June 1999

[5] Simple Control Transmission Protocol, draft-ietf-sigtran-sctp-00.txt,
    August 1999

[6] Media Gateway Control Protocol (MGCP), draft-huitema-megaco-mgcp-
    v1-03.txt, August 1999

























Morneault, et al                                               [Page 32]

Internet Draft         SS7 MTP2 User Adaptation Layer           Sep 1999


8.0  Author's Addresses

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-477-8446
Alcatel USA                           EMail: ram.dantu@usa.alcatel.com
1000 Coit Road
Plano, Tx. 74075


This Internet Draft expires April 2000.


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/