sent.
An example of a message flow with an error retrieving the BSN is
shown below.
MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP
<-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req---
-BSN Not Rtrv->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---BSN Not Rtrv-->
(seq_num = -1)
An example of a message flow with an error retrieving the messages is
shown below.
<-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req---
-Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm-->
(seq_num = BSN)
<-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req---
(seq_num = FSN)
-Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm-->
(seq_num = -1)
An example of a message flow for a request to drop messages (clear
retransmission buffers) is shown below.
MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP
-Clr RTB Req----|<-StateReq (STATUS_CLEAR_RTB)--|<--Clr RTB Req-----
-Clr RTB Req--->|-StateCfm (STATUS_CLEAR_RTB)-->|---Clr RTB Req---->
5.3.7 Flush and Continue
The following message flow shows a request to flush buffers.
MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP
<--Flush Req----|<-State Req (STATUS_FLUSH_BUFS)--|<---Flush Req--
---Flush Cfm--->|--State Cfm (STATUS_FLUSH_BUFS)->|---Flush Cfm-->
The following message flow shows a request to continue.
MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP
<---Cont Req----|<--State Req (STATUS_CONTINUE)---|<---Cont Req---
----Cont Cfm--->|---State Cfm (STATUS_CONTINUE)-->|----Cont Cfm-->
5.3.8 Auditing of SS7 link state
It may be necessary for the ASP to audit the current state of a SS7
link. The flows below show an example of the request and all the
potential responses.
Below is an example in which the SS7 link is out-of-service.
MTP2 M2UA M2UA MGMT
SGP SGP ASP ASP
|<----State Req (STATUS_AUDIT)----|<----Audit-------
MTP3
ASP
|-----------Release Ind---------->|-Out of Serv Ind->
MGMT
ASP
|-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm--->
Below is an example in which the SS7 link is in-service.
MTP2 M2UA M2UA MGMT
SGP SGP ASP ASP
|<----State Req (STATUS_AUDIT)----|<----Audit-------
MTP3
ASP
|-----------Establish Cfm-------->|---In Serv Ind-->
MGMT
ASP
|-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm--->
Below is an example in which the SS7 link is in-service, but
congested.
MTP2 M2UA M2UA MGMT
SGP SGP ASP ASP
|<----State Req (STATUS_AUDIT)----|<----Audit-------
MTP3
ASP
|-----------Establish Cfm-------->|---In Serv Ind-->
|----------Congestion Ind-------->|---Cong Ind----->
MGMT
ASP
|-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm--->
Below is an example in which the SS7 link is in-service, but in
Remote Processor Outage.
MTP2 M2UA M2UA MGMT
SGP SGP ASP ASP
|<----State Req (STATUS_AUDIT)----|<---Audit Req----
MTP3
ASP
|-----------Establish Ind-------->|---In Serv Ind-->
|---State Ind (EVENT_RPO_ENTER)-->|----RPO Enter--->
MGMT
ASP
|-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm--->
6.0 Timer Values
The recommended default values for M2UA timers are:
T(r) 2 seconds
T(ack) 2 seconds
T(beat) Heartbeat Timer 30 seconds
7.0 Security Considerations
M2UA is designed to carry signalling messages for telephony services.
As such, M2UA MUST involve the security needs of several parties: the
end users of the services; the network providers and the applications
involved. Additional requirements MAY come from local regulation.
While having some overlapping security needs, any security solution
SHOULD fulfill all of the different parties' needs.
7.1 Threats
There is no quick fix, one-size-fits-all solution for security. As a
transport protocol, M2UA has the following security objectives:
* Availability of reliable and timely user data transport.
* Integrity of user data transport.
* Confidentiality of user data.
M2UA runs on top of SCTP. SCTP [8] provides certain transport
related security features, such as:
* Blind Denial of Service Attacks
* Flooding
* Masquerade
* Improper Monopolization of Services
When M2UA is running in a professionally managed corporate or service
provider network, it is reasonable to expect that this network
includes an appropriate security policy framework. The "Site
Security Handbook" [13] SHOULD be consulted for guidance.
When the network in which M2UA runs in involves more than one party,
it MAY NOT be reasonable to expect that all parties have implemented
security in a sufficient manner. In such a case, it is recommended
that IPSEC is used to ensure confidentiality of user payload.
Consult [14] for more information on configuring IPSEC services.
7.2 Protecting Confidentiality
Particularly for mobile users, the requirement for confidentiality
MAY include the masking of IP addresses and ports. In this case
application level encryption is not sufficient; IPSEC ESP SHOULD be
used instead. Regardless of which level performs the encryption, the
IPSEC ISAKMP service SHOULD be used for key management.
8.0 IANA Considerations
8.1 SCTP Payload Protocol Identifier
A request will be made to IANA to assign an M2UA value for the
Payload Protocol Identifier in SCTP Payload Data chunk. The
following SCTP Payload Protocol Identifier has been registered:
M2UA "2"
The SCTP Payload Protocol Identifier is included in each SCTP Data
chunk, to indicate which protocol the SCTP is carrying. This Payload
Protocol Identifier is not directly used by SCTP but MAY be used by
certain network entities to identify the type of information being
carried in a Data chunk.
The User Adaptation peer MAY use the Payload Protocol Identifier as a
way of determining additional information about the data being
presented to it by SCTP.
8.2 M2UA Protocol Extensions
This protocol may also be extended through IANA in three ways:
-- through definition of additional message classes,
-- through definition of additional message types, and
-- through definition of additional message parameters.
The definition and use of new message classes, types and parameters
is an integral part of SIGTRAN adaptation layers. Thus, these
extensions are assigned by IANA through an IETF Consensus action as
defined in [RFC2434].
The proposed extension must in no way adversely affect the general
working of the protocol.
8.2.1 IETF Defined Message Classes
The documentation for a new message class MUST include the following
information:
(a) A long and short name for the message class.
(b) A detailed description of the purpose of the message class.
8.2.2 IETF Defined Message Types
Documentation of the message type MUST contain the following
information:
(a) A long and short name for the new message type.
(b) A detailed description of the structure of the message.
(c) A detailed definition and description of intended use of each
field within the message.
(d) A detailed procedural description of the use of the new message
type within the operation of the protocol.
(e) A detailed description of error conditions when receiving this
message type.
When an implementation receives a message type which it does not
support, it MUST respond with an Error (ERR) message with an Error
Code of Unsupported Message Type.
8.2.3 IETF-defined TLV Parameter Extension
Documentation of the message parameter MUST contain the following
information:
(a) Name of the parameter type.
(b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general type-length-value
format described in Section 3.1.5.
(c) Detailed definition of each component of the parameter value.
(d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances
multiple instances of this parameter type may be found within the
same message type.
9.0 Acknowledgments
The authors would like to thank Tom George (Alcatel) for contribution
of text and effort on the specification.
The authors would like to thank John Loughney, Neil Olson, Michael
Tuexen, Nikhil Jain, Steve Lorusso, Dan Brendes, Joe Keller, Heinz
Prantner, Barry Nagelberg, Naoto Makinae, Joyce Archibald, Mark
Kobine, Nitin Tomar, Harsh Bhondwe and Karen King for their valuable
comments and suggestions.
10.0 References
10.1 Normative
[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] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part'
[4] Bellcore GR-246-CORE 'Bell Communications Research Specification
of Signalling System Number 7', Volume 1, December 1995
[5] Telecommunication Technology Committee (TTC) Standard JT-Q704,
Message Transfer Part Signaling Network Functions, April 28,
1992.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[7] Coded Character Set--7-Bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
10.2 Informative
[8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC2960, October 2000.
[9] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L.,
Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Architectural
Framework for Signalling Transport", RFC2719, October 1999.
[10] ITU-T Recommendation Q.2140, 'B-ISDN ATM Adaptation Layer',
February 1995
[11] ITU-T Recommendation Q.2210, 'Message transfer part level 3
functions and messages using the services of ITU-T
Recommendation Q.2140', August 1995
[12] ITU-T Recommendation Q.751.1, 'Network Element Management
Information Model for the Message Transfer Part', October 1995
[13] Fraser, B., "Site Security Handbook", FYI 8, RFC2196, September
1997.
[14] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC2401, November 1998.
Appendix A: Signalling Network Architecture
A Signalling Gateway will support the transport of MTP2-User
signalling traffic received from the SS7 network to one or more
distributed ASPs (e.g., MGCs). Clearly, the M2UA protocol
description cannot in itself meet any performance and reliability
requirements for such transport. A physical network architecture is
required, with data on the availability and transfer performance of
the physical nodes involved in any particular exchange of
information. However, the M2UA protocol is flexible enough to allow
its operation and management in a variety of physical configurations
that will enable Network Operators to meet their performance and
reliability requirements.
To meet the stringent SS7 signalling reliability and performance
requirements for carrier grade networks, these Network Operators
should ensure that there is no single point of failure provisioned in
the end-to-end network architecture between an SS7 node and an IP
ASP.
Depending of course on the reliability of the SGP and ASP functional
elements, this can typically be met by spreading SS7 links in a SS7
linkset [1] across SGPs or SGs, the provision of redundant QoS-
bounded IP network paths for SCTP Associations between SCTP End
Points, and redundant Hosts. The distribution of ASPs within the
available Hosts is also important. For a particular Application
Server, the related ASPs MAY be distributed over at least two Hosts.
An example of logical network architecture relevant to carrier-grade
operation in the IP network domain is shown in Figure 7 below:
************** **************
* ********__*______________________________*__******** * Host1
SG1 * * SGP1 *__*________________ _______*__* ASP1 * *
* ******** * | | * ******** *
* . * | | * *
* . * | | **************
************** | |
| |
************** | |
* ********__*______________________|
SG2 * * SGP2 *__*________ |
* ******** * | |
* . * | |
* . * | |
************** | | **************
| |_____________*__******** * Host2
|_____________________*__* ASP2 * *
. * ******** *
. SCTP Associations * *
. **************
.
.
.
Figure 7: Logical Model Example
To avoid a single point of failure, it is recommended that a minimum
of two ASPs be configured in an AS list, resident in separate hosts
and, therefore, available over different SCTP associations. For
example, in the network shown in Figure 7, all messages for the
Interface Identifiers could be sent to ASP1 in Host1 or ASP2 in
Host2. The AS list at SGP1 might look like the following:
Interface Identifiers - Application Server #1
ASP1/Host1 - State = Active
ASP2/Host2 - State = Inactive
In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming
message for the Interface Identifiers registered. ASP2 in Host2
would normally be brought to the active state upon failure of
ASP1/Host1. In this example, both ASPs are Inactive or Active,
meaning that the related SCTP association and far-end M2UA peer is
ready.
For carrier grade networks, Operators should ensure that under
failure or isolation of a particular ASP, stable calls or
transactions are not lost. This implies that ASPs need, in some
cases, to share the call/-transaction state or be able to pass the
call/transaction state between each other. Also, in the case of ASPs
performing call processing, coordination MAY be required with the
related Media Gateway to transfer the MGC control for a particular
trunk termination. However, this sharing or communication is outside
the scope of this document.
11.0 Authors' Addresses
Ken Morneault
Cisco Systems Inc.
13615 Dulles Technology Drive
Herndon, VA. 20171
USA
Phone: +1-703-484-3323
EMail: kmorneau@cisco.com
Ram Dantu, Ph.D.
NetRake Corporation
3000 Technology Drive
Plano, TX 75074
USA
Phone: +1-214-291-1111
EMail: rdantu@netrake.com
Greg Sidebottom
Signatus Technologies
Kanata, Ontario, Canada
EMail: greg@signatustechnologies.com
Brian Bidulock
OpenSS7 Corporation
1469 Jeffreys Crescent
Edmonton, AB T6L 6T1
Canada
Phone: +1-780-490-1141
EMail: bidulock@openss7.org
Jacob Heitz
Lucent Technologies
1701 Harbor Bay Parkway
Alameda, CA, 94502
USA
Phone: +1-510-747-2917
EMail: jheitz@lucent.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.