tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 3331


Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer

Part 5 of 5, p. 85 to 94
Prev RFC Part


prevText      Top      Up      ToC       Page 85 
6. 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. 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.

Top      Up      ToC       Page 86 
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. 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.

Top      Up      ToC       Page 87 
8.2.1 IETF Defined Message Classes

   The documentation for a new message class MUST include the following

   (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

   (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

   (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.  Acknowledgments

   The authors would like to thank Tom George (Alcatel) for contribution
   of text and effort on the specification.

Top      Up      ToC       Page 88 
   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.  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,

   [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", RFC 2960, 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", RFC 2719, 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

Top      Up      ToC       Page 89 
   [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, RFC 2196, September

   [14] Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

Top      Up      ToC       Page 90 
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

   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.

Top      Up      ToC       Page 91 
   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

Top      Up      ToC       Page 92 
   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.  Authors' Addresses

   Ken Morneault
   Cisco Systems Inc.
   13615 Dulles Technology Drive
   Herndon, VA. 20171

   Phone: +1-703-484-3323

   Ram Dantu, Ph.D.
   NetRake Corporation
   3000 Technology Drive
   Plano, TX 75074

   Phone: +1-214-291-1111

   Greg Sidebottom
   Signatus Technologies
   Kanata, Ontario, Canada


   Brian Bidulock
   OpenSS7 Corporation
   1469 Jeffreys Crescent
   Edmonton, AB  T6L 6T1

   Phone: +1-780-490-1141

Top      Up      ToC       Page 93 
   Jacob Heitz
   Lucent Technologies
   1701 Harbor Bay Parkway
   Alameda, CA, 94502

   Phone: +1-510-747-2917

Top      Up      ToC       Page 94 
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

   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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.