Internet DRAFT - draft-asveren-sigtran-m3uasgsg
draft-asveren-sigtran-m3uasgsg
Network Working Group T. Asveren
Internet-Draft Ulticom Inc.
Expires: June 3, 2006 B. Bidulock
OpenSS7 Corporation
J. Pastor-Balbas
Ericsson Espana S.A.
November 30, 2005
M3UA SG-SG Communication
draft-asveren-sigtran-m3uasgsg-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on June 3, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a protocol to support the communication
between M3UA SGs in IP domain. The functionality needed by SGs to
act as relay points between SS7 nodes is also addressed.
Asveren, et al. Expires June 3, 2006 [Page 1]
Internet-Draft M3UA SG-SG Communication November 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 3
2. Functional Areas . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Signaling Point Code Representation . . . . . . . . . . . 4
2.2. Routing Keys and Routing Context . . . . . . . . . . . . . 4
2.3. Network Appearence . . . . . . . . . . . . . . . . . . . . 4
2.4. SCTP Associations . . . . . . . . . . . . . . . . . . . . 5
2.5. Communication Initiation . . . . . . . . . . . . . . . . . 5
2.6. Message Distribution . . . . . . . . . . . . . . . . . . . 5
2.7. Congestion Handling . . . . . . . . . . . . . . . . . . . 6
2.8. Restricted Destinations . . . . . . . . . . . . . . . . . 6
3. Message Types and Parameters . . . . . . . . . . . . . . . . . 6
4. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Destiantion User Part Available(DUPU) . . . . . . . . . . 7
4.2. Signaling Congestion (SCON) . . . . . . . . . . . . . . . 7
4.3. Congestion Test Message (CGT) . . . . . . . . . . . . . . 8
4.4. Changeover Mechanism Related Messages . . . . . . . . . . 10
4.4.1. Changeover Request Message (COR) . . . . . . . . . . . 10
4.4.2. Changeover Request Acknowledgement Message (CORA) . . 11
5. SG and SGP State Machines . . . . . . . . . . . . . . . . . . 12
5.1. SGP State Machine . . . . . . . . . . . . . . . . . . . . 12
5.2. SG State Machine . . . . . . . . . . . . . . . . . . . . . 13
6. Management Procedures . . . . . . . . . . . . . . . . . . . . 14
6.1. ASPUP Procedures . . . . . . . . . . . . . . . . . . . . . 14
6.2. ASP Down Procedures . . . . . . . . . . . . . . . . . . . 15
6.3. ASP Active Procedures . . . . . . . . . . . . . . . . . . 15
7. Examples of SG-SG Communication Procedures . . . . . . . . . . 15
7.1. M3UA Availability Declaration . . . . . . . . . . . . . . 15
7.2. PC Status Announcement . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Asveren, et al. Expires June 3, 2006 [Page 2]
Internet-Draft M3UA SG-SG Communication November 2005
1. Introduction
This document describes a protocol to support the communication
between M3UA[1] SGs in IP domain.
1.1. Terminology
This document uses the terminology in RFC3332 [1] with the following
additions:
COA Changeover Acknowledgement MTP3 message
COO Changeover Order MTP3 message
ECA Emergency Changeover Acknowledgement MTP3 message
ECM Emergency Changeover MTP3 message
Relaying Relaying is used throughout this document with the meaning
of providing transfering functionality for messages, which are not
destined for the own PC, like a STP does in SS7 network.
TFC Transfer Controlled MTP3 message
1.2. Scope
This document defines a communication mechanism between M3UA SGs.
The main motivation for such a mechanism is allowing message relaying
on SGs. This relaying could happen between two nodes in TDM based
domain, between two nodes in IP based domain or between a node in TDM
based domain and a node in IP based domain.
M3UA SG-SG communication could be utilized for different reasons:
o To offload SS7 traffic over IP network
o To replace TDM based C-links between two SGs
o To build a hierarchical network topology for easier provisioning
o To provode security gateway functionality between different
administrative domains
( ) ( )
( SS7 ) +-----+ +-----+ ( SS7 )
( segment )---+ SG1 +----+ SG2 +---( segment )
( 1 ) +-----+ +-----+ ( 2 )
( ) ( )
Figure 1. Connecting two SS7 segments with SG-SG communication
1.3. Architecture
The goal of SG-SG communication is to define a peer-to-peer
relationship between two M3UA IP doamin entities, which can be used
both for direct communication and for message relaying. For that
reason SG-SG communication model mimics the relationship between two
Asveren, et al. Expires June 3, 2006 [Page 3]
Internet-Draft M3UA SG-SG Communication November 2005
MTP3[3] signaling points. This allows inheritance of necessary MTP3
procedures without any modeling problems.
In the context of SG-SG communication, a SG MAY be controlling one or
more SPMCs. 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
controling SG MAY be based on the ASP/SGP realtionship as defined by
M3UA or MAY be implementation dependent.
SG-SG communication management is based mainly on SSNM as defined in
M3UA. Communication of peers is in PC granularity.
Each SG MAY consist of multiple SGPs. It should be noted that all
MTP3 related logic for own PC, for SPMCs directly connected and for
remote PCs function as a signle entity in the whole SG.
SG
************************************
* +------------------------------+ *
* | MTP3 Logic | *
* +----+---+----+---+----+--+----+ *
* |SGP1| |SGP2| |SGP3| |SGP4| *
* +----+ +----+ +----+ +----+ *
************************************
| | | |
Figure 2. SG consisting of multiple SGPs
2. Functional Areas
2.1. Signaling Point Code Representation
If a SG controls a SPMC, it SHOULD control it as a whole. When a
SPMC becomes available, SG will broadcast DAVA to all adjacent SGs.
Similarly when a SPMC becomes unavailable DUNA and when SPMC becomes
restricted DRST SHOULD be sent.
2.2. Routing Keys and Routing Context
There is no Routing Context/Routing Key concept present in SG-SG
communication.
2.3. Network Appearence
Network Appearence is used in the messages as described in M3UA.
Asveren, et al. Expires June 3, 2006 [Page 4]
Internet-Draft M3UA SG-SG Communication November 2005
2.4. SCTP Associations
SCTP[2] with multihoming feature MUST be used as transport protocol
for SG-SG communication.
There is no client/server relationship between SGPs. SCTP
associations MAY be initiated by any SG. A collision, which might
happen if both sides try to establish SCTP association concurrently
is handled by SCTP protocol itself.
Although SGPs are allowed to have more than one SCTP association
between them, such a configuration is NOT RECOMMENDEDr, as SCTP
multihoming provides an excellent way to achieve redundnacy in a
trnsparent way to upper layers with no message loss/duplication/
missequencing. For that reason, equivalent of MTP3 changeover and
changeback procedures are not defined for SG-SG communication.
2.5. Communication Initiation
After a SCTP association is established, peers MUST declare the
availability of their M3UA layer with ASPUP message. A received
ASPUP is replied with ASPUP-ACK. If one peer receives ASPUP message
before sending ASPUP, it MAY send ASPUP message. A received ASPUP or
ASPUP-ACK message declares availability of the peer. A SGP can
declare its unavailability with ASPDN message. ASPDN is acknowledged
with ASPDN-ACK message.
After the availability of M3UA layers is confirmed, SGs will exchange
SSNM to update to update the remore peer about the status of 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 DUAN for unavailable PCs and DRST
for restricted PCs. The end of this of this unavailable/restricted
PC announcement is marked with an ASPAC message. A received ASPAC is
replied wit an ASPAC-ACK message. SSNM and ASPAC/ASPAC-ACK are sent
per SG. A SG SHOULD NOT start sending DATA messages 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 may arise due to missequencing.
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. If there
is no such peer SG, DATA messages SHOULD be sent to SGs, which
declared the destination as restricted. If no such SG exists, the
Asveren, et al. Expires June 3, 2006 [Page 5]
Internet-Draft M3UA SG-SG Communication November 2005
message SHOULD be dropped.
Message distribution among remote SGs is implementation dependent.
Message distribution among SGPs belonging to the same SG is
determined by the sender of the message. A SG SHOULD be preprared to
receive messages by any of its SGPs in UP state.
Messages, for which sequencing has to be preserved SHOULD be sent via
the same SCTP association using the same stream.
In case, the destination to which a certain group of messages changes
,e.g due to a new SGP becoming UP, procedures similiar to time-
controlled diversion and time-controlled changeover as decribed by
MTP3 SHOULD be followed to reduce the possibility of message
missequencing.
2.7. Congestion Handling
Congestion handling procedures as defined in relevant MTP3 standards
SHOULD be followed. It is responsibility of a SG to follow those
procedures on behalf of the SPMCs it 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 SG.
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 defined as new SSNM in addition
to existing ones 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 Signaling Link Code 0x0215
4. Protocol Messages
Asveren, et al. Expires June 3, 2006 [Page 6]
Internet-Draft M3UA SG-SG Communication November 2005
DATA, SSNM messages, ERROR, ASPUP/ASPUP-ACK, ASPAC/ASPAC-ACK messages
are used for SG-SG communication. RC field in the messages is not
used, i.e. it MUST not be filled.
4.1. Destiantion User Part Available(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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Concerned DPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0204 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause | User |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2. Signaling Congestion (SCON)
For SG-SG communication, Concerned DPC parameter is mandatory. It
contains the point code for the signaling point, which originated the
message causing SCON to be generated.
There will be two Affected PC fields present. The first one contains
the point code of the originator of the SCON -or the corresponding
Asveren, et al. Expires June 3, 2006 [Page 7]
Internet-Draft M3UA SG-SG Communication November 2005
TFC- message and the second one contains the point code 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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3. Congestion Test Message (CGT)
CGT is used to support Signaling Route Set Congestion Test(National
Option) procedures as defined by MTP3. It is used instead of RCT
MTP3 message.
The CGT message contains the following parameters:
Affected PC Mandatory
Concerned DPC Mandatory
Congestion Level Mandatory
Info String Optional
Asveren, et al. Expires June 3, 2006 [Page 8]
Internet-Draft M3UA SG-SG Communication November 2005
The format for the 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 Appearence: 32 bits (semi-mandatory)
See M3UA Section 3.1.1
Affected Point Code: 32 bits (mandatory)
Affected Point Code parameter contains the 14-, 16-, 24-bit binary
formatted point code value, for which CGT message is generated.
Congestion Levels: 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
When sending CGT message, procedures defined for Signaling Route Set
Congestion Test in Q.704 Clause 13.9 SHOULD be followed.
Asveren, et al. Expires June 3, 2006 [Page 9]
Internet-Draft M3UA SG-SG Communication November 2005
4.4. Changeover Mechanism Related Messages
SG-SG communication does not rely on a mechanism similar to M3UA
changeover mechanism for redundancy purposes , but a SG may relay
MTP3 changeover mechanism related messages.
+-------+ +-------+
| SS7 | | SG2 |
| node1 +--------X-------+ |
COO(1)+---+---+ ^ +----+--+ CORA(3)
| ^ | | | ^ |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
V | | | +-------+ | | V
COA(4)| | | SG1 | | COR(2)
+-----+-+ +---------+
^ | +-------+ ^
| | |
| | |
| | |
| | |
TDM IP
Figure 3. SG1 relaying changeover messages to and from SG2
4.4.1. Changeover Request Message (COR)
COR is used to relay changeover order/emergency changeover order
information to/from a peer in TDM domain. There are two cases, where
it can be used: either it is received from a SG peer, where a
corresponding COO/ECM is sent to a conventional SS7 peer or it can be
sent to a SG, after COO/ECM has been received from a conventional SS7
node.
COR message contains the following parameters:
Network Appearence: 32 bits (semi-mandatory)
See M3UA Section 3.1.1
SLC: 5 bits (mandatory)
The signaling link code of the failed link.
FSN: 24-bits (semi-mandatory)
Forward sequence number of the last message signal unit accepted from
the unavailable signalink link by the sender of the message. If COR
Asveren, et al. Expires June 3, 2006 [Page 10]
Internet-Draft M3UA SG-SG Communication November 2005
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 conventional SS7 peer, FSN MUST be filled in
COR. When ECM is received from a conventioanal 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 send COO/ECM message.
Concerned Point Code: 32 bits (mandatory)
Concerned Point Code parameter contains he 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 inforamtion for the last accepted MSU
on a failed link between a peer SG and a conventional SS7 node as an
answer to COR.
COR message contains the following parameters:
Asveren, et al. Expires June 3, 2006 [Page 11]
Internet-Draft M3UA SG-SG Communication November 2005
Network Appearence: 32-bit (semi-mandatory)
See M3UA Section 3.1.1
SLC: 5 bits (mandatory)
The signaling link code of the failed link.
FSN: 24 bits (semi-mandatory)
Forward sequence number of the last message signal unit accepted from
the unavailable signalink 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 conventional SS7 node, FSN MUST be filled in CORA.
When ECA is received from a conventional SS7 node, 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 COA/ECA 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.
5. SG and SGP State Machines
5.1. SGP State Machine
The state of each remote SGP is maintened 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 SGP M3UA layer.
* Reception of indications from the SCTP layer.
* Local management intervention.
The SGP state transition diagram is shown below. 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 ASPDN-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.
Asveren, et al. Expires June 3, 2006 [Page 12]
Internet-Draft M3UA SG-SG Communication November 2005
+--------+
|SGP UP |
+-+----+-+
ASPUP or ^ | ASPDOWN/ASPDOWN-ACK
ASPUP-ACK | | SCTP CDI/SCTP RI
| |
| v
+-+----+-+
|SGP DOWN|
+--------+
Figure 4. SGP State Machine
5.2. SG State Machine
The state machine of each remote SG is maintained in the SGP. SGPs
belonging to the same SG MUST have a uniqie view of a remote SG. The
state of a particular SG changes due to the events. The events
include:
* Reception of messages from the peer SG/SGP.
* State changes of local SGPs.
* Local management intervention.
The SG state transition diagram is shown below. Possible states of a
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, DATA messages SHOULD NOT be sent to the remote SG.
SG ACTIVE: There is at least one SGP belonging to this SG in SGP UP
state and SG has finished PC announcement phase.
Asveren, et al. Expires June 3, 2006 [Page 13]
Internet-Draft M3UA SG-SG Communication November 2005
+--------+
| 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 5. SG State Machine
6. Management Procedures
6.1. ASPUP 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 SGP is in SGP-UP state, SGP
stays in SGP-UP state and an ASPUP-ACK message is sent. In such a
situation, if the SGP sending ASPUP message was the only SGP in
SGP-UP state and if the SG is in SG-ACTIVE state, SG state is chnaged
to SG-UP state.
Asveren, et al. Expires June 3, 2006 [Page 14]
Internet-Draft M3UA SG-SG Communication November 2005
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.
6.2. ASP Down Procedures
When a SGP does not want to send/receive DATA messages to/from a SGP,
for which it was already in SGP-UP state, it sends ASPDN 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, intiially 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 establishmnet of SCTP association between SGPs,
each SGP should make its peers aware that its own M3UA layer is
ready.
Asveren, et al. Expires June 3, 2006 [Page 15]
Internet-Draft M3UA SG-SG Communication November 2005
SGP1 SGP2 SGP3 SGP4
| | | |
+------ASPUP----------->| |
| | | |
+------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. The scenario shows message exchange after M3UA
availability declaration is performed. Pc1/PC2/PC3 are configured as
reachable via SG2 in SG1 and PC4/PC5 are configured as reachable via
SG1 in SG2. During PC Status Announcement procedure, PC1 is
unavailable in SG1 and PC2 is restricted. PC4 is unavailable in SG2.
Asveren, et al. Expires June 3, 2006 [Page 16]
Internet-Draft M3UA SG-SG Communication November 2005
SGP1 SGP2 SGP3 SGP4
| | | |
|-------DUNA(PC1)--------->| |
| | | |
|-------DRST(PC2)--------->| |
| | | |
|------ASPAC-------------->| |
| | | |
|<-----ASPAC-ACK-----------| |
| | | |
|<--------+----DUNA(PC4)---+---------|
| | | |
|<--------+----ASPAC-------+---------|
| | | |
|---------+----ASPAC-ACK---+-------->|
| | | |
|<------DATA(PC3)----------| |
| | | |
| |----DATA(PC5)-->| |
| | | |
8. IANA Considerations
9. Security Considerations
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
places 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 networks more vulnerable to intentioanl 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 or a combination of them. Other more
sophisticated message syntax, message type and content based
screening could also be implemented to improve security.
Asveren, et al. Expires June 3, 2006 [Page 17]
Internet-Draft M3UA SG-SG Communication November 2005
10. Acknowledgments
The authors would like to thank Manfred Angermayr, Vaibhav Madan, Ken
Morneault and Kutluk Uslu for their valuable comments and
suggestions.
11. Normative References
[1] Sidebottom, G., Morneault, K., and J. Pastor-Balbas, "Signaling
System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation
Layer (M3UA)", RFC 3332, September 2002.
[2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[3] ITU, "Q.704 (07/96) Specifications of Signalling System No. 7 -
Message transfer part".
Asveren, et al. Expires June 3, 2006 [Page 18]
Internet-Draft M3UA SG-SG Communication November 2005
Authors' Addresses
Tolga Asveren
Ulticom Inc.
1020 Briggs Road
Mount Laurel, NJ, 08054
USA
Email: asveren@ulticom.com
Brian Bidulock
OpenSS7 Corporation
1469 Jeffreys Crescent
Edmonton, AB T6L 6T1
Canada
Email: bidulock@openss7.org
Javier Pastor-Balbas
Ericsson Espana S.A.
C/ Retama1
28045 Madrid
Spain
Email: j.javier.pastor@ericsson.com
Asveren, et al. Expires June 3, 2006 [Page 19]
Internet-Draft M3UA SG-SG Communication November 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Asveren, et al. Expires June 3, 2006 [Page 20]
