| draft-ietf-sigtran-m2ua-02Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-ietf-sigtran-m2ua-02.txt. Network Working Group Ken Morneault INTERNET-DRAFT Cisco Systems Mallesh Kalla Telcordia Greg Sidebottom Nortel Networks Ram Dantu Tom George Alcatel Expires in six months December 1999 SS7 MTP2-User Adaptation Layer <draft-ietf-sigtran-m2ua-02.txt> Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as 'work in progress.' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To learn the current status of any Internet-Draft, please check the '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This Internet Draft defines a protocol for backhauling of SS7 MTP2 User signaling messages over IP using the Simple Control Transmission Protocol (SCTP). One application of this protocol would be to use it between a Signaling Gateway (SG) and Media Gateway Controller (MGC). In this case, the Signaling Gateway would be acting as a Signaling Link Terminal. Another application of this protocol would be to use it between a SG and a SCP. In either application, it is assumed that the SG receives SS7 signaling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. Morneault, Kalla & Sidebottom [Page 1] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 TABLE OF CONTENTS 1. Introduction..............................................2 1.1 Scope..................................................2 1.2 Terminology............................................3 1.3 Signaling Transport Architecture.......................3 1.4 Services Provide by the M2UA Adaptation Layer..........4 1.5 Function Provided by the M2UA Layer....................6 1.6 Definition of the M2UA Boundaries......................7 2. Protocol Elements.........................................8 2.1 Common Message Header..................................8 2.2 M2UA Message Header....................................9 2.3 M2UA Messages.........................................10 3. Procedures...............................................17 3.1 Procedures to Support Service in Section 1.4.1........17 3.2 Procedures to Support Service in Section 1.4.2........17 3.3 Procedures to Support Service in Section 1.4.3........17 4. Examples of MTP2 User Adaptation (M2UA) Procedures.......22 4.1 Establishment of associations between SG and MGC......22 examples 4.2 MTP Level 2 / MTP Level 3 Boundary Examples...........23 4.3 Layer Management Communication Examples................25 5. Security.................................................31 6. Acknowledgements.........................................31 7. References...............................................31 8. Author's Addresses.......................................32 1. Introduction 1.1 Scope There is a need for SCN signaling protocol delivery from an Signaling Gateway (SG) to a Media Gateway Controller (MGC) or IP Signaling Point (IPSP). The delivery mechanism should meet the following criteria: * Support for MTP Level 2 / MTP Level 3 interface boundary * Support for communication between Layer Management modules on SG and MGC * Support for management of active associations between the SG and MGC In other words, the Signaling Gateway will transport MTP Level 3 messages to a Media Gateway Controller (MGC) or IP Signaling Point (IPSP). In the case of delivery from an SG to an IPSP, the SG and IPSP function as traditional SS7 nodes using the IP network as a new type of SS7 link. This allows for full MTP Level 3 message handling and network management capabilities. Morneault, Kalla & Sidebottom [Page 2] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 1.2 Terminology MTP2-User - A protocol that normally uses the services of MTP Level 2 (i.e. MTP3). Interface - For the purposes of this document, an interface is a SS7 signaling link. Association - An association refers to a SCTP association. The association will provide the transport for the delivery of protocol data units for one or more interfaces. Stream - A stream refers to a SCTP stream. Backhaul - Refers to the transport of signaling from the point of interface for the associated data stream (i.e., SG function in the MGU) back to the point of call processing (i.e., the MGCU), if this is not local [4]. Application Server (AS) - A logical entity serving a specific application instance. An example of an Application Server is a MGC handling the MTP Level 3 and call processing for SS7 links terminated by the Signaling Gateways. Practically speaking, an AS is modeled at the SG as an ordered list of one or more related Application Server Processes (e.g., primary, secondary, tertiary, �). Application Server Process (ASP) - A process instance of an Application Server. Examples of Application Server Processes are primary or backup MGC instances. Application Server Process Path (ASP Path or just Path) - A Path to a remote Application Server Process instance. A Path maps 1:1 to an SCTP association. Fail-over - The capability to re-route signaling traffic as required to a next-preferred Application Server Process within an Application Server in the event of failure or unavailability of the currently used Application Server Process (e.g., from primary MGC to back-up MGC). Fail-over may also apply upon the return to service of a previously unavailable Application Server Process. Signaling Link Terminal (SLT) - Refers to the means of performing all of the functions defined at MTP level 2 regardless of their implementation [2]. Morneault, Kalla & Sidebottom [Page 3] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 1.3 Signaling Transport Architecture The architecture that has been defined [4] for SCN signaling transport over IP uses multiple components, including an IP transport protocol, a signaling common transport protocol (SCTP) and an adaptation module to support the functions expected by a particular SCN signaling protocol from its underlying protocol layer. In reference to the SIGTRAN framework architecture [4], this document defines a SCN adaptation module that is suitable for the transport of SS7 MTP2 User. The only SS7 MTP2 User is MTP3. 1.3.1 Case 1: SG to MGC In a Signaling Gateway, it is expected that the SS7 signaling is received over a standard SS7 network termination, using the SS7 Message Transfer Part (MTP) to provide transport of SS7 signaling messages to and from an SS7 Signaling End Point (SEP) or SS7 Signaling Transfer Point (STP). In other words, the SG acts as a Signaling Link Terminal (SLT) [2]. The SG then provides interworking of transport functions with IP Signaling Transport, in order to transport the MTP3 signaling messages to the MGC where the peer MTP3 protocol layer exists, as shown below: ****** SS7 ****** IP ******* *SEP *-----------* SG *-------------* MGC * ****** ****** ******* +----+ |S7UP| +----+ +----+ |MTP | |S7UP| |L3 | +----+ +----+----+ +----+ |MTP | |MTP |M2UA| |M2UA| |L3 | | +----+ +----+ |L2 | |L2 |SCTP| |SCTP| |L1 | |L1 +----+ +----+ | | | |UDP | |UDP | +----+ +---------+ +----+ SEP - SS7 Signaling Endpoint UDP - User Datagram Protocol SCTP - Simple Control Transmission Protocol (Refer to Reference [5]) Figure 1: M2UA in the SG to MGC Application Note: STPs may be present in the SS7 path between the SEP and the SG. Morneault, Kalla & Sidebottom [Page 4] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 1.3.2 Case 2: SG to IPSP The following figure shows the seamless interworking at the MTP3 layer. MTP3 is adapted to the SCTP layer using MTP2 User Adaptation Layer (M2UA). In this example, the Signaling Gateway could be an STP. All the primitives between MTP3 and MTP2 are supported by M2UA. Any of the nodes in the diagram could have SCCP or other SS7 user parts. ****** SS7 ****** IP ************ *SEP *-------* SG *-------------* IPSP * ****** ****** ************ +----+ +---------+ |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 IPSP - IP Signaling Point UDP - User Datagram Protocol SCTP - Simple Control Transmission Protocol (Refer to Reference [5]) Figure 2: M2UA in the SG to IPSP Application In this case, the SCTP association acts as an SS7 link between the SG and the IPSP. The association contains two streams, one in each direction. The IPSP may or may not have a termination to the SS7 network. 1.3.3 UDP port A request will be made to IANA to assign a UDP port for M2UA. 1.4 Services Provided by the M2UA Adaptation Layer The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination point in the IP network, so that the M2UA protocol layer is required to provide the equivalent set of services to its users as provided by the MTP Level 2 to MTP Level 3. Morneault, Kalla & Sidebottom [Page 5] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 This includes the following services: 1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary Also provision is made for protocol elements that enable a seamless, or as seamless as possible, operation of the MTP2-User peers in the SS7 and IP domains. This includes Data Provides the ability to transport MTP2 User information (in this case, MTP Level 3 PDUs). Link Establish Provides the ability to request MTP Level 2 to bring SS7 links in-service. Link Release Provides the ability to request MTP Level 2 to take SS7 links out-of- service. Also, provides mechanism for MTP2 to autonomously indicate that SS7 link(s) have gone out-of-service. Link State Provides the ability to request state change or information on a per link basis. Some examples would be the forcing of Local Processor Outage or flushing buffers. Link Status Provides a means for asychronous notification of link state changes to be reported to the upper layer (MTP Level 3). An examples would be the reporting of remote processor outage event. Data Retrieval Provides a mechanism to perform SS7 link changeover procedure in the case of a SS7 link failure. 1.4.2 Support for communication between Layer Management modules on SG and MGC It is envisioned that the M2UA layer needs to provide some messages that will facilitate communication between Layer Management modules on the SG and MGC. To facilitate reporting of errors that arise because of backhauling MTP Level 3 scenario, the following primitive is defined: Morneault, Kalla & Sidebottom [Page 6] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 M-ERROR The M-ERROR message is used to indicate an error with a received M2UA message (e.g., interface identifier value is not known to the SG). 1.4.3 Support for management of active associations between SG and MGC The M2UA layer on the SG keeps the state of various ASPs it is associated with. A set of primitives between M2UA layer and the Layer Management are defined below to help the Layer Management manage the association(s) between the SG and the MGC. M-SCTP ESTABLISH The M-SCTP ESTABLISH primitive is used to request, indicate and confirm the establishment of SCTP association to a peer M2UA node. The M2UA layer may also need to inform the status of the SCTP association(s) to the Layer Management. This can be achieved using the following primitive. M-SCTP STATUS The M-SCTP STATUS primitive is used to request and indicate the status of underlying SCTP association(s). The Layer Management may need to inform the M2UA layer of a user status (i.e., failure, active, etc.), so that messages can be exchanged between M2UA layer peers to stop traffic to the local M2UA user. This can be achieved using the following primitive. M-ASP STATUS The M-ASP STATUS primitive is used by the Layer Management to indicate the status of the local M2UA user to the M2UA layer. 1.5 Functions Provided by the M2UA Layer 1.5.1 Mapping The M2UA layer must maintain a map of a Interface ID to a physical interface on the Signaling Gateway. A physical interface would be a V.35 line, T1 line/timeslot, E1 line/timeslot, etc. The M2UA layer must also maintain a map of Interface ID to SCTP association and to a stream within the association. Morneault, Kalla & Sidebottom [Page 7] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 1.5.2 Status of ASPs The M2UA layer on the Signaling Gateway must maintain the state of one or more Application Server Process(es) it is associated with. The state of an ASP changes because of reception of peer-to-peer messages or reception of indications from the local SCTP association. ASP state transition procedures are described in Section Section 3.3. 1.5.3 Flow Control / Congestion It is possible for the M2UA layer to be informed of IP network congestion by means of an implementation-dependent function (i.e. an indication from the SCTP). If the M2UA layer receives this indication, the action(s) taken are implementation dependent. 1.5.4 SCTP Stream Management SCTP allows user specified number of streams to be opened during the initialization. It is the responsibility of the M2UA layer to ensure proper management of these streams. SCTP streams provide a means for avoiding head of line blocking. For that reason, a stream will be used per SS7 signaling link terminated by the Signaling Gateway. The SS7 signaling link can be identified by the optional Interface Identifier in the M2UA specific message header (refer to Section 2.2). 1.5.5 Seamless SS7 Network Management Interworking If the SG loses the SCTP association to the MGC, it should follow MTP 2 processor outage procedures [2]. 1.5.6 Management Inhibit/Uninhibit Local Management may wish to stop traffic across an SCTP association in order to temporarily remove the association from service or to perform testing and maintenance activity. The function could optionally be used to manage the start of traffic on to a newly-available SCTP association. 1.6 Definition of the M2UA Boundaries 1.6.1 Definition of the M2UA / MTP Level 3 boundary DATA ESTABLISH RELEASE STATE STATUS RETRIEVAL DATA RETRIEVAL DATA RETRIEVAL COMPLETE Morneault, Kalla & Sidebottom [Page 8] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 1.6.2 Definition of the M2UA / MTP Level 2 boundary DATA ESTABLISH RELEASE STATE STATUS RETRIEVAL DATA RETRIEVAL DATA RETRIEVAL COMPLETE 1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP The upper layer and layer management primitives provided by SCTP are provided in Reference [6] Section 9. 1.6.4 Definition of Layer Management / M2UA Boundary M-ERROR M-SCTP ESTABLISH M-SCTP STATUS M-ASP STATUS 2.0 Protocol Elements This section describes the format of various messages used in this protocol. 2.1 Common Message Header The protocol messages for MTP2 User Adaptation require a message header structure which contains a version, message type and message length. This message header is common among all SCN adaptation layers. 0 7 8 15 16 31 +---------------+---------------+ | Vers | Spare | Msg Type | +---------------+---------------+ | Message Length | +-------------------------------+ Figure 2 Common Message Header 2.1.1 Version The version field (vers) contains the version of the M2UA adapation layer. The supported versions are: 01 Release 1.0 of M2UA adaptation protocol Morneault, Kalla & Sidebottom [Page 9] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 2.1.2 Message Type The valid message types are defined in Section 2.2.2 and the message contents are described in Section 2.3. Each message can contain parameters. The following list contains the message types for the defined messages. MTP2 User Adaptatation (MAUP) Messages Data Request 0601 Data Indication 0602 Establish Request 0603 Establish Confirm 0604 Release Request 0605 Release Confirm 0606 Release Indication 0607 State Request 0608 State Confirm 0609 State Indication 060a Data Retrieval Request 060b Data Retrieval Confirm 060c Data Retrieval Indication 060d Data Retrieval Complete Indication 060e Application Server Process Maintenance (ASPM) Messages ASP Up (ASPUP) 0301 ASP Down (ASPDN) 0302 ASP Active (ASPAC) 0401 ASP Inactive (ASPIA) 0402 Management (MGMT) Messages Error 0001 2.1.3 Message Length The Message length defines the length of the message in octets, not including the header. 2.2 M2UA Message Header In addition to the common message header, there will be a M2UA specific message header. The M2UA specific message header will immediately follow the common message header, but will only be used with MAUP and MGMT messages. This message header will contain the Interface Identifier. The Interface Identifier identifies the physical interface at the SG for which the signaling messages are sent/received. Or, the Interface Identifier Morneault, Kalla & Sidebottom [Page 10] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 can be left empty (a null string of length zero). The Interface Identifier follows the same endpoint naming scheme provided in MGCP [7]. For example, if a Signaling Gateway terminates a E1 and the SS7 signaling link is one timeslot 16, the interface identifier could be the following: e1/[email protected] The use of wildcards is not acceptable. Ed's Note: The Interface Identifier string should be padded to 32-bit boundaries. The length field indicates the end of the string. 0 15 16 31 +---------------+---------------+ | Tag (0x1) | Length | +-------------------------------+ | Interface Identifier | +-------------------------------+ Figure 3 M2UA Message Header The Tag value for Interface Identifier is 0x1. The length provides the length of the Interface Identifier string in bytes. 2.3 M2UA Messages The following section defines the messages and parameter contents. The M2UA messages will use the command header and the M2UA specific header. 2.3.1 MTP2 User Adaptation Messages 2.3.1.1 Data (Request, Indication) The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The Data message contains the protocol data. The format for the Data Message parameters is as follows: 0 15 16 31 +-------------------------------+ ... | Protocol Data | ... +---------------+---------------+ The Protocol Data field contains the MTP2-User application message. Morneault, Kalla & Sidebottom [Page 11] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 2.3.1.2 Establish (Request, Confirmation) The Establish Request message is used to establish the channel or to indicate that the channel has been established. Note that the gateway may already have the channel established at its layer. If so, upon receipt of an Establish Request, the gateway takes no action except to send an Establish Confirm. 0 15 16 31 +---------------+---------------+ | State | +---------------+---------------+ The valid values for State are shown in the following table. Define Value Description ESTABLISH_NORMAL 0x0 Follow normal procedure for establishing a SS7 link ESTABLISH_EMERGENCY 0x1 Follow emergency procedure for establishing a SS7 link 2.3.1.3 Release (Request, Indication, Confirmation) This Release Request message is used to release the channel. The Release Confirm and Indication messages are used to indicate that the channel has been released. 0 15 16 31 +---------------+---------------+ | Reason | +---------------+---------------+ The valid values for Reason are shown in the following table. Define Value Description RELEASE_MGMT 0x0 Management layer generated release. RELEASE_PHYS 0x1 Physical layer alarm generated release. RELEASE_SIOS 0x2 Receipt of SIOS RELEASE_OTHER 0x3 Other reason SS7 link out-of-service (should we keep it simple, or provide list of reasons that would enable debugging) 2.3.1.4 State (Request, Confirm) The State Request message can be sent from a MGC to cause an action on a particular SS7 link supported by the Signaling Gateway. The gateway sends a State Confirm to the MGC if the action has been success- fully completed. The State Confirm reflects that state value received in the State Request message. Morneault, Kalla & Sidebottom [Page 12] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 0 15 16 31 +---------------+---------------+ | State | +---------------+---------------+ The valid values for State are shown in the following table. Define Value Description STATUS_LOC_PROC_SET 0x0 Request local processor outage. STATUS_LOC_PROC_CLEAR 0x1 Request local processor outage recovered. STATUS_EMER_SET 0x2 Request emergency alignment procedure. STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel emergency) procedure. STATUS_FLUSH_BUFFERS 0x4 Flush transmit and retransmit buffers. STATUS_CONTINUE 0x5 Continue. 2.3.1.5 State Indication The MTP2 State Indication message can be sent from a gateway to a call agent to indicate a condition on a channel. 0 15 16 31 +---------------+---------------+ | State | +---------------+---------------+ The valid values for State are shown in the following table. Define Value Description EVENT_ENTER_LPO 0x0 Entered local processor outage. EVENT_EXIT_LPO 0x1 Exited local processor outage. EVENT_ENTER_CONG 0x2 Entered a congested state. EVENT_EXIT_CONG 0x3 Exited a congested state. EVENT_PHYS_UP 0x4 Physical interface up. EVENT_PHYS_DOWN 0x5 Physical interface down. EVENT_PROTOCOL_ERR 0x6 Protocol error occurred. EVENT_REM_ENTER_CONG 0xc Remote entered congestion. EVENT_REM_EXIT_CONG 0xd Remote exited congestion. EVENT_REM_ENTER_PO 0xe Remote entered processor outage. EVENT_REM_EXIT_PO 0xf Remote exited processor outage. 2.3.1.6 Retrieval (Request, Confirm) The MTP2 Retrieval Request message is used during the MTP Level 3 changeover procedure to request the BSN, to retrieve PDUs from the retransmit queue or to flush PDUs from the retransmit queue. Morneault, Kalla & Sidebottom [Page 13] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 0 15 16 31 +---------------+---------------+ | Action | +---------------+---------------+ | fsn_bsn | +---------------+---------------+ The valid values for Action are shown in the following table. Define Value Description ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number. ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the retransmit queue. ACTION_DROP_MSGS 0x3 Drop the PDUs in the retransmit queue. In the Retrieval Request message, the fsn_bsn field contains the FSN of the far end if the action is ACTION_RTRV_MSGS. When the Signaling Gateway sends a Retrieval Confirm to this request, it echos the action and puts the BSN in the fsn_bsn field if the action was ACTION_RTRV_BSN. 2.3.1.7 Retrieval Indication The Retrieval Indication message is sent by the Signaling Gateway with a PDU from the retransmit queue. The Retrieval Indication message does not contain the Action or fsn_bsn fields, just a PDU from the retransmit queue. 0 15 16 31 +---------------+---------------+ | | . PDU from retransmit . . queue . | | +---------------+---------------+ 2.3.1.8 Retrieval Complete Indication The MTP2 Retrieval Complete Indication message is exactly the same as the MTP2 Retrieval Indication message except that it also indicates that it contains the last PDU from the retransmit queue. 2.3.2 Application Server Process Maintenance (ASPM) Messages The ASPM messages will only use the common header. Morneault, Kalla & Sidebottom [Page 14] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 2.3.2.1 ASP UP (ASPUP) The ASPUP message is used to indicate to a remote M2UA peer that the layer is ready to receive traffic or maintenance messages. The ASPUP message contains the following parameters: Adaptation Layer Identifer (optional) SCN Protocol Identifier (optional) The Adaptation Layer Identifier is a string that identifies the adaptation layer. This string must be set to "M2UA" which means the length will be 4. The Protocol Identifier field contains the identity of the specific SCN signaling protocol being transported. The Protocol ID defines the protocol type, variant, and version, and thereby specifies the components and encoding of the PROTOCOL DATA field. The Protocol Identifier also defines what SCN protocol message components are included in the PROTOCOL DATA. (Ed. Note: Need encoding of mime-type value or OID or fixed string/integer that will be administered outside of this document (IANA). Also, perhaps bring in text from Christian's mime document - See "draft-ietf-sigtran-mime-isup.txt" for an example of an application/ISUP media type defined according to the rules defined in RFC 2048.?) The format for the ASPUP message is as follows: 0 15 16 31 +---------------+---------------+ | Tag (0x2) | Length | +---------------+---------------+ | Adaptation Layer Identifier | +---------------+---------------+ | Tag (0x3) | Length | +---------------+---------------+ | Protocol Identifier | +---------------+---------------+ | Tag (0x4) | Length | +---------------+---------------+ | INFO String | +---------------+---------------+ Note: Strings are padded to 32-bit boundaries. The length field indicates the end of the string. Morneault, Kalla & Sidebottom [Page 15] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 2.3.2.2 ASP Down (ASPDN) The ASPDN message is used to indicate to a remote M2UA peer that the layer is not ready to receive traffic or maintenance messages. The ASPDN message contains the following parameters: INFO String The format for the ASPDN message is as follows: 0 15 16 31 +---------------+---------------+ | Tag (0x4) | Length | +---------------+---------------+ | INFO String | +---------------+---------------+ ##### We discussed adding a reason code. Reason could be failure or management inhibit. ##### 2.3.2.3 ASP Active (ASPAC) The ASPAC message is sent by an ASP to indicate to an SG that it is the active ASP to be used from within a list of primary and back-up ASPs for a particular signaling mapping relationship. The ASPAC message contains the following parameters: Controlled/Forced flag (C/F flag) INFO String The format for the ASPAC message is as follows: 0 15 16 31 +---------------+---------------+ | C/F flag | +---------------+---------------+ | Tag (0x4) | Length | +---------------+---------------+ | INFO String | +---------------+---------------+ Morneault, Kalla & Sidebottom [Page 16] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 The valid values for C/F flag are shown in the following table. Define Value Description FORCED 0x0 Force sending of all messages to ASP CONTROLLED 0x1 Only send "new work" to ASP 2.3.2.4 ASP Inactive (ASPIA) The ASPIA message is sent by an ASP to indicate to an SG that it is no longer the the active ASP to be used from within a list of primary and back-up ASP for a particular signaling mapping relationship. The SG will respond with an ASPIA message and either buffer or discard incoming messages for a timed period and then discard. The ASPIA message contains the following parameters: INFO String The format for the ASPIA message is as follows: 0 15 16 31 +---------------+---------------+ | Tag (0x4) | Length | +---------------+---------------+ | INFO String | +---------------+---------------+ 2.3.3 Layer Management (MGMT) Messages 2.3.3.1 Error (ERR) The ERR message is sent when an invalid value is found in an incoming messages. The ERR message contains the following parameters: Error Code The format for the ERR message is as follows: 0 7 8 15 16 31 +---------------+---------------+ | Error Code | +---------------+---------------+ Morneault, Kalla & Sidebottom [Page 17] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 The Error Code can be one of the following values: Invalid Version 0x1 Invalid Interface Identifier 0x2 Invalid SCN Version 0x3 Invalid Adaptation Layer Identifier 0x4 Invalid Stream Identifier 0x5 Invalid Message Type 0x6 3.0 Procedures The M2UA layers needs to respond to various primitives it receives from other layers as well as messages it receives from the peer-to-peer messages. This section describes various procedures involved in response to these events. 3.1 Procedures to Support Service in Section 1.4.1 These procedures achieve the M2UA layer's "Transport of MTP Level 2 / MTP Level 3 boundary" service. 3.1.1 MTP Level 2 / MTP Level 3 Boundary Procedures On receiving a primitives from the local layer, the M2UA layer will send the corresponding MAUP message (see Section 2) to its peer. The M2UA layer must fill in various fields of the common and specific headers correctly. In addition the message needs to be sent on the SCTP stream that corresponds to the SS7 link. 3.1.2 MAUP Message Procedures On receiving MAUP messages from a peer M2UA layer, the M2UA layer on an SG or MGC needs to invoke the corresponding layer primitives to the local MTP Level 2 or MTP Level 3 layer. 3.2 Procedures to Support Service in Section 1.4.2 These procedures achieve the IUA layer's "Support for Communication between Layer Managements" service. 3.2.1 Layer Management Primitives Procedure On receiving these primitives from the local layer, the M2UA layer will send the corresponding MGMT message (Error) to its peer. The M2UA layer must fill in the various fields of the common and specific headers correctly. 3.2.2 MGMT message procedures Upon receipt of MGMT messages the M2UA layer must invoke the corresponding Layer Management primitives (M-ERROR) to the local layer management. 3.3 Procedures to Support Service in Section 1.4.3 These procedures achieve the M2UA layer's "Support for management of active associations between SG and MGC" service. Morneault, Kalla & Sidebottom [Page 18] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 3.3.1 State Maintenance 3.3.1.1 ASP States The state of the each ASP is maintained in the M2UA layer on the SG. The state of an ASP changes due to events. The events include: * Reception messages from peer M2UA layer * Reception of indications from layers below The ASP state transition diagram is shown in Figure 4. The possible states of an ASP are: ASP-DOWN: Application Server Process is unavailable. Initially all ASPs are in this state. ASP-UP: Application Server Process is available but application traffic is stopped. ASP-ACTIVE: Application Server Process is available and application traffic is active. At most one ASP per AS can be in the active state. Figure 4: ASP State Transition Diagram +-------------+ |-------->| | | | ASP-ACTIVE | | | | | | | | +-------------+ | ^ | | ASP | | ASP | Active | | Inactive | | v | +-------------+ | | | ASP Down / | | | SCTP CDI | | ASP-UP | | | | | | | | +-------------+ | ^ | | ASP | | ASP Down / | Up | | SCTP CDI | | v | +-------------+ | | | |-------->| | | ASP-DOWN | | | | | +-------------+ Morneault, Kalla & Sidebottom [Page 19] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 SCTP CDI: Local SCTP layer's Communication Down Indication to the Upper Layer Protocol (M2UA) on an SG. SCTP will send this indication when it detects the loss of connectivity to ASP's SCTP layer. 3.3.1.2 AS States The state of the AS is maintained in the ITUN layer on the SG. The state of an AS changes due to events. These events include: * ASP state transitions * Recovery timer triggers The possible states of an AS are: AS-DOWN: Application Server is unavailable. This state implies that all ASPs are in the ASP-DOWN state for this AS. AS-UP: One or more ASPs are in the ASP-UP state. AS-ACTIVE: Application Server is available and application traffic is active. This state implies that one ASP is in the ASP-ACTIVE state. AS-PENDING: Currently Active ASP became inactive or SCTP association with it is lost. A Recovery timer will be started and in coming SCN messages will be queuedby the SG. If an ASP becomes Active before the recovery timer (Tr) expires, the AS will move to AS-ACTIVE state and all the queued messages will be sent to the active ASP. If the recovery timer expires before an ASP becomes active, SG stops queuing messages and discards all queued messages. AS will move to AS-UP if at least one ASP is in ASP-UP state, otherwise it will move to AS-DOWN state. If Tr expires before an ASP becomes active, the SG stops queuing messages and discards all previously queued messages. The AS will move to AS-UP if at least one ASP is in ASP-UP state, otherwise it will move to AS-DOWN state. Ed's 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. Morneault, Kalla & Sidebottom [Page 20] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 +----------+ one ASP trans ACTIVE +-------------+ | |------------------------>| | | AS-UP | | AS-ACTIVE | | | | | | |< -| | +----------+ \ / +-------------+ ^ | \ Tr Trigger / ^ | | | \ at least one / | | | | \ ASP in UP / | | | | \ / | | | | \ / | | | | \ /---/ | | one ASP | | \ / one ASP | | ACTIVE ASP trans | | all ASP \-/----\ trans | | trans to UP or to UP | | trans to / \ ACTIVE | | ACTIVE ASP | | DOWN / \ | | SCTP CDI | | / \ | | | | / \ | | | | /all ASP \ | | | v / trans to \ | v +----------+ / DOWN \ +-------------+ | |<--/ -| | | AS-DOWN | | AS-PENDING | | | | (queueing) | | |<------------------------| | +----------+ Tr Trigger no ASP +-------------+ in UP state or prev ACTIVE ASP trans to DOWN state Tr = Recovery Timer Figure 5: AS State Transition Diagram 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. Morneault, Kalla & Sidebottom [Page 21] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 Once the SCTP association is established, The M2UA layer at an ASP will then find out the state of its local M2UA-user from the Layer Management using the primitive M-ASP STATUS. Based on the status of the local M2UA-User, the local ASP ITUN Application Server Process Maintenance (ASPM) function will initiate the ASPM procedures, using the ASP-Up/-Down/-Active/ -Inactive messages to convey the ASP-state to the SG - see Section 3.3.3. If the M2UA layer subsequently receives an SCTP-Communication Down indication from the underlying SCTP layer, it will inform the Layer Management by invoking the M-SCTP STATUS indication primitive. The state of the ASP will be moved to "Down" at both the SG and ASP. At an ASP, the Layer Management may try to reestablish the SCTP association using M-SCTP ESTABLISH request primitive. 3.3.3 ASPM procedures for peer-to-peer messages 3.3.3.1 ASP UP The SG will mark the path as up if an explicit ASP UP (ASPUP) message is received and internally the path is allowed to come up (i.e., not in a locked local maintenance state). An ASP UP (ASPUP) message will be sent to acknowledge the received ASPUP. The SG will respond to a ASPUP with a ASPDN message if the path is in a locked maintenance state. The SG will send a ASPUP message in response to a received ASPUP message from the MGC even if that path was already marked as UP at the SG. The paths are controlled by the MGC. The SG will only send ASPUP in response to the reception of a ASPUP message. The MGC will send ASPUP messages every 2 (add text regarding this being a configurable timer) seconds until the path comes up (i.e. until it receives a ASPUP message from the SG for that path). The MGC may decide to reduce the frequency (say to every 5 seconds) if the an acknowledge- ment is not received after a few tries. The MGC should wait for the ASPUP message from the SG before transmitting ASP maintenance messages (ASPIA or ASPAC) or M2UA messages or it will risk message loss. The ASPUP message received from the SG is not acknowledged by the MGC. 3.3.3.2 ASP Down The SG will mark the ASP as down and send a ASPDN message to the MGC if one of the following events occur: Morneault, Kalla & Sidebottom [Page 22] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 - a ASP Down(ASPDN) message is received from the MGC, - the ASP is locked by local maintenance. The SG will also send a ASPDN message when the ASP is already down and a ASPDN) message is received from the MGC. The MGC will send ASPDN whenever it wants to take down a ASP. Since the ASPDN messages to the SG or the ASPDN responses from the SG can be lost (for example, during a MGC node failover), the MGC can send ASPDN messages every 2 seconds until the path comes down (i.e. until it receives a ASPDN message from the SG for that path). 3.3.4 ASP Version Control If a ASP Up message with an unknown version is received, the receiving end will respond with an Error message. This will indicate to the sender which version the receiving node supports. This is useful when protocol version upgrades are being performed. A node with the newer version should support the older versions used on other nodes it is communicating with. The version field in the Error message header associated with the will indicate the version supported by the node. 3.3.5 ASP Inactive When a ASPIA message is received, message transmission to that ASP ceases. The SG will either discard all incoming messages or start buffering the incoming messages for N seconds after which messages will be discarded. If the ASP is down, all of the Paths that were supported by that ASP are, by default, down. 3.3.6 ASP Active When a ASP Active (ASPAC) message is received, the SG will start routing to that ASP. Reception of a ASPAC message overrides any previous ASPAC messages and results in the ASP associated with the ASPAC message to become the newly active ASP. 4.0 Examples of MTP2 User Adaptation (M2UA) Procedures 4.1 Establishment of associations between SG and MGC examples An example of the message flows for establishing active associations between SG and MGC is shown below. SG ASP1 <----------- ASP Up ASP Up ----------> (ACK) <----------- ASP Active ASP Active ----------> (ACK) Morneault, Kalla & Sidebottom [Page 23] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 An example of message flows for establishment of associations with two ASPs and the message flows for take-over of the primary (ASP1) by the secondary (ASP2). SG ASP1 ASP2 <----------- ASP Up ASP Up ----------> (ACK) <------------------------------ ASP Up ASP Up ------------------------------> (ACK) <----------- ASP Active ASP Active ----------> (ACK) ... <----------- ASP Inactive ASP Inactive ----------> (ACK) (this message is optional) ASP Inactive ------------------------------> <------------------------------ ASP Active ASP Active ------------------------------> (ACK) An example of message flows for establishment of associations with two ASPs and the message flows for controlled take-over of the primary (ASP1) by the secondary (ASP2). In this case, the SG sends new work to ASP2. SG ASP1 ASP2 <----------- ASP Up ASP Up ----------> (ACK) <------------------------------ ASP Up ASP Up ------------------------------> (ACK) <----------- ASP Active ASP Active ----------> (ACK) ... <------------------------------ ASP Active (New Work) ASP Active ------------------------------> (ACK) <----------- ASP Inactive ASP Inactive ----------> (ACK) 4.2 Case 1: SG to MGC, MTP Level 2 to MTP Level 3 Boundary Procedures 4.2.1 SS7 Link Alignment The MGC can request that a SS7 link be brought into alignment using the normal or emergency procedure. An example of the message flow to bring a SS7 link in-service using the normal alignment procedure is shown below. SG MGC <----------- Establish Request (ESTABLISH_NORMAL) Establish Response ----------> An example of the message flow to bring a SS7 link in-service using the emergency alignment procedure. SG MGC <----------- Establish Request (ESTABLISH_EMER) Establish Response ----------> Morneault, Kalla & Sidebottom [Page 24] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 4.2.2 SS7 Link Release The MGC can request that a SS7 link be taken out-of-service. It uses the Release Request message as shown below. SG MGC <------------ Release Request (RELEASE_MGMT) Release Response ------------> The SG can autonomously indicate that a SS7 link has gone out-of-service as shown below. SG MGC Release Indication ------------> (RELEASE_PHYS) 4.2.3 Set and Clear Local Processor Outage to be added 4.2.4 Notification of Processor Outage (local or remote) to be added 4.2.5 Flush Buffers or Continue to be added 4.2.6 SS7 Link Changeover An example of the message flow for a changeover is shown below. SG MGC <---------- Retrieval Request (MTP2_RTRV_BSN) Retrieval Confirm ----------> (with BSN) <---------- Retrieval Request (MTP2_RTRV_MSGS with FSN) Retrieval Confirm ----------> Retrieval Ind -----------> Retrieval Ind -----------> Rtrvl Complete Ind ----------> Note: The number of Retrieval Indication is dependent on the number of messages in the retransmit queue that have been requested. Only one Retrieval Complete Indication should be sent. Morneault, Kalla & Sidebottom [Page 25] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 4.3 Case 2: SG to IPSP, MTP Level 2 to MTP Level 3 Boundary Procedures In general, messages passed between MTP3 and M2UA are the same as those passed between MTP3 and MTP2. M2UA interprets messages from MTP3 and sends the appropriate message to SCTP. Likewise, messages from SCTP are used to generate a meaningful message to MTP3. 4.3.1 Link Initialization (Alignment) The MTP3 layer can request that an SS7 link be brought into alignment using the normal or emergency procedure. An example of the message flow to bring an SS7 link in-service is shown below. There are two alignment procedures normal alignment and emergency alignment. During normal alignment, communication to the other end is tested for a period of time to make sure that the communication link satisfies the performance requirements of the application. The examples are RTT and packet loss. Normal alignment is used when there are other links available to the same destination. Emergency alignment is used when there are no other links to the same destination. During emergency, the link is not tested for a long period of time. Instead, an indication from the SCTP layer is used to bring the link in service. The procedure for beginning an Association is described in the SCTP standard [5]. MTP3 M2UA SCTP SCTP M2UA MTP3 ---- ---- ---- ---- ---- ---- Power On ------------> Out of Service <------------ Emergency OR Emergency Ceases ------------> Start ------------> Associate ------------> (SCTP Association procedure) Communication Up Communication Up <------------ ------------> Indication Indication (Link In Service) (Link In Service) <------------ ------------> For the Emergency Ceases case, proving begins at this time. See the section on Link Proving below. 4.3.2 Link Proving 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 how the link meets performance requirements is implementation dependent. Also, the proving period can be configurable. Proving is done by both ends of the link. To simplify the diagram, proving is shown on one end only. In the following diagram the Link has just completed the alignment procedure. The Status primitive is sent to determine if the Heartbeats were delivered successfully within the desired time period. MTP3 M2UA SCTP SCTP M2UA MTP3 ---- ---- ---- ---- ---- ---- Request Heartbeat ------------> (Heartbeat sent and acknowledged) Request Heartbeat ------------> (Heartbeat sent and acknowledged) Request Heartbeat ------------> (Heartbeat sent and acknowledged) Heartbeats are sent for M seconds (Note A). Status ------------> Indication (Link In Service) (After checking that link is sane) <------------ Note A M is implementation-dependent. 4.3.3 Message Transmission and Reception Messages are transmitted using the Data Request primitive from MTP3 to M2UA. The diagram shows the case where the Link is In Service. The message is passed from MTP3 of the source to MTP3 of the destination. MTP3 M2UA SCTP SCTP M2UA MTP3 ---- ---- ---- ---- ---- ---- Request (Message for transmission) ------------> Send ------------> (SCTP sends message) Receive ------------> Indication (Received message) ------------> 4.3.4 Link Status Indication The M2UA layer sends an indication that the Link is In Service or Out of Service after receiving a Communication indication from the SCTP layer. In either case, MTP3 responds in its usual way. MTP3 M2UA SCTP SCTP M2UA MTP3 ---- ---- ---- ---- ---- ---- Communication Up <------------ (If Emergency Ceases, Link proving is done by M2UA now.) Indication (Link In Service) <------------ MTP3 M2UA SCTP SCTP M2UA MTP3 ---- ---- ---- ---- ---- ---- Communication Lost <------------ Indication (Link Out of Service) <------------ 4.3.5 Congestion Notification to Upper layer MTP3 layer expects notification of the link congestion. For example, this is accomplished by two messages 1) Link Congestion Onset 2) Link Congestion Abated. Congestion is assumed if M2UA layer notices repeated failures to send requests to SCTP (this is implementation dependent and it is assumed that the SEND Failure has an error code "life time expired"). Subsequently M2UA can start polling status of SCTP. If all the messages are successfully transmitted over a period of time (implementation dependent) then it is assumed that the congestion is abated. If the congestion condition should continue, the link will be taken out of service. In this case, it is possible to start the link changeover procedure. The US National version of SS7 has congestion levels. For US National SS7, the Indication primitive for Congestion Onset should report the congestion level. In the example below, M2UA has sent a message to SCTP. MTP3 M2UA SCTP SCTP M2UA MTP3 ---- ---- ---- ---- ---- ---- Send Failure <------------ Send Failure <------------ Send Failure <------------ "N" consecutive fails - implementation specific Indication (Congestion Onset) <------------ Status ------------> Status ------------> Status ------------> polled for certain time until congestion ceases - implementation specific Indication (Congestion Abatement) <------------ 4.3.6 Link Deactivation The MTP3 can request that a SS7-IP link be taken out-of-service. It uses the Release Request message as shown below. MTP3 M2UA SCTP SCTP M2UA MTP3 ---- ---- ---- ---- ---- ---- Request (Deactivate Link) ------------> Terminate ------------> Terminate Successful <------------ Communication Lost <------------ Indication (Link Out of Service) <------------ 4.3.7 Link Changeover The objective of the changeover is to ensure that signaling traffic carried by the unavailable signaling link is diverted to the alternative signaling link as quickly as possible while avoiding message loss, duplication, or mis-sequencing. For this purpose, the changeover procedure includes data retrieval, which is performed before reopening the alternative signaling links to the diverted traffic. Data retrieval consists of identifying all those messages in the retransmission buffer of the unavailable signaling link which have not been received by the far end. Retrieval includes transferring the concerned messages to the transmission buffers of the alternative links. In order to support changeover, the SCTP SSN must be used in place of the FSN/BSN of SS7. Stream Sequence Numbers used by SCTP (Signaling Control Transport Protocol) are sixteen bits long. MTP2's forward and backward sequence numbers are only seven bits long. Hence it is necessary to modify MTP3 to accomodate the larger SSNs. Reference [7] can be used as a guide for the MTP3 changes. For data retrieval, MTP3 requests Backward Sequence Number (BSN) from M2UA. This is the sequence number of the last message received by the local end. During normal period, SCTP delivers ordered messages to the application. However, during congestion or failure condition, the sequence numbers of the acknowledged messages can have gaps. In particular, the SACK (selective acknowledgement message) message can have several of these gaps. Hence, it is important to scan through these gaps and find the sequence number before first gap. This is the number from which the remote end has to transmit the messages. So, this is the number considered as the Backward Sequence Number and communicated to the remote end. In a similar way, the remote end also detects the BSN and indicates to local end. As soon as the MTP3 of the local end receives this BSN, MTP3 retrieves all the unacknowledged messages starting from BSN. This is accomplished through "Retrieve FSN" message. After all the messages are sent from M2UA to MTP3, a retrieval complete message is sent. Note that the sequence numbers and messages requested by MTP3 are sent from SCTP to M2UA in the Communication Lost primitive. MTP3 M2UA SCTP SCTP M2UA MTP3 ---- ---- ---- ---- ---- ---- Communication Lost <------------ Indication (Link Out of Service) <------------ Request (Retrieve BSN) ------------> (M2UA locates first gap in received messages) Indication (Indicate BSN) <------------ Request - COO (BSN) on another link ------------------------------------------------------------> Request (Retrieve BSN) <------------ Indication (Indicate BSN) ------------> Request - COA (BSN) <------------------------------------------------------------ Request (Retrieve FSN) ------------> (M2UA locates first gap in acknowledgements) Indication (FSB Not retrievable) (in case) <------------ Indication (Retrieved Message) <------------ Indication (Retrieved Message) <------------ Indication (Retrieval Complete) <------------ Send messages on another link. 4.4 Layer Management Communication Examples An example of the message flows for communication between Layer Manage- ment modules between SG and MGC is shown below. An active association between MGC and SG is established (section 4.1) prior to the following message flows. SG MGC <----------- Establish Request Error ----------> (Invalid Interface Id) Morneault, Kalla & Sidebottom [Page 31] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 5.0 Security SCN adaptation layers rely on SCTP to provide security. 6.0 Acknowledgements The authors would like to thank Ian Rytina for his valuable comments and suggestions. 7.0 References [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling System No. 7 (SS7)' [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - Message Transfer Part (MTP)' [3] Bellcore GR-246-CORE 'Bell Communications Research Specification of Signaling System Number 7', Volume 1, December 1995 [4] Framework Architecture for Signaling Transport, draft-ietf-sigtran- framework-arch-03.txt, June 1999 [5] Simple Control Transmission Protocol, draft-ietf-sigtran-sctp-00.txt, August 1999 [6] Media Gateway Control Protocol (MGCP), draft-huitema-megaco-mgcp- v1-03.txt, August 1999 [7] ITU-T Recommendation Q.2210, 'Message transfer part level 3 functions and messages using the services of ITU-T Recommendation Q.2140' Morneault, Kalla & Sidebottom [Page 32] Internet Draft SS7 MTP2 User Adaptation Layer Dec 1999 8.0 Author's Addresses Ken Morneault Tel: +1-703-484-3323 Cisco Systems Inc. EMail: [email protected] 13615 Dulles Technology Drive Herndon, VA. 20171 USA Malleswar Kalla Tel: +1-973-829-5212 Telcordia Technologies EMail: [email protected] MCC 1J211R 445 South Street Morristown, NJ 07960 USA Greg Sidebottom Tel: +1-613-763-7305 Nortel Networks EMail: [email protected] 3685 Richmond Rd, Nepean, Ontario Canada K2H5B7 Ram Dantu, Ph.D. Tel: +1-972-477-8446 Alcatel USA EMail: [email protected] 1000 Coit Road Plano, TX 74075 Tom George Tel: +1-972-519-3168 Alcatel USA EMail: [email protected] 1000 Coit Road Plano, TX 74075 This Internet Draft expires June 2000. | ||||||||||||||||
Last modified: Thu, 28 Nov 2024 10:20:49 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. |