| draft-george-sigtran-m2peer-00Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-george-sigtran-m2peer-00.txt.
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: [email protected]
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: [email protected]
13615 Dulles Technology Drive
Herndon, VA. 20171
USA
Malleswar Kalla Tel: +1-973-829-5212
Telcordia Technologies EMail: [email protected]
MCC 1J211R
445 South Street
Morristown, NJ 07960
USA
Greg Sidebottom Tel: +1-613-763-7305
Nortel Networks EMail: [email protected]
3685 Richmond Rd,
Nepean, Ontario
Canada K2H5B7
Ram Dantu, Ph.D. Tel: +1-972-234-6070 extension 211
IPmobile EMail: [email protected]
1651 North Glenville, Suite 216
Richardson, TX 75081
USA
This Internet Draft expires September 2000.
George, et al [Page 23]
| ||||||||||||||||
| Last modified: Wed, 27 Nov 2024 14:56:22 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. | |||||||||||||||||