draft-ietf-sigtran-m2ua-00.txt   draft-ietf-sigtran-m2ua-01.txt 
Network Working Group Ken Morneault Network Working Group Ken Morneault
INTERNET-DRAFT Cisco Systems INTERNET-DRAFT Cisco Systems
Malleswar Kalla Mallesh Kalla
Telcordia Telcordia
Greg Sidebottom Greg Sidebottom
Nortel Networks Nortel Networks
Ram Dantu
Alcatel
Expires in six months September 1999 Expires in six months October 1999
SS7 MTP2-User Adaptation Layer SS7 MTP2-User Adaptation Layer
<draft-ietf-sigtran-m2ua-00.txt> <draft-ietf-sigtran-m2ua-01.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 42 skipping to change at page 1, line 44
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
'1id-abstracts.txt' listing contained in the Internet- Drafts Shadow '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Abstract Abstract
This Internet Draft defines a protocol for backhauling of SS7 MTP2 This Internet Draft defines a protocol for backhauling of SS7 MTP2
User signaling messages over IP using the Sigtran Common Transport User signaling messages over IP using the Simple Control Transmission
Protocol (SCTP). This protocol would be used between a Signaling Protocol (SCTP). One application of this protocol would be to use it
Gateway (SG) and Media Gateway Controller (MGC). It is assumed that between a Signaling Gateway (SG) and Media Gateway Controller (MGC).
In this case, the Signaling Gateway would be acting as a Signaling
Link Terminal. Another application of this protocol would be to use
it between a SG and a SCP. In either application, it is assumed that
the SG receives SS7 signaling over a standard SS7 interface using the the SG receives SS7 signaling over a standard SS7 interface using the
SS7 Message Transfer Part (MTP) to provide transport. SS7 Message Transfer Part (MTP) to provide transport.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction..............................................2 1. Introduction..............................................2
1.1 Scope..................................................2 1.1 Scope..................................................2
1.2 Terminology............................................3 1.2 Terminology............................................3
1.3 Signaling Transport Architecture.......................3 1.3 Signaling Transport Architecture.......................3
1.4 Services Provide by the M2UA Adaptation Layer..........4 1.4 Services Provide by the M2UA Adaptation Layer..........4
1.5 Function Provided by the M2UA Layer....................6 1.5 Function Provided by the M2UA Layer....................6
1.6 Definition of the M2UA Boundaries......................7 1.6 Definition of the M2UA Boundaries......................7
2. Protocol Elements.........................................8 2. Protocol Elements.........................................8
2.1 Common Message Header..................................8 2.1 Common Message Header..................................8
2.2 M2UA Message Header....................................9 2.2 M2UA Message Header....................................9
2.3 M2UA Messages.........................................10 2.3 M2UA Messages.........................................10
3. Procedures...............................................17 3. Procedures...............................................17
3.1 Procedures to Support Service in Section 1.4.1........17 3.1 Procedures to Support Service in Section 1.4.1........17
3.2 Procedures to Support Service in Section 1.4.2........17 3.2 Procedures to Support Service in Section 1.4.2........17
3.3 Procedures to Support Service in Section 1.4.3........17 3.3 Procedures to Support Service in Section 1.4.3........17
4. Examples of MTP2 User Adaptation (M2UA) Procedures.......21 4. Examples of MTP2 User Adaptation (M2UA) Procedures.......22
4.1 Establishment of associations between SG and MGC......21 4.1 Establishment of associations between SG and MGC......22
examples examples
4.2 MTP Level 2 / MTP Level 3 Boundary Examples...........22 4.2 MTP Level 2 / MTP Level 3 Boundary Examples...........23
4.3 Layer Management Communication Examples................24 4.3 Layer Management Communication Examples................25
5. Security.................................................24 5. Security.................................................31
6. Acknowledgements.........................................24 6. Acknowledgements.........................................31
7. References...............................................24 7. References...............................................31
8. Author's Addresses.......................................25 8. Author's Addresses.......................................32
1. Introduction 1. Introduction
1.1 Scope 1.1 Scope
There is a need for SCN signaling protocol delivery from an Signaling There is a need for SCN signaling protocol delivery from an Signaling
Gateway (SG) to a Media Gateway Controller (MGC). The delivery Gateway (SG) to a Media Gateway Controller (MGC) or Signaling Control
mechanism should meet the following criteria: Point (SCP). The delivery mechanism should meet the following criteria:
* Support for MTP Level 2 / MTP Level 3 interface boundary * Support for MTP Level 2 / MTP Level 3 interface boundary
* Support for communication between Layer Management modules on SG and * Support for communication between Layer Management modules on SG and
MGC MGC
* Support for management of active associations between the SG and MGC * Support for management of active associations between the SG and MGC
In other words, the Signaling Gateway will terminate MTP Level 1 and MTP In other words, the Signaling Gateway will transport MTP Level 3 messages
Leve 2 and will transport MTP Level 3 messages to a Media Gateway to a Media Gateway Controller (MGC) or Signaling Control Point (SCP).
Controller (MGC).
1.2 Terminology 1.2 Terminology
MTP2-User - A protocol that normally uses the services of MTP Level 2 MTP2-User - A protocol that normally uses the services of MTP Level 2
(i.e. MTP3). (i.e. MTP3).
Interface - For the purposes of this document, an interface is a SS7 Interface - For the purposes of this document, an interface is a SS7
signaling link. signaling link.
Association - An association refers to a SCTP association. The Association - An association refers to a SCTP association. The
skipping to change at page 3, line 25 skipping to change at page 3, line 25
data units for one or more interfaces. data units for one or more interfaces.
Stream - A stream refers to a SCTP stream. For the purposes of this Stream - A stream refers to a SCTP stream. For the purposes of this
document, a stream will be mapped to a SS7 signaling link, or interface. document, a stream will be mapped to a SS7 signaling link, or interface.
Backhaul - Refers to the transport of signaling from the point of Backhaul - Refers to the transport of signaling from the point of
interface for the associated data stream (i.e., SG function in the MGU) interface for the associated data stream (i.e., SG function in the MGU)
back to the point of call processing (i.e., the MGCU), if this is not back to the point of call processing (i.e., the MGCU), if this is not
local [4]. local [4].
Application Server Process - A process instance of an Application Server. Application Server (AS) - A logical entity serving a specific application
Up to 3 processes can be defined (Primary, Secondary and Tertiary). instance. An example of an Application Server is a MGC handling the
Examples of Application Server Processes are primary or backup MGC MTP Level 3 and call processing for SS7 links terminated by the Signaling
instances. Gateways. Practically speaking, an AS is modeled at the SG as an ordered
list of one or more related Application Server Processes (e.g., primary,
secondary, tertiary, ).
Application Server Process Path (or just Path) - A Path to a remote Application Server Process (ASP) - A process instance of an Application
Application Server Process instance. A Path maps 1:1 to an SCTP Server. Examples of Application Server Processes are primary or backup
association). MGC instances.
Application Server - Groups all the Application Server Processes Application Server Process Path (ASP Path or just Path) - A Path to a
associated with an application (e.g., primary, secondary, tertiary). remote Application Server Process instance. A Path maps 1:1 to an SCTP
Examples of Application Servers are virtual MGCs or IP Databases. association.
Fail-over - The capability to re-route signaling traffic as required Fail-over - The capability to re-route signaling traffic as required
between related Application Server Processes in the event of failure or to a next-preferred Application Server Process within an Application
unavailability of the currently used Application Server Process (e.g., Server in the event of failure or unavailability of the currently used
from primary MGC to back-up MGC). Fail-over also applies upon the Application Server Process (e.g., from primary MGC to back-up MGC).
return to service of a previously unavailable Process. Fail-over may also apply upon the return to service of a previously
unavailable Application Server Process.
Signaling Link Terminal (SLT) - Refers to the means of performing all Signaling Link Terminal (SLT) - Refers to the means of performing all
of the functions defined at MTP level 2 regardless of their of the functions defined at MTP level 2 regardless of their
implementation [2]. implementation [2].
1.3 Signaling Transport Architecture 1.3 Signaling Transport Architecture
The architecture that has been defined for SCN signaling transport The architecture that has been defined for SCN signaling transport
over IP uses multiple components, including an IP transport over IP uses multiple components, including an IP transport
protocol, a signaling common transport protocol (SCTP) and an adaptation protocol, a signaling common transport protocol (SCTP) and an adaptation
module to support the functions expected by a particular SCN signaling module to support the functions expected by a particular SCN signaling
protocol from its underlying protocol layer. protocol from its underlying protocol layer.
In reference to the SIGTRAN framework architecture [4], this document In reference to the SIGTRAN framework architecture [4], this document
defines a SCN adaptation module that is suitable for the transport of defines a SCN adaptation module that is suitable for the transport of
SS7 MTP2 User. The only SS7 MTP2 User is MTP3. SS7 MTP2 User. The only SS7 MTP2 User is MTP3.
1.3.1 Case 1: SG to MGC
In a Signaling Gateway, it is expected that the SS7 signaling is In a Signaling Gateway, it is expected that the SS7 signaling is
received over a standard SS7 network termination, using the SS7 Message received over a standard SS7 network termination, using the SS7 Message
Transfer Part (MTP) to provide transport of SS7 signaling messages to Transfer Part (MTP) to provide transport of SS7 signaling messages to
and from an SS7 Signaling End Point (SEP) or SS7 Signaling Transfer and from an SS7 Signaling End Point (SEP) or SS7 Signaling Transfer
Point (STP). In other words, the SG acts as a Signaling Link Terminal Point (STP). In other words, the SG acts as a Signaling Link Terminal
(SLT) [2]. The SG then provides interworking of transport functions (SLT) [2]. The SG then provides interworking of transport functions
with IP Signaling Transport, in order to transport the MTP3 signaling with IP Signaling Transport, in order to transport the MTP3 signaling
messages to the MGC where the peer MTP3 protocol layer exists, as shown messages to the MGC where the peer MTP3 protocol layer exists, as shown
below: below:
skipping to change at page 4, line 38 skipping to change at page 4, line 48
+----+ +----+----+ +----+ +----+ +----+----+ +----+
|MTP | |MTP |M2UA| |M2UA| |MTP | |MTP |M2UA| |M2UA|
|L3 | | +----+ +----+ |L3 | | +----+ +----+
|L2 | |L2 |SCTP| |SCTP| |L2 | |L2 |SCTP| |SCTP|
|L1 | |L1 +----+ +----+ |L1 | |L1 +----+ +----+
| | | |UDP | |UDP | | | | |UDP | |UDP |
+----+ +---------+ +----+ +----+ +---------+ +----+
SEP - SS7 Signaling Endpoint SEP - SS7 Signaling Endpoint
UDP - User Datagram Protocol UDP - User Datagram Protocol
SCTP - Signaling Common Transport Protocol SCTP - Simple Control Transmission Protocol
(Refer to Reference [5]) (Refer to Reference [5])
Figure 1: Figure 1: M2UA in the SG to MGC Application
Note: STPs may be present in the SS7 path between the SEP and the SG. Note: STPs may be present in the SS7 path between the SEP and the SG.
1.3.1 UDP port 1.3.2 Case 2: SG to IPSCP
The following figure shows the seamless interworking at MTP3 layer.
MTP3 is adapted to SCTP layer using MTP2 User Adaptation Layer. In this
example, the Signaling Gateway can be a STP. All the primitives between
MTP3 and MTP2 are supported using MTP2 User Adaptation Layer (MTP2UA).
In the following example, the Signaling Gateway could also have SCCP
layer for providing Gateway Screening functionality for the IPSCP.
****** SS7 ****** IP ************
*SEP *-------* SG *-------------* IPSCP *
****** ****** ************
+----+ +---------+
|TCAP| | TCAP |
+----+ +---------+
|SCCP| | SCCP |
+----+ +---------+ +---------+
|MTP | | MTP | | MTP |
|L3 | | L3 | | L3 |
|L2 | +----+----+ +----+----+
|L1 | |MTP |M2UA| |M2UA|MTP |
| | |L2 +----+ +----+L2 |
| | |L1 |SCTP| |SCTP|L1 |
| | | |----| |----| |
| | | |UDP | |UDP | |
+----+ +----+----+ +----+----+
SEP - SS7 Signaling Endpoint
IPSCP - IP Signaling Control Point
UDP - User Datagram Protocol
SCTP - Simple Control Transmission Protocol
(Refer to Reference [5])
Figure 2: M2UA in the SG to IPSCP Application
Note that in this case, the SCTP association acts as a SS7 link between
the SG and IPSCP. The IPSCP may or may not have a termination to the
SS7 network.
1.3.3 UDP port
A request will be made to IANA to assign a UDP port for M2UA. A request will be made to IANA to assign a UDP port for M2UA.
1.4 Services Provided by the M2UA Adaptation Layer 1.4 Services Provided by the M2UA Adaptation Layer
The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination
point in the IP network, so that the M2UA protocol layer is required to point in the IP network, so that the M2UA protocol layer is required to
provide the equivalent set of services to its users as provided by the provide the equivalent set of services to its users as provided by the
MTP Level 2 to MTP Level 3. MTP Level 2 to MTP Level 3.
skipping to change at page 7, line 27 skipping to change at page 8, line 27
from the SCTP). If the M2UA layer receives this indication, the action(s) from the SCTP). If the M2UA layer receives this indication, the action(s)
taken are implementation dependent. taken are implementation dependent.
1.5.4 SCTP Stream Management 1.5.4 SCTP Stream Management
SCTP allows user specified number of streams to be opened during the SCTP allows user specified number of streams to be opened during the
initialization. It is the responsibility of the M2UA layer to ensure initialization. It is the responsibility of the M2UA layer to ensure
proper management of these streams. SCTP streams provide a means for proper management of these streams. SCTP streams provide a means for
avoiding head of line blocking. For that reason, a stream will be used avoiding head of line blocking. For that reason, a stream will be used
per SS7 signaling link terminated by the Signaling Gateway. The SS7 per SS7 signaling link terminated by the Signaling Gateway. The SS7
signaling link is identified by the Interface Identifier in the message signaling link can be identified by the optional Interface Identifier
header (refer to Section 2.3). in the M2UA specific message header (refer to Section 2.2).
1.5.5 Seamless SS7 Network Management Interworking 1.5.5 Seamless SS7 Network Management Interworking
If the SG loses the SCTP association to the MGC, it should follow If the SG loses the SCTP association to the MGC, it should follow
MTP 2 processor outage procedures [2]. MTP 2 processor outage procedures [2].
1.5.6 Management Inhibit/Uninhibit 1.5.6 Management Inhibit/Uninhibit
Local Management may wish to stop traffic across an SCTP association in Local Management may wish to stop traffic across an SCTP association in
order to temporarily remove the association from service or to perform order to temporarily remove the association from service or to perform
skipping to change at page 8, line 36 skipping to change at page 9, line 36
M-ASP STATUS M-ASP STATUS
2.0 Protocol Elements 2.0 Protocol Elements
This section describes the format of various messages used in this This section describes the format of various messages used in this
protocol. protocol.
2.1 Common Message Header 2.1 Common Message Header
The protocol messages for MTP2 User Adaptation require a message header The protocol messages for MTP2 User Adaptation require a message header
structure which contains a version, message type and message length. This structure which contains a version, message type and message length.
message header is common among all SCN adaptation layers. This message header is common among all SCN adaptation layers.
0 7 8 15 16 31 0 7 8 15 16 31
+---------------+---------------+ +---------------+---------------+
| Vers | Spare | Msg Type | | Vers | Spare | Msg Type |
+---------------+---------------+ +---------------+---------------+
| Message Length | | Message Length |
+-------------------------------+ +-------------------------------+
Figure 2 Common Message Header Figure 2 Common Message Header
skipping to change at page 9, line 55 skipping to change at page 10, line 55
2.2 M2UA Message Header 2.2 M2UA Message Header
In addition to the common message header, there will be a M2UA specific In addition to the common message header, there will be a M2UA specific
message header. The M2UA specific message header will immediately message header. The M2UA specific message header will immediately
follow the common message header, but will only be used with MAUP and follow the common message header, but will only be used with MAUP and
MGMT messages. MGMT messages.
This message header will contain the Interface Identifier. The Interface This message header will contain the Interface Identifier. The Interface
Identifier identifies the physical interface at the SG for which the Identifier identifies the physical interface at the SG for which the
signaling messages are sent/received. The interface identifier follows signaling messages are sent/received. Or, the Interface Identifier
the same endpoint naming scheme provided in MGCP [7]. For example, if can be left empty (a null string of length zero). The Interface Identifier
a Signaling Gateway terminates a E1 and the SS7 signaling link is one follows the same endpoint naming scheme provided in MGCP [7]. For example,
if a Signaling Gateway terminates a E1 and the SS7 signaling link is one
timeslot 16, the interface identifier could be the following: timeslot 16, the interface identifier could be the following:
e1/16@sgw1.example.net e1/16@sgw1.example.net
The use of wildcards is not acceptable. The use of wildcards is not acceptable.
Note: The Interface Identifier string should be padded to 32-bit Note: The Interface Identifier string should be padded to 32-bit
boundaries. The length field indicates the end of the string. boundaries. The length field indicates the end of the string.
0 15 16 31 0 15 16 31
skipping to change at page 11, line 51 skipping to change at page 12, line 51
RELEASE_PHYS 0x1 Physical layer alarm generated release. RELEASE_PHYS 0x1 Physical layer alarm generated release.
RELEASE_SIOS 0x2 Receipt of SIOS RELEASE_SIOS 0x2 Receipt of SIOS
RELEASE_OTHER 0x3 Other reason SS7 link out-of-service RELEASE_OTHER 0x3 Other reason SS7 link out-of-service
(should we keep it simple, or provide list of reasons that would (should we keep it simple, or provide list of reasons that would
enable debugging) enable debugging)
2.3.1.4 State (Request, Confirm) 2.3.1.4 State (Request, Confirm)
The State Request message can be sent from a MGC to cause an action The State Request message can be sent from a MGC to cause an action
on a particular SS7 link supported by the Signaling Gateway. The gateway on a particular SS7 link supported by the Signaling Gateway. The
sends a State Confirm to the MGC if the action has been successfully gateway sends a State Confirm to the MGC if the action has been success-
completed. The State Confirm reflects that state value received in fully completed. The State Confirm reflects that state value received
the State Request message. in the State Request message.
0 15 16 31 0 15 16 31
+---------------+---------------+ +---------------+---------------+
| State | | State |
+---------------+---------------+ +---------------+---------------+
The valid values for State are shown in the following table. The valid values for State are shown in the following table.
Define Value Description Define Value Description
STATUS_LOC_PROC_SET 0x0 Request local processor outage. STATUS_LOC_PROC_SET 0x0 Request local processor outage.
STATUS_LOC_PROC_CLEAR 0x1 Request local processor outage recovered. STATUS_LOC_PROC_CLEAR 0x1 Request local processor outage
STATUS_EMER_SET 0x2 Request emergency alignment procedure. recovered.
STATUS_EMER_SET 0x2 Request emergency alignment
procedure.
STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel
emergency) procedure. emergency) procedure.
STATUS_FLUSH_BUFFERS 0x4 Flush transmit and retransmit buffers. STATUS_FLUSH_BUFFERS 0x4 Flush transmit and retransmit buffers.
STATUS_CONTINUE 0x5 Continue. STATUS_CONTINUE 0x5 Continue.
2.3.1.5 State Indication 2.3.1.5 State Indication
The MTP2 State Indication message can be sent from a gateway to a call The MTP2 State Indication message can be sent from a gateway to a call
agent to indicate a condition on a channel. agent to indicate a condition on a channel.
skipping to change at page 15, line 40 skipping to change at page 16, line 38
##### #####
2.3.2.3 ASP Active (ASPAC) 2.3.2.3 ASP Active (ASPAC)
The ASPAC message is sent by an ASP to indicate to an SG that it is The ASPAC message is sent by an ASP to indicate to an SG that it is
the active ASP to be used from within a list of primary and back-up ASPs the active ASP to be used from within a list of primary and back-up ASPs
for a particular signaling mapping relationship. for a particular signaling mapping relationship.
The ASPAC message contains the following parameters: The ASPAC message contains the following parameters:
Controlled/Forced flag (C/F flag)
INFO String INFO String
The format for the ASPAC message is as follows: The format for the ASPAC message is as follows:
0 15 16 31 0 15 16 31
+---------------+---------------+ +---------------+---------------+
| C/F flag |
+---------------+---------------+
| Tag (0x4) | Length | | Tag (0x4) | Length |
+---------------+---------------+ +---------------+---------------+
| INFO String | | INFO String |
+---------------+---------------+ +---------------+---------------+
The valid values for C/F flag are shown in the following table.
Define Value Description
FORCED 0x0 Force sending of all messages to ASP
CONTROLLED 0x1 Only send "new work" to ASP
2.3.2.4 ASP Inactive (ASPIA) 2.3.2.4 ASP Inactive (ASPIA)
The ASPIA message is sent by an ASP to indicate to an SG that it is The ASPIA message is sent by an ASP to indicate to an SG that it is
no longer the the active ASP to be used from within a list of primary no longer the the active ASP to be used from within a list of primary
and back-up ASP for a particular signaling mapping relationship. The and back-up ASP for a particular signaling mapping relationship. The
SG will respond with an ASPIA message and either buffer or discard SG will respond with an ASPIA message and either buffer or discard
incoming messages for a timed period and then discard. incoming messages for a timed period and then discard.
The ASPIA message contains the following parameters: The ASPIA message contains the following parameters:
skipping to change at page 17, line 50 skipping to change at page 19, line 5
3.2.2 LM message procedures 3.2.2 LM message procedures
Upon receipt of LM messages the M2UA layer must invoke the corresponding Upon receipt of LM messages the M2UA layer must invoke the corresponding
Layer Management primitives (M-ERROR) to the local layer management. Layer Management primitives (M-ERROR) to the local layer management.
3.3 Procedures to Support Service in Section 1.4.3 3.3 Procedures to Support Service in Section 1.4.3
These procedures achieve the M2UA layer's "Support for management of These procedures achieve the M2UA layer's "Support for management of
active associations between SG and MGC" service. active associations between SG and MGC" service.
3.3.1 AS and ASP State 3.3.1 State Maintenance
3.3.1.1 ASP States
The state of the each ASP is maintained in the M2UA layer on the SG. The The state of the each ASP is maintained in the M2UA layer on the SG. The
state of an ASP changes due to events. The events include: state of an ASP changes due to events. The events include:
* Reception messages from peer M2UA layer * Reception messages from peer M2UA layer
* Reception of indications from layers below * Reception of indications from layers below
The ASP state transition diagram is shown in Figure 4. The ASP state transition diagram is shown in Figure 4. The possible
states of an ASP are:
The possible states of an ASP are:
ASP-DOWN: Application Server Process is unavailable. Initially all ASPs ASP-DOWN: Application Server Process is unavailable. Initially all ASPs
are in this state. are in this state.
ASP-UP: Application Server Process is available but application traffic is ASP-UP: Application Server Process is available but application traffic is
stopped. stopped.
ASP-ACTIVE: Application Server Process is available and application traffic ASP-ACTIVE: Application Server Process is available and application
is active. At most one ASP per AS can be in the active state. traffic is active. At most one ASP per AS can be in the active state.
Figure 4: ASP State Transition Diagram
+-------------+ +-------------+
|-------->| | |-------->| |
| | ASP-ACTIVE | | | ASP-ACTIVE |
| | | | | |
| | | | | |
| +-------------+ | +-------------+
| ^ | | ^ |
| ASP | | ASP | ASP | | ASP
| Active | | Inactive | Active | | Inactive
skipping to change at page 18, line 47 skipping to change at page 20, line 5
| Up | | SCTP CDI | Up | | SCTP CDI
| | v | | v
| +-------------+ | +-------------+
| | | | | |
|-------->| | |-------->| |
| ASP-DOWN | | ASP-DOWN |
| | | |
| | | |
+-------------+ +-------------+
SCTP CDI: Local SCTP layer's Communication Down Indication to the Upper Layer SCTP CDI: Local SCTP layer's Communication Down Indication to the Upper
Protocol (M2UA) on an SG. SCTP will send this indication when it Layer Protocol (M2UA) on an SG. SCTP will send this indication when
detects the loss of connectivity to ASP's SCTP layer. it detects the loss of connectivity to ASP's SCTP layer.
Figure 4: ASP State Transition Diagram 3.3.1.2 AS States
The state of the AS is maintained in the ITUN layer on the SG.
The state of an AS changes due to events. These events include:
* ASP state transitions
* Recovery timer triggers
The possible states of an AS are: The possible states of an AS are:
AS-DOWN: Application Server is unavailable. This state implies that all AS-DOWN: Application Server is unavailable. This state implies that all
ASPs are in the ASP-DOWN state for this AS. ASPs are in the ASP-DOWN state for this AS.
AS-UP: One or more ASPs are in the ASP-UP state. AS-UP: One or more ASPs are in the ASP-UP state.
AS-ACTIVE: Application Server is available and application traffic is AS-ACTIVE: Application Server is available and application traffic is
active. This state implies that one ASP is in the ASP-ACTIVE state. active. This state implies that one ASP is in the ASP-ACTIVE state.
AS-PENDING: Currently Active ASP became inactive or SCTP association with it AS-PENDING: Currently Active ASP became inactive or SCTP association with it
is lost. A Recovery timer will be started and in coming SCN messages will is lost. A Recovery timer will be started and in coming SCN messages will
be queuedby the SG. If an ASP becomes Active before the recovery timer be queuedby the SG. If an ASP becomes Active before the recovery timer
expires, AS will move to AS-ACTIVE state and all the queued messages will expires, AS will move to AS-ACTIVE state and all the queued messages will
be sent to the active ASP. If the recovery timer expires before an ASP be sent to the active ASP. If the recovery timer expires before an ASP
becomes active, SG stops queuing messages and discards all queued messages. becomes active, SG stops queuing messages and discards all queued messages.
AS will move to AS-UP if at least one ASP is in ASP-UP state, otherwise it AS will move to AS-UP if at least one ASP is in ASP-UP state, otherwise it
will move to AS-DOWN state. will move to AS-DOWN state.
Note: If AS moves from AS-PENDING state to AS-UP or AS-DOWN states, the Layer If T(r) expires before an ASP becomes active, the SG stops queuing messages
Management on MG may take appropriate SCN notification actions. and discards all previously queued messages. The AS will move to AS-UP if
at least one ASP is in ASP-UP state, otherwise it will move to AS-DOWN state.
+----------+ one ASP trans ACTIVE +-------------+ +----------+ one ASP trans ACTIVE +-------------+
| |------------------------>| | | |------------------------>| |
| AS-UP | | AS-ACTIVE | | AS-UP | | AS-ACTIVE |
| | | | | | | |
| |< -| | | |< -| |
+----------+ \ / +-------------+ +----------+ \ / +-------------+
^ | \ Tr Trigger / ^ | ^ | \ Tr Trigger / ^ |
| | \ at least one / | | | | \ at least one / | |
| | \ ASP in UP / | | | | \ ASP in UP / | |
skipping to change at page 20, line 5 skipping to change at page 21, line 39
| |<------------------------| | | |<------------------------| |
+----------+ Tr Trigger no ASP +-------------+ +----------+ Tr Trigger no ASP +-------------+
in UP state or in UP state or
prev ACTIVE ASP trans prev ACTIVE ASP trans
to DOWN state to DOWN state
Tr = Recovery Timer Tr = Recovery Timer
Figure 5: AS State Transition Diagram Figure 5: AS State Transition Diagram
3.3.2 ASP UP Note: If AS moves from AS-PENDING state to AS-UP or AS-DOWN states, the
Layer Management on MG may take appropriate SCN notification actions.
3.3.2.1 SG Operation 3.3.2 ASPM procedures for primitives
Before the establishment of an SCTP association the ASP state at both the
SG and ASP is assumed to be "Down".
When the M2UA layer receives an M-SCTP ESTABLISH request primitive from
the Layer Management, the M2UA layer will try to establish an SCTP
association with the remote M2UA peer. Upon reception of an eventual
SCTP-Communication Up confirm primitive from the SCTP, the M2UA layer
will invoke the primitive M-SCTP ESTABLISH confirm to the Layer Management.
Alternatively, if the remote M2UA-peer establishes the SCTP association
first, the M2UA layer will receive an SCTP Communication Up indication
primitive from the SCTP. The M2UA layer will then invoke the primitive
M-SCTP ESTABLISH indication to the Layer Management.
Once the SCTP association is established, The M2UA layer at an ASP will
then find out the state of its local M2UA-user from the Layer Management
using the primitive M-ASP STATUS. Based on the status of the local
M2UA-User, the local ASP ITUN Application Server Process Maintenance (ASPM)
function will initiate the ASPM procedures, using the ASP-Up/-Down/-Active/
-Inactive messages to convey the ASP-state to the SG - see Section 3.3.3.
If the M2UA layer subsequently receives an SCTP-Communication Down
indication from the underlying SCTP layer, it will inform the Layer
Management by invoking the M-SCTP STATUS indication primitive. The state
of the ASP will be moved to "Down" at both the SG and ASP.
At an ASP, the Layer Management may try to reestablish the SCTP association
using M-SCTP ESTABLISH request primitive.
3.3.3 ASPM procedures for peer-to-peer messages
3.3.3.1 ASP UP
The SG will mark the path as up if an explicit ASP UP (ASPUP) message is The SG will mark the path as up if an explicit ASP UP (ASPUP) message is
received and internally the path is allowed to come up (i.e., not in a received and internally the path is allowed to come up (i.e., not in a
locked local maintenance state). An ASP UP (ASPUP) message will be sent locked local maintenance state). An ASP UP (ASPUP) message will be sent
to acknowledge the received ASPUP. The SG will respond to a ASPUP with a to acknowledge the received ASPUP. The SG will respond to a ASPUP with a
ASPDN message if the path is in a locked maintenance state. ASPDN message if the path is in a locked maintenance state.
The SG will send a ASPUP message in response to a received ASPUP message The SG will send a ASPUP message in response to a received ASPUP message
from the MGC even if that path was already marked as UP at the SG. from the MGC even if that path was already marked as UP at the SG.
The paths are controlled by the MGC. The SG will only send ASPUP in The paths are controlled by the MGC. The SG will only send ASPUP in
response to the reception of a ASPUP message. response to the reception of a ASPUP message.
3.3.2.2 MGC Operation
The MGC will send ASPUP messages every 2 (add text regarding this being The MGC will send ASPUP messages every 2 (add text regarding this being
a configurable timer) seconds until the path comes up (i.e. until it a configurable timer) seconds until the path comes up (i.e. until it
receives a ASPUP message from the SG for that path). The MGC may decide receives a ASPUP message from the SG for that path). The MGC may decide
to reduce the frequency (say to every 5 seconds) if the an acknowledge- to reduce the frequency (say to every 5 seconds) if the an acknowledge-
ment is not received after a few tries. ment is not received after a few tries.
The MGC should wait for the ASPUP message from the SG before transmitting The MGC should wait for the ASPUP message from the SG before transmitting
ASP maintenance messages (ASPIA or ASPAC) or M2UA messages or it will ASP maintenance messages (ASPIA or ASPAC) or M2UA messages or it will
risk message loss. The ASPUP message received from the SG is not risk message loss. The ASPUP message received from the SG is not
acknowledged by the MGC. acknowledged by the MGC.
3.3.3 ASP Down 3.3.3.2 ASP Down
3.3.3.1 SG Operation
The SG will mark the ASP as down and send a ASPDN message to the MGC if The SG will mark the ASP as down and send a ASPDN message to the MGC if
one of the following events occur: one of the following events occur:
- a ASP Down(ASPDN) message is received from the MGC, - a ASP Down(ASPDN) message is received from the MGC,
- the ASP is locked by local maintenance. - the ASP is locked by local maintenance.
The SG will also send a ASPDN message when the ASP is already down and The SG will also send a ASPDN message when the ASP is already down and
a ASPDN) message is received from the MGC. a ASPDN) message is received from the MGC.
3.3.3.2 MGC Operation
The MGC will send ASPDN whenever it wants to take down a ASP. Since the The MGC will send ASPDN whenever it wants to take down a ASP. Since the
ASPDN messages to the SG or the ASPDN responses from the SG can be lost ASPDN messages to the SG or the ASPDN responses from the SG can be lost
(for example, during a MGC node failover), the MGC can send ASPDN messages (for example, during a MGC node failover), the MGC can send ASPDN messages
every 2 seconds until the path comes down (i.e. until it receives a ASPDN every 2 seconds until the path comes down (i.e. until it receives a ASPDN
message from the SG for that path). message from the SG for that path).
3.3.4 ASP Version Control 3.3.4 ASP Version Control
If a ASP Up message with an unknown version is received, the receiving If a ASP Up message with an unknown version is received, the receiving
end will respond with an Error message. This will indicate to the end will respond with an Error message. This will indicate to the
skipping to change at page 22, line 32 skipping to change at page 24, line 32
<----------- ASP Inactive <----------- ASP Inactive
ASP Inactive ----------> ASP Inactive ---------->
(ACK) (ACK)
(this message is optional) (this message is optional)
ASP Inactive ------------------------------> ASP Inactive ------------------------------>
<------------------------------ ASP Active <------------------------------ ASP Active
ASP Active ------------------------------> ASP Active ------------------------------>
(ACK) (ACK)
4.2 MTP Level 2 / MTP Level 3 Boundary Examples An example of message flows for establishment of associations with two
ASPs and the message flows for controlled take-over of the primary (ASP1)
by the secondary (ASP2). In this case, the SG sends new work to ASP2.
SG ASP1 ASP2
<----------- ASP Up
ASP Up ---------->
(ACK)
<------------------------------ ASP Up
ASP Up ------------------------------>
(ACK)
<----------- ASP Active
ASP Active ---------->
(ACK)
...
<------------------------------ ASP Active
(New Work)
ASP Active ------------------------------>
(ACK)
<----------- ASP Inactive
ASP Inactive ---------->
(ACK)
4.2 Case 1: SG to MGC, MTP Level 2 to MTP Level 3 Boundary Procedures
4.2.1 SS7 Link Alignment 4.2.1 SS7 Link Alignment
The MGC can request that a SS7 link be brought into alignment using the The MGC can request that a SS7 link be brought into alignment using the
normal or emergency procedure. An example of the message flow to bring normal or emergency procedure. An example of the message flow to bring
a SS7 link in-service using the normal alignment procedure is shown a SS7 link in-service using the normal alignment procedure is shown
below. below.
SG MGC SG MGC
<----------- Establish Request (ESTABLISH_START) <----------- Establish Request (ESTABLISH_NORMAL)
Establish Response ----------> Establish Response ---------->
An example of the message flow to bring a SS7 link in-service using the An example of the message flow to bring a SS7 link in-service using the
emergency alignment procedure. emergency alignment procedure.
SG MGC SG MGC
<----------- Establish Request (ESTABLISH_EMER) <----------- Establish Request (ESTABLISH_EMER)
Establish Response ----------> Establish Response ---------->
skipping to change at page 24, line 5 skipping to change at page 26, line 5
Retrieval Confirm ----------> Retrieval Confirm ---------->
Retrieval Ind -----------> Retrieval Ind ----------->
Retrieval Ind -----------> Retrieval Ind ----------->
Rtrvl Complete Ind ----------> Rtrvl Complete Ind ---------->
Note: The number of Retrieval Indication is dependent on the number of Note: The number of Retrieval Indication is dependent on the number of
messages in the retransmit queue that have been requested. Only one messages in the retransmit queue that have been requested. Only one
Retrieval Complete Indication should be sent. Retrieval Complete Indication should be sent.
4.3 Layer Management Communication Examples 4.3 Case 2: SG to IPSCP, MTP Level 2 to MTP Level 3 Boundary Procedures
4.3.1 Message Transmission
Messages are transmitted using the Data Request primitive from MTP3 to
MTP2UA.
MTP2UA MTP3
<------------- Message For Transmission (Data Request)
4.3.2 Message Reception
Messages are received using the Data Indication primitive from MTP2UA to
MTP3.
MTP2UA MTP3
------------> Received Message (Data Indication)
4.3.3 Link Status Indication
The MTP2UA layer sends Link_In_Service and Link_out_Of_Service after
receiving indication from SCTP layer.
MTP3 MTP2UA SCTP SCTP MTP2UA MTP3
<--------------
Communication Up
Link proving is done
By MTP2UA at this moment.
<---------------
Link_In_Service
<--------------
Communication Lost
<---------------
Link Out of Service
4.3.4 Link Alignment
The MTP3 layer in the IPSCP can request that a SS7 link be brought into
alignment using the normal or emergency procedure. An example of the
message flow to bring a SS7 link in-service using the normal alignment
procedure is shown below.
MTP2UA MTP3
<----------- Establish Request (ESTABLISH_NORMAL)
Establish Response ---------->
An example of the message flow to bring a SS7 link in-service using the
emergency alignment procedure.
MTP2UA MTP3
<----------- Establish Request (ESTABLISH_EMER)
Establish Response ---------->
4.3.5 Link Proving (During Emergency)
There are two alignment procedures used: normal alignment and emergency
alignment. During normal alignment, communication to other end is tested
for a period of time for making sure that the communication link does
satisfy the performance requirements of the application. The examples
are RTT and packet loss. Normal alignment is used when there are other
links associated with the affected link. The other links should be to
the same destination. Emergency alignment is used when there are no other
links to the same destination. During emergency, link is not tested for
long period of time but instead, an indication from SCTP layer is used to
bring the link in service.
MTP3 MTP2UA SCTP SCTP MTP2UA MTP3
------------->
Emergency Disable Proving
<-------------
Communication UP
-------------->
Status (validate the SCTP association meets
application requirement)
<-------------
Link_In_Service
4.3.6 Link Proving (Emergency Ceased)
One function of the adaptation layer is to make sure that the link meets
the performance requirements of the application. This is usually done
by proving the link. For example, for proving the link, we need the
adaptation layer to issue an heartbeat/RTT to its peer. This is done
before declaring link is in service to its application. For this purpose,
the existing "status" command is used. Note that how to the link meets
performance requirements is implementation dependent. Also, the proving
period can be configurable.
MTP3 MTP2UA SCTP SCTP MTP2UA MTP3
------------->
Emergency Enable Proving
ceased
<---------------
Communication UP
---------------> RTT
Status -------->
RTTs are -------->
Sent for a -------->
Period of .........
3 seconds -------->
RTT
<--------------
Link_In_Service (After checking that link is sane)
4.3.7 Congestion Notification to Upper layer
MTP3 layer expects notification of the link congestion. For example, this
is accomplished by two messages: I) Link Congested ii) Link Congestion
Ceased. Congestion is assumed if MTP2UA layer notices repeated failures
to send requests to SCTP (this is implementation dependent and it is
assumed that the SEND Failure has an error code "life time expired").
Subsequently MTP2UA can start polling status of SCTP. If all the messages
are successfully transmitted over a period of time (implementation dependent)
then it is assumed that the congestion is abated. If the congestion
condition should continue, the link will be taken out of service. In
this case, it is possible to start link change over procedure.
MTP3 MTP2UA SCTP SCTP MTP2UA MTP3
<--------------
Send Failure
<--------------
Send Failure
<--------------
Send Failure
("N" consecutive fails)
(implementation specific)
<-------------
Congestion Detected
------------->
Status
------------>
Status
------------->
polled for certain time
till the congestion ceased
(implementation specific)
<--------------
Congestion ceased
4.3.8 Link Change Over due to Congestion
Due to sustained congestion, MTP2UA can take the link out of service.
Next, MTP2UA sends an indication to MTP3 regarding link is out service
due to congestion. In this context, MTP3 can initiate a link change
over to its peer.
MTP3 MTP2UA SCTP SCTP MTP2UA MTP3
<--------------
Send Failure
<--------------
Send Failure
<--------------
Send Failure
("N" consecutive fails)
(implementation specific)
<--------------
Congestion Detected
------------>
Terminate
<------------
Terminate Successful
<------------
Communication Lost
<---------------
Link Out of Service
4.3.9 Link Release
The MTP3 can request that a SS7-IP link be taken out-of-service. It uses
the Release Request message as shown below.
MTP2UA MTP3
<------------ Release Request
Release Response ------------>
The SG can autonomously indicate that a SS7 link has gone out-of-service
as shown below.
MTP2UA MTP3
Release Indication ------------>
(Link_Out_Of_Service)
NOTE: We may be able to effective use of "State" primitives here.
For further investigation
4.3.10 Link Change Over
The objective of the change over is to ensure that signaling traffic
carried by the unavailable signaling link is diverted to the alternative
signaling link as quickly as possible while avoiding message loss,
duplication or mis-sequencing. For this purpose, the changeover
procedure includes data retrieval, which is performed before reopening
the alternative signaling links to the diverted traffic. Data retrieval
consists of identifying all those messages in the retransmission buffer
of the unavailable signaling link which have not been received by the far
end. Retrieval includes transferring the concerned messages to the
transmission buffers of the alternative links. In order to support
changeover, the SCTP TSN must be mapped to FSN/BSN of SS7.
Transmit Sequence Numbers used by SCTP (Signaling Control Transport
Protocol) are of sixteen bits. MTP2's forward and backward sequence
numbers of only seven bits. Hence it is required to map the sixteen bit
TSN to seven bit FSN/BSN. For simplicity, it is assumed that only least
seven significant seven bits of TSN are used. There can be a
configuration, where the links in the link set are of not equal bandwidth.
Further investigation is required for this scenario.
15 8 0
----------------------------------------------
0 0 0 0 0 0 0 0 0 X X X X X X X
-----------------------------------------------
<------FSN/BSN----->
In order to convert TSN to FSN and BSN, the following formula is used:
FSN, BSN = (Transmit Sequence Number - 1) MODULO 255
For data retrieval, MTP3 requests Backward Sequence Number (BSN) from
MTP2UA. This the sequence number of the last message received by the
local end. During normal period, SCTP delivers ordered messages to the
application. However, during congestion or failure condition, the sequence
numbers of the acknowledged messages can have gaps. In particular, the
SACK (selective acknowledgement message) message can have several of these
gaps. Hence, it is important to scan through these gaps and find the
sequence number before first gap. This is the number from which the remote
end has to transmit the messages. So, this is the number considered as
the Backward Sequence Number and communicated to the remote end. In a
similar way, the remote end also, detects the BSN and indicates to local
end. As soon, the MTP3 of local end receives this BSN, MTP3 retrieves all
the unacknowledged messages starting from BSN. This is accomplished
through "Retrieve FSN" message. After all the messages are sent from
MTP2UA to MTP3, a retrieval complete message is sent.
MTP3 MTP2UA SCTP SCTP MTP2UA MTP3
<-------------
Communication Lost
<--------------
Link Out of Service
--------------> Find the gaps
Retrieve BSN in the rcvd. Msgs
And locate the first gap
<---------------
Indicate BSN
---------------------------------------------------------------->
COO (BSN)
<-----------
Retrieve BSN
----------->
Indicate BSN
<-----------------------------------------------------------------
COA (BSN)
--------------------->Go through the transmit
Retrieve FSN queue and find unack. Msgs.
<--------------------- FSB Not retrievable (in case)
<--------------------- Retrieved Message
<----------------------Retrieved Message
...
<----------------------Retrieval Complete
4.4 Layer Management Communication Examples
An example of the message flows for communication between Layer Manage- An example of the message flows for communication between Layer Manage-
ment modules between SG and MGC is shown below. An active association ment modules between SG and MGC is shown below. An active association
between MGC and SG is established (section 4.1) prior to the following between MGC and SG is established (section 4.1) prior to the following
message flows. message flows.
SG MGC SG MGC
<----------- Establish Request <----------- Establish Request
Error ----------> Error ---------->
(Invalid Interface Id) (Invalid Interface Id)
5.0 Security 5.0 Security
SCN adaptation layers rely on SCTP to provide security. SCN adaptation layers rely on SCTP to provide security.
6.0 Acknowledgements 6.0 Acknowledgements
The authors would like to thank commenters for their valuable comments and The authors would like to thank Ian Rytina for his valuable comments and
suggestions. suggestions.
7.0 References 7.0 References
[1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling
System No. 7 (SS7)' System No. 7 (SS7)'
[2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) -
Message Transfer Part (MTP)' Message Transfer Part (MTP)'
[3] Bellcore GR-246-CORE 'Bell Communications Research Specification [3] Bellcore GR-246-CORE 'Bell Communications Research Specification
of Signaling System Number 7', Volume 1, December 1995 of Signaling System Number 7', Volume 1, December 1995
[4] Framework Architecture for Signaling Transport, draft-ietf-sigtran- [4] Framework Architecture for Signaling Transport, draft-ietf-sigtran-
framework-arch-03.txt, June 1999 framework-arch-03.txt, June 1999
[5] Signaling Common Transport Protocol, draft-ietf-sigtran-sctp-00.txt, [5] Simple Control Transmission Protocol, draft-ietf-sigtran-sctp-00.txt,
August 1999 August 1999
[6] Media Gateway Control Protocol (MGCP), draft-huitema-megaco-mgcp- [6] Media Gateway Control Protocol (MGCP), draft-huitema-megaco-mgcp-
v1-03.txt, August 1999 v1-03.txt, August 1999
8.0 Author's Addresses 8.0 Author's Addresses
Ken Morneault Tel: +1-703-484-3323 Ken Morneault Tel: +1-703-484-3323
Cisco Systems Inc. EMail: kmorneau@cisco.com Cisco Systems Inc. EMail: kmorneau@cisco.com
13615 Dulles Technology Drive 13615 Dulles Technology Drive
skipping to change at line 1203 skipping to change at line 1606
MCC 1J211R MCC 1J211R
445 South Street 445 South Street
Morristown, NJ 07960 Morristown, NJ 07960
USA USA
Greg Sidebottom Tel: +1-613-763-7305 Greg Sidebottom Tel: +1-613-763-7305
Nortel Networks EMail: gregside@nortelnetworks.com Nortel Networks EMail: gregside@nortelnetworks.com
3685 Richmond Rd, 3685 Richmond Rd,
Nepean, Ontario Nepean, Ontario
Canada K2H5B7 Canada K2H5B7
Ram Dantu, Ph.D. Tel: +1-972-477-8446
Alcatel USA EMail: ram.dantu@usa.alcatel.com
1000 Coit Road
Plano, Tx. 74075
This Internet Draft expires April 2000. This Internet Draft expires April 2000.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/