Network Working Group Tolga Asveren
INTERNET DRAFT Oksijen Teknoloji
Brian Bidulock
OpenSS7 Corporation
Expires: September 23, 2003 April 23, 2003
M3UA SG-SG communication
<draft-bidas-sigtran-sgsg-03.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Asveren/Bidulock 1
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
This Internet-Draft describes a protocol to support communication of
M3UA[1] based SGs in IP domain. The additional functionality needed
by SGs to act as relay points between SS7 nodes is also addressed.
TABLE OF CONTENTS
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology. . . . . . . . . . . . . . . . . . . . . 2
1.2 Scope. . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Conventions. . . . . . . . . . . . . . . . . . . . . 4
1.4 Overview . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Architecture . . . . . . . . . . . . . . . . . . . . 5
1.6 Possible Scenarios for SG-SG Communication . . . . . 6
2. Functional Areas. . . . . . . . . . . . . . . . . . . . . 7
2.1 Signalling Point Code Representation . . . . . . . . 7
2.2 Routing Context and Routing Keys . . . . . . . . . . 7
2.3 Network Appearance . . . . . . . . . . . . . . . . . 7
2.4 SCTP Association Establishment . . . . . . . . . . . 7
2.5 Point Code Status Information Exchange . . . . . . . 7
2.6 Message Distribution . . . . . . . . . . . . . . . . 8
2.7 Congestion Handling. . . . . . . . . . . . . . . . . 8
2.8 Restricted Destinations. . . . . . . . . . . . . . . 9
3. Message Types and Parameters. . . . . . . . . . . . . . . 9
4. Protocol Messages . . . . . . . . . . . . . . . . . . . . 9
4.1 Destination User Part Unavailable Message. . . . . . 9
4.2 Signalling Congestion. . . . . . . . . . . . . . . . 10
4.3 Congestion Test Message. . . . . . . . . . . . . . . 11
4.4 Changeover Mechanism Related Messages. . . . . . . . 12
4.4.1 Changeover Request Message. . . . . . . . . . 13
4.4.2 Changeover Request Acknowledgement Message. . 14
5. SG and SGP State Machines . . . . . . . . . . . . . . . . 14
5.1 SGP State Machine. . . . . . . . . . . . . . . . . . 14
5.2 SG State Machine . . . . . . . . . . . . . . . . . . 15
6. Management Procedures . . . . . . . . . . . . . . . . . . 16
6.1 ASP Up Procedures. . . . . . . . . . . . . . . . . . 16
6.2 ASP Down Procedures. . . . . . . . . . . . . . . . . 17
6.3 ASP Active Procedures. . . . . . . . . . . . . . . . 17
6. Examples of SG-SG Communication Procedures. . . . . . . . 17
6.1 M3UA Availability Declaration. . . . . . . . . . . . 17
6.2 PC Status Announcement . . . . . . . . . . . . . . . 18
7. Security. . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . 19
9. References. . . . . . . . . . . . . . . . . . . . . . . . 19
9.1 Normative References . . . . . . . . . . . . . . . . 19
9.2 Informative References . . . . . . . . . . . . . . . 19
10. Author's Addresses . . . . . . . . . . . . . . . . . . . 20
1. Introduction
1.1 Terminology
2
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
SG-SG communication document uses the terminology used in the M3UA
RFC[3332] with the following additions and modifications:
COA Changeover Acknowledgement MTP3 message
COO Changeover Order MTP3 message
ECA Emergency changeover acknowledgement MTP3 message
ECM Emergency changeover MTP3 message
IP-SP IP Signalling Point. A signaling point, which uses IP and
possibly also TDM based messaging to communicate with its peers.
RCT Signalling route set congestion test MTP3 message
Relaying Relaying is used throughout this document with the meaning
of providing transferring functionalities for messages, which are
not destined for the own PC, like a STP does in SS7 network.
SG In the context of this document, a SG does not necessarily
have SCN interface. It is used with the meaning of IP-SP. The name
SG is preserved because this document defines an extension to a
M3UA-SGP stack.
TFC Transferred controlled MTP3 message
1.2 Scope
M3UA does not have relaying capability. This might be necessary to
build hybrid networks, where some part of the signaling transport is
TDM based and some part of it IP based. Relaying might be also
desirable for redundancy purposes and to have a hierarchy in the
network based on SS7 constructs. M2PA[2] provides a way to achieve
relaying but it includes MTP2[3] procedures on top of SCTP[4] and
emulates SS7 links in IP domain. An alternative approach is defined
in this document: relaying with a layer3 peer-to-peer model, without
the burden of layer2 procedures and within the M3UA protocol with
some additional messages and procedures.
For ASP/SGP relationship as defined in M3UA, SPMC logic and user
parts for a PC reside on different nodes, and communication between
them is defined based on MTP3/MTP3[5] User relationship. This brings
some difficulties for modelling and implementation, when SG acts as
STP(non-backhaul scenarios), i.e. when PC boundary is crossed
between SG and ASP. SG-SG communication is based on MTP3/MTP3
communication and supports such scenarios in a similar way as MTP3
does in conventional SS7 network.
SG-SG communication as defined in this document does also provide a
method for direct communication between M3UA nodes in IP domain,
where again user part and layer3 logic are provided by the same
entity.
In general, when PC boundaries are crossed, providing layer3 logic
on the same side of the relationship with user parts provides an
easy way to make a MTP3 stack to support M3UA SG-SG mode of
communication, where some of the MTP3 routes are using IP based
communication instead of SS7 links.
3
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
1.3 Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in
[7].
1.4 Overview
The purpose of SG-SG protocol is to increase IP domain communication
capabilities of M3UA peers and to allow SS7 signalling backhauling
between SS7 nodes over IP with M3UA protocol.
----- -----
// \\ // \\
| SPMC | | SPMC |
| Cloud 1| | Cloud 2|
\\ // \\ //
--+-- --+--
| |
| |
+--+--+ +--+--+
| SG1 +------------+ SG2 |
+--+--+ +--+--+
| |
| |
| |
| +-----+ |
+-----+ SG3 +------+
+--+--+
|
|
--+--
// \\
| SPMC |
| Cloud 3
\\ //
-----
Figure 1. Intra-IP communication using SG-SG communication
In the configuration in Figure 1 SGs act as transfer points between
SPMC clouds. Their functionality is similar to the STP functionality
in SS7 network. The communication between ASPs and SGs is as defined
in M3UA protocol. It should be noted that a SG can also support a
local SPMC, i.e. it MAY have user parts running on it, instead of on
an ASP.
4
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
+---------+ +---------+
| SG1 +--------------+ SG2 |
+----+----+ +----+----+
| |
| |
+----+----+ +----+----+
|SS7 node1| |SS7 node2|
+---------+ +---------+
Figure 2. SS7 signalling backhauling using SG-SG communication
In the configuration in Figure 2 SGs act as relay points for SS7
nodes.
1.5 Architecture
The goal of SG-SG communication is to define a peer-to-peer
relationship between two M3UA IP domain entities, which can be used
both for direct communication and for relaying. For that reason SG-
SG communication model tries to mimic the relationship of two
signaling points in traditional SS7 network. This allows inheritance
of necessary MTP3 procedures without any modeling problems, to
modify a MTP3 stack easily to make it work also as a M3UA SG and a
smooth migration from TDM based communication to IP based
communication for SS7 networks.
In fact, in the context of SG-SG communication, SGs can be thought
as IP-SPs. All of the SPMC(layer3) logic resides in the local node,
which provides a well defined peer-to-peer model, without relying to
a remote SPMC control entity for local procedures. It should be
noted that user parts for a specific SPMC MAY reside on the same
node with SG itself, or MAY be distributed across remote nodes,
where relationship between those nodes and the controlling SG MAY be
implementation dependent or MAY be based on the ASP/SGP relationship
as defined in M3UA. SGs MAY also not control any SPMC directly and
act only as relay points.
SG-SG communication management is based mainly on SSNM as defined in
M3UA protocol, with some additional messages to handle changeover
and congestion cases as defined in MTP3.
Communication of peers is in PC granularity.
Each SG MAY consist of multiple SGPs. It should be noted, that all
layer3 logic(both for SPMCs directly controlled and for remote PCs)
functions as a single entity in the whole SG.
SG
************************************
* +------------------------------+ *
* | Layer3 Logic | *
* +----+---+----+---+----+--+----+ *
5
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
* |SGP1| |SGP2| |SGP3| |SGP4| *
* +-+--+ +-+--+ +-+--+ ++---+ *
************************************
| | | |
Figure 3. SG with single Layer3 Logic and with multiple SGPs
1.6 Possible Scenarios for SG-SG Communication
Below, some cases, where SG-SG communication might be used is given.
As gateway between networks of different operators:
It is likely that operators would prefer to centralize interaction
of their network with networks of other operators for reasons like
security, management transparency, different protocols used in
different networks etc... Using concentration nodes instead of a
fully mesh network also reduces number of necessary SCTP
associations.
----- -----
//// \\\\ //// \\\\
| Network of | | Network of |
| Operator1 | | Operator2 |
| | | |
| | | |
\\\\ //// \\\\ ////
--+-- --+--
| |
| |
+-----+------+ +-------+----+
| SG of | | SG of |
| Operator1 +----------+ Operator2 |
+------------+ +------------+
Figure 4. Interaction of two networks via SG-SG communication
To build hybrid networks:
SG-SG communication might be utilized to build networks, where TDM
and IP based transport of messages is used in a mixed way. It should
be noted that SGs can act as IP-STPs and/or IP-SEPs. For example in
Figure 5 below, SG3 acts as IP-SEP.
+------+
|SS7 |
|User |
|Parts |
+------+ +------+ +------+
| ASP1 | | SG3 | |SS7 |
| | | | |node3 |
+---+--+ +-+--+-+ +---:--+
| | | :
6
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
| | | : +------+
| | | : | ASP2 |
+---+--+ | | +---:--+ +--+ |
| SG1 +----------+ +----------+ SG2 +---+ +------+
| +------------------------+ +---+ +------+
+--:---+ +---:--+ | | ASP3 |
: : +--+ |
: : +------+
+--:---+ +---:--+
|SS7 | |SS7 |
|node1 | |node2 |
+------+ +------+
--------- IP based communication
.. .. .. TDM based communication
Figure 5. Hybrid network configuration with SG-SG communication
2 Functional Areas
2.1 Signalling Point Code Representation
SGs should control SPMCs as a whole. When a SPMC becomes
unavailable, SG will broadcast DUNA to all SGs, it has an
association with. Similarly when a SPMC becomes available DAVA and
when a SPMC becomes restricted DRST will be sent.
2.2 Routing Context and Routing Keys
Unlike M3UA, there is no Routing Context/Routing Key concept present
in SG-SG communication.
2.3 Network Appearance
NA is used in the messages as described in M3UA.
2.4 SCTP Association Establishment
There is no client/server relationship between SGPs. SCTP
associations might be initiated from any side. A collision, which
might happen if both sides try to establish SCTP association
concurrently, is handled by the SCTP protocol itself.
Although SGPs are allowed to have more than one SCTP association
between them, such a configuration is NOT RECOMMENDED, as SCTP
multihoming provides a better way to achieve redundancy in a
transparent way to upper layers with no message loss/duplication and
missequencing. For that reason, equivalent of MTP3 changeover and
changeback procedures are not defined for SG-SG communication.
2.5 Point Code Status Information Exchange
7
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
After a SCTP association is established, peers SHOULD declare the
availability of their M3UA layer with ASPUP messages. A received
ASPUP message is replied with ASPUP-ACK. If one of the peers
receives ASPUP message before sending ASPUP, it MAY or MAY NOT send
ASPUP message, ASPUP-ACK message declares availability of the remote
peer. Each SGP should declare its availability to each SGP of the
remote SGs separately. A SGP can declare its unavailability with
ASPDN message. ASPDN message is acknowledged with ASPDN-ACK message.
After availability of M3UA layers is confirmed, SGs will exchange
SSNM to update the remote peer about the status of the PCs, which
are configured as reachable on them. Unless a corresponding message
is received, all configured PCs are assumed as accessible via the
remote peer. Each SG will send DUNA for unavailable PCs and DRST for
restricted PCs. The end of this unavailable/restricted PC
announcement procedure is marked with an ASPAC message. A received
ASPAC is replied with an ASPAC-ACK. SSNM and ASPAC/ASPAC-ACK are
sent per SG. A SG SHOULD NOT start sending DATA to a peer, unless
ASPAC and ASPAC-ACK are received.
SSNM, which are sent for point code status information exchange
procedure and ASPAC/ASPAC-ACK SHOULD be sent via stream 0, to
prevent problems, which might arise because of missequencing of
those messages.
2.6 Message Distribution
DATA messages SHOULD be sent to SGs, via which the destination
pointcode of the message to be sent is in available status. In case,
when there is no such peer SG, message SHOULD be sent to SGs, from
which the destination is declared as restricted. If no such SG
exists, the message SHOULD be dropped.
Message distribution among remote SGs is implementation dependent.
Message distribution method among SGPs belonging to the same SG is
determined by the sender of message. A SG SHOULD be prepared to
receive messages by any of its SGPs in UP state.
Messages, which require sequencing SHOULD be sent via the same SCTP
association using the same stream.
In case, the destination to which messages are to be sent changes (
new SGP switching to UP state etc...), Timer Procedure as described
in CORID[6] (1.4.1.4. SPP Restoring Traffic) SHOULD be followed, to
decrease possibility of missequencing.
2.7 Congestion Handling
Congestion handling procedures as defined in relevant MTP3 standards
for signaling points should be followed between SGs. It is
responsibility of a SG, to follow those procedures, on behalf of the
8
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
SPMCs, that it directly controls. While following those procedures,
SCON instead of TFC and CGT instead of RCT MUST be used, when the
message needs to be sent to or via an adjacent node in IP domain.
2.8 Restricted Destinations
When destinations in IP domain should be declared as restricted is
implementation dependent.
3 Message Types and Parameters
The following new message types are added to SSNM in addition to the
ones defined in M3UA.
128 Congestion Test Message (CGT)
129 Changeover Request Message(COR)
130 Changeover Request Acknowledgement Message(CORA)
The following parameters are added in addition to the ones defined
in M3UA.
Forward Sequence Number 0x0214
Signalling Link Code 0x0215
4 Protocol Messages
Between SGs DATA and SSNM messages as defined in M3UA protocol are
used. ERROR from MGMT, ASPUP/ASPUP-ACK from ASPSM and ASPAC/ASPAC-
ACK from ASPTM are also used. RC field in messages is not used,i.e.
it MUST not be filled.
4.1 Destination User Part Unavailable (DUPU)
A new field is introduced to DUPU.
Concerned PC: Destination PC, which has caused DUPU to be generated.
This parameter is mandatory.
The format for DUPU message parameters 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Affected PC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0206 | Length |
9
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Concerned DPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0204 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause | User |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2 Signalling Congestion (SCON)
For SG-SG communication, Concerned DPC parameter is mandatory. It
contains the point code information for the signaling point, which
originated the message causing SCON to be generated.
In SG-SG communication, there will be two Affected PC fields
present. The first one gives the PC of the originator of the SCON
(or the corresponding TFC) message and the second one gives the PC
for the congested destination. Those two Affected PC fields MUST be
sent in this order.
The format for SCON message parameters 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Affected PC1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Affected PC2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0206 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Concerned DPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0205 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Cong. Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
10
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3 Congestion Test Message (CGT)
CGT is used to support Signalling-route-set-congestion-test(National
Option) procedures as defined in MTP3. It is used instead of RCT in
MTP3.
The CGT message contains the following parameters:
Affected PC Mandatory
Concerned DPC Mandatory
Congestion Level Mandatory
Info String Optional
The format for CGT Message parameters 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0206 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Concerned DPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0205 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Cong. Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance: 32 bits (Semi-mandatory)
See M3UA Section 3.1.1
Affected Point Code: 32 bits (Mandatory)
11
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
Affected Point Code parameter contains the 14-, 16-, 24-bit binary
formatted point code value, for which CGT message is generated.
Concerned DPC: 32 bits (Mandatory)
Concerned DPC parameter contains the 14-, 16-, 24-bit binary
formatted point code value, whose congestion status is to be tested.
Congestion Level: 8 bits (unsigned integer) (Mandatory)
The Congestion Level parameter contains one of the following values:
0 No Congestion or Undefined
1 Congestion Level 1
2 Congestion Level 2
3 Congestion Level 3
The congestion levels are defined in the congestion method in the
appropriate national MTP recommendations.
When sending CGT message, procedures defined for Signalling-route-
set-congestion-test in Q.704 Clause 13.9 SHOULD be followed.
4.4 Changeover Mechanism Related Messages
Those messages are necessary to support changeover mechanism as
defined in MTP3. It should be noted that, they will be used, in case
a SG is relaying corresponding MTP3 changeover messages to another
SG.
+-------+ +-------+
| SS7 | | SG2 |
| node1 +--------X-------+ |
COO(1)+---+---+ ^ +----+--+ CORA(3)
| ^ | | | ^ |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
V | | | +-------+ | | V
COA(4)| | | SG1 | | COR(2)
+-----+-+ +---------+
^ | +-------+ ^
| | |
| | |
| | |
| | |
TDM IP
Figure 7. SG1 relaying changeover messages to and from SG2
12
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
4.4.1 Changeover Request Message(COR)
COR is used to relay changeover order/emergency changeover order
information to/from a SS7 peer. There are two scenarios, where it
can be used. Either it is received from a peer SG, where a
corresponding COO/ECM is sent to peer SS7 node or it can be
generated to a peer SG, after receiving COO/ECM from a SS7 node.
COR message contains the following parameters:
Network Appearance: 32 bits (Semi-mandatory)
See M3UA Section 3.1.1
SLC : 5 bits (Mandatory)
The Signalling Link Code of the failed link.
FSN : 24 bits (Semi-mandatory)
Forwards sequence number of the last message signal unit accepted
from the unavailable signaling link by the sender of message. If COR
is received from a SG and if FSN is present a corresponding COO MUST
be generated. If no FSN is present an ECM MUST be generated. When
COO is received from a SS7 peer, FSN MUST be filled in COR. When ECM
is received from a SS7 peer, FSN MUST NOT be filled.
Affected Point Code: 32 bits (Mandatory)
Affected Point Code parameter contains the 14-, 16-, 24-bit binary
formatted point code value, which has sent COO/ECM message.
Concerned Point Code: 32 bits (Mandatory)
Concerned Point Code parameter contains the 14-, 16-, 24-bit binary
formatted point code value, to which COO/ECM message is sent.
The format for COR message parameters 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0214 | Length =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserve | FSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0215 | Length =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | SLC |
13
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Affected PC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0206 | Length =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Concerned PC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4.2 Changeover Request Acknowledgement Message (CORA)
CORA is used to relay the FSN information regarding the last
accepted MSUs by a failed link between a peer SG and a SS7 node as
an answer to COR.
COR message contains the following parameters:
Network Appearance: 32 bit (Semi-mandatory)
See M3UA Section 3.1.1
SLC : 5 bits (Mandatory)
The Signalling Link Code of the failed link.
FSN : 24 bits (Semi-mandatory)
Forwards sequence number of the last message signal unit accepted
from the unavailable signaling link by the sender of CORA. . If CORA
is received from a SG and if FSN is present a corresponding COA MUST
be generated. If no FSN is present an ECA MUST be generated. When
COA is received from a SS7 peer, FSN MUST be filled in CORA. When
ECA is received from a SS7 peer, FSN MUST NOT be filled.
Affected Point Code: 32 bits (Mandatory)
Affected Point Code parameter contains the 14-, 16-, 24-bit binary
formatted point code value, to which the COA to be generated based
on the received CORA, should be sent.
Concerned Point Code: 32 bits (Mandatory)
Concerned Point Code parameter contains the 14-, 16-, 24-bit binary
formatted point code value, to which COO/ECM message is sent.
The format for parameters for CORA is the same like COR.
5. SG and SGP State Machines
5.1 SGP State Machine
14
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
The state of each remote SGP is maintained in the M3UA layer in the
SGP. The state of a particular SGP changes due to events. The events
include:
*Reception of messages from the peer M3UA layer at the SGP.
*Reception of indications from the SCTP layer.
*Local management intervention.
The SGP state transition diagram is shown in Figure 8. The possible
states of a SGP are:
SGP-DOWN: The remote M3UA peer at the SGP is unavailable and/or the
related SCTP association is down. Initially all SGPs will be in this
state. An SGP in this state SHOULD NOT be sent any messages, with
the exception of Heartbeat, ASP Down Ack and Error messages.
SGP-UP: The remote M3UA peer at the SGP is available(and the related
SCTP association is up). M3UA messages, which can be sent in this
state are restricted only by SG state.
+--------+
|SGP UP |
+-+----+-+
ASPUP or ^ | ASPDOWN/ASPDOWN-ACK
ASPUP-ACK | | SCTP CDI/SCTP RI
| |
| v
+-+----+-+
|SGP DOWN|
+--------+
Figure 8. SGP state machine
5.2 SG State Machine
The state of each remote SG is maintained in the SGP. SGPs belonging
to the same SG MUST have a unique view of a remote SG. The state of
a particular SG changes due to events. The events include:
*Reception of messages from the peer SG.
*State changes of local SGPs.
*Local management intervention.
The SG state transition diagram is shown in Figure 9. Possible
states of SG are:
SG DOWN: There is no SGP belonging to this SG in SGP UP state.
Messages, which are not allowed in SGP DOWN state SHOULD NOT be sent
to the SG.
SG UP: There is at least one SGP belonging to this SG in SGP UP
state, but PC status announcement phase is not completed yet. In
this state no DATA messages SHOULD be sent to the remote SG.
15
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
SG ACTIVE: There is at least one SGP belonging to this SG in ASP UP
state and remote SG has finished PC announcement phase. DATA
messages can be sent to the SG.
+--------+
| SG |
|ACTIVE +---+
+---+----+ |
^ |
ASPAC and| |Last SGP in SGP UP state
ASPAC-ACK | |transitions to SGP DOWN state
received from | |
peer SG +---+----+ |
| SG | |
| UP | |
+-+-----++ |
one SGP ^ | |
transitions| |Last SGP in SGP UP state
to SGP UP | |transitions to SGP DOWN state
state | | |
| v |
+-+-----++ |
| SG +<--+
| DOWN |
+--------+
Figure 9. SG state machine
6. Management Procedures
6.1 ASP Up Procedures
After a SGP successfully establishes a SCTP association with a peer
SGP, it needs to declare availability of its M3UA layer to its peer.
This is done either by sending ASPUP or by acknowledging a received
ASPUP with ASPUP-ACK or with both of them.
Because there is no client/server relationship between peers, each
of them can send ASPUP.
If for any local reason(e.g. management blocking) the SGP cannot
respond with an ASPUP-ACK message, the SGP responds with an Error
message with reason "Refused - Management Blocking". Otherwise, a
received ASPUP message SHOULD be acknowledged with ASPUP-ACK.
When ASPUP message is received, while the peer SGP is in SGP-UP
state, SGP stays in SGP-UP state and an ASPUP-ACK is sent as an
acknowledgement. In such a situation, if the peer SGP, sending ASPUP
message was the only one in SGP-UP state and if the SG is in SG-
ACTIVE state, SG state is changed to SG-UP state.
16
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
When ASPUP-ACK message is received without sending an ASPUP message,
remote SGP is put to SGP-DOWN state and an Error message with reason
"Unexpected Message" is sent.
When the SGP sends an ASPUP message, it starts timer T(ack). If the
SGP does not receive a response to ASPUP message within T(ack), the
SGP MAY restart T(ack) and resend ASPUP.
6.2 ASP Down Procedures
When a SGP does not want to receive messages from a peer SGP, for
which it was already in SGP-UP state, it sends an ASPDN message.
A received ASPDN message SHOULD be acknowledged with an ASPDN-ACK
message.
When ASPDN message is received while the peer SGP is already in SGP-
DOWN state, an Error message with reason "Unexpected message" is
sent.
When the SGP sends an ASPDN message, it starts timer T(ack). If the
SGP does not receive a response to ASPDN message within T(ack), the
SGP MAY restart T(ack) and resend ASPDN.
6.3 ASP Active Procedures
ASPAC message MUST be sent to mark the end of SSNM, initially sent
to report PCs, which are configured as reachable via the SGP, but
currently are not accessible or restricted.
A received ASPAC message SHOULD be acknowledged with ASPAC-ACK
message.
When the SGP sends an ASPAC message, it starts timer T(ack). If the
SGP does not receive a response to ASPAC message within T(ack), the
SGP MAY restart T(ack) and resend ASPAC.
A SGP SHOULD NOT start sending DATA to a peer SGP before receiving
both ASPAC and ASPAC-ACK from the peer SGP.
7 Examples of SG-SG Communication Procedures
7.1 M3UA Availability Declaration
In the following scenario, SG1 consists of SGP1/SGP2 and SG2
consists of SGP3/SGP4. After establishment of SCTP associations
between SGPs, each SGP should make its peers aware that its own M3UA
is ready.
SGP1 SGP2 SGP3 SGP4
| | | |
+------ASPUP----------->| |
17
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
| | | |
+------ASPUP------------+------->|
| | | |
|<-----ASPUP-ACK--------| |
| | | |
|<-----ASPUP------------+--------|
| | | |
|<-----ASPUP-ACK--------+--------|
| | | |
|------ASPUP-ACK--------+------->|
| | | |
|<-----ASPUP------------| |
| | | |
|------ASPUP-ACK------->| |
| | | |
|------ASPUP------------+------->|
| | | |
|<-----ASPUP-ACK--------+--------|
| | | |
| | | |
7.2 PC Status Announcement
In the following scenario, SG1 consists of SGP1/SGP2 and SG2
consists of SGP3/SGP4. It shows the messages exchanged after M3UA
availability declaration is finished. PC1/PC2/PC3 are configured as
reachable via SG2 on SG1 and PC4/PC5 are configured as reachable via
SG1 on SG2.
SGP1 SGP2 SGP3 SGP4
| | | |
|-------DUNA(PC1)--------->| |
| | | |
|-------DRST(PC2)--------->| |
| | | |
|------ASPAC-------------->| |
| | | |
|<-----ASPAC-ACK-----------| |
| | | |
|<--------+----DUNA(PC4)---+---------|
| | | |
|<--------+----ASPAC-------+---------|
| | | |
|---------+----ASPAC-ACK---+-------->|
| | | |
|<------DATA(PC3)----------| |
| | | |
| |----DATA(PC5)-->| |
| | | |
8 Security
18
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
SG-SG communication inherits security risks and considerations that
are present in M3UA. Please see "Security" section of M3UA for those
security considerations and recommendations.
Because SG-SG communication introduces relaying capability and can
be placed at network boundaries of networks belonging to different
operators, additional security might be desirable. Since SS7 related
outages are very costly and increased interconnections between TDM
and IP domain make SS7 network more vulnerable to intentional and/or
accidental disturbances, it is advisable for SGs to have capability
to screen and act on SS7 messages going through it. For example,
screening of messages can be made based on configurable lists of
OPC, DPC, SIO values or any combination of them. Possible actions
that are taken upon detection of disturbances could be informing
network management entities, generation of alarms, discarding
messages, modification of messages, generation of new messages or a
combination of them. Other more sophisticated message syntax,
message type and content screening could also be implemented to
improve security.
9 Acknowledgements
The authors would like to thank Manfred Angermayr, Javier Pastor-
Balbas, Vaibhav Madan, Ken Morneault and Kutluk Uslu for their
valuable comments and suggestions.
10 References
10.1 Normative References
[1] RFC[3332] "Signalling System7 (SS7) Message Transfer Part3(MTP3)
User Adaptation Layer(M3UA)"
[2] RFC[abcd] "SS7 MTP2-User Peer-to-Peer Adaptation Layer"
[3] ITU-T Recommendation Q.703 "Specifications of Signalling System
No. 7 _ Message transfer part, Signalling link"
[4] RFC[2960] "Stream Control Transmission Protocol"
[5] ITU-T Recommendation Q.704 "Specifications of Signalling System
No. 7 - Message transfer part Signalling network functions and
messages"
[6] draft-bidulock-sigtran-corid-00.txt "Correlation Id and
Heartbeat Procedures (CORID) Supporting Lossless Fail-Over between
SCTP Associations for Signalling User Adaptation Layers"
10.2 Informative References
19
Asveren/Bidulock
Internet Draft M3UA SG-SG Communication April, 2003
[7] RFC[2119] "Key words for use in RFCs to Indicate Requirement
Levels"
11 Author's Addresses
Tolga Asveren
Oksijen Teknoloji
Dunya Ticaret Merkezi A1
Istanbul, Turkey
Email : tolga.asveren@oksijen.com
Brian Bidulock
OpenSS7 Corporation
1469 Jeffreys Crescent
Edmonton, AB T6L 6T1
EMail : bidulock@openss7.org
Expires: September 23, 2003
20