doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc4166.txt b/doc/rfc/rfc4166.txt
new file mode 100644
index 0000000..2603300
--- /dev/null
+++ b/doc/rfc/rfc4166.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group                                           L. Coene
+Request for Comments: 4166                                       Siemens
+Category: Informational                                 J. Pastor-Balbas
+                                                                Ericsson
+                                                           February 2006
+
+
+                  Telephony Signalling Transport over
+  Stream Control Transmission Protocol (SCTP) Applicability Statement
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes the applicability of the several protocols
+   developed under the signalling transport framework.  A description of
+   the main issues regarding the use of the Stream Control Transmission
+   Protocol (SCTP) and an explanation of each adaptation layer for
+   transport of telephony signalling information over IP infrastructure
+   are given.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Coene & Pastor-Balbas        Informational                      [Page 1]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Scope ......................................................2
+      1.2. Terminology ................................................3
+      1.3. Contributors ...............................................3
+   2. SIGTRAN Architecture ............................................3
+   3. Issues for Transporting Telephony Signalling over SCTP ..........5
+      3.1. Congestion Control .........................................5
+      3.2. Detection of Failures ......................................6
+           3.2.1. Retransmission TimeOut (RTO) Calculation ............6
+           3.2.2. Heartbeat ...........................................7
+           3.2.3. Maximum Number of Retransmissions ...................7
+      3.3. Shorten End-to-End Message Delay ...........................7
+      3.4. Bundling Considerations ....................................7
+      3.5. Stream Usage ...............................................7
+   4. User Adaptation Layers ..........................................7
+      4.1. Access Signalling .........................................10
+           4.1.1. IUA (ISDN Q.921 User Adaptation) ...................10
+           4.1.2. V5UA (V5.2-User Adaptation) Layer ..................12
+           4.1.3. DUA (DPNSS/DASS User adaptation) Layer .............13
+      4.2. Network Signalling ........................................13
+           4.2.1. MTP lvl3 over IP ...................................14
+           4.2.2. M3UA (SS7 MTP3 User Adaptation) Layer ..............17
+           4.2.3. SUA (SS7 SCCP User Adaptation) Layer ...............18
+   5. Security Considerations ........................................20
+   6. Informative References .........................................20
+
+1.  Introduction
+
+   This document is intended to describe how to transport telephony
+   signalling protocols, used in classic telephony systems, over IP
+   networks.  As described in [RFC2719], the whole architecture is
+   called SIGTRAN (Signalling Transport) and is composed of a transport
+   protocol (SCTP) and several User Adaptation Layers (UALs).  The
+   transport protocol SCTP has been developed to fulfill the stringent
+   requirements of telephony signalling networks [RFC3257].  The set of
+   UALs has also been introduced to make it possible for different
+   signalling protocols to use the SCTP layer.
+
+1.1.  Scope
+
+   The scope of this document is the SIGTRAN user adaptation layers and
+   SCTP protocols and how they are used to transport telephony
+   signalling information over IP networks.
+
+
+
+
+
+
+Coene & Pastor-Balbas        Informational                      [Page 2]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+1.2.  Terminology
+
+   The following terms are commonly identified in related work:
+
+   Association: SCTP connection between two endpoints.
+
+   Stream:      A uni-directional logical channel established within an
+                association, within which all user messages are
+                delivered in sequence except for those submitted to the
+                unordered delivery service.
+
+   SPU:         Signalling protocol user, the application on top of the
+                User adaptation layer.
+
+   CTSP:        Classical Telephony Signalling Protocol (examples
+                include: MTP level 2, MTP level 3, and SCCP).
+
+   UAL:         User Adaptation Layer, the protocol that encapsulates
+                the upper layer telephony signalling protocols that are
+                to be transported over SCTP/IP.
+
+   ISEP:        IP Signalling Endpoint, an IP node that implements SCTP
+                and a User adaptation layer.
+
+   SP:          Signalling Point.
+
+1.3.  Contributors
+
+   The following people contributed to the document: L. Coene (Editor),
+   M. Tuexen, G. Verwimp, J. Loughney, R.R. Stewart, Qiaobing Xie, M.
+   Holdrege, M.C. Belinchon, A. Jungmaier, J. Pastor, and L. Ong.
+
+2.  SIGTRAN Architecture
+
+   The SIGTRAN architecture describes the transport of signalling
+   information over IP infrastructure.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Coene & Pastor-Balbas        Informational                      [Page 3]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+   Telephony signalling transport over IP normally uses the following
+   architecture:
+
+                    Telephony Signalling Protocol
+                                 |
+                +------------------------------------+
+                |       User Adaptation Layers       |
+                +------------------------------------+
+                                 |
+                +------------------------------------+
+                |Stream Control Transmission Protocol|
+                |             (SCTP)                 |
+                +------------------------------------+
+                                 |
+                  Internet Protocol (IPv4/IPv6)
+
+          Figure 1: Telephony SIGnalling TRANsport Protocol Stack
+
+   The components of the protocol stack are:
+
+   1.  Adaptation layers used when the telephony application needs to
+       preserve an existing primitive interface (e.g., management
+       indications or data operation primitives for a particular
+       user/application protocol).
+   2.  SCTP, specially configured to meet the telephony application
+       performance requirements.
+   3.  The standard Internet Protocol.
+
+   The telephony signalling protocols to be transported can be:
+
+   o  [RFC3332] SS7 MTP3 users: SCCP, ISUP, TUP...
+   o  [RFC3331] SS7 MTP2 users: MTP3
+   o  [RFC3868] SS7 SCCP users: RANAP, MAP(+TCAP), INAP(+TCAP)...
+   o  [RFC3057] ISDN Q.921 users: Q.931
+   o  [RFC3807] V5.2 / DSS1
+   o  ....
+
+   The user adaptation layers (UALs) are a set of protocols that
+   encapsulate a specific signalling protocol to be transported over
+   SCTP.  The adaption is done in a way that the upper signalling
+   protocols, which are relayed, remain unaware that the lower layers
+   are different from the original lower telephony signalling layers.
+   In that sense, the upper interface of the user adaptation layers
+   needs to be the same as the upper layer interface is to its original
+   lower layer.  If a MTP user is being relayed over the IP network, the
+   related UAL used to transport the MTP user will have the same upper
+   interface as MTP has.
+
+
+
+
+Coene & Pastor-Balbas        Informational                      [Page 4]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+   The Stream Control Transmission Protocol was designed to fulfill the
+   stringent transport requirements that classical signalling protocols
+   have and is therefore the recommended transport protocol to use for
+   this purpose.
+
+   SCTP provides the following functions:
+
+   o  Reliable Data Transfer
+   o  Multiple streams to help avoid head-of-line blocking
+   o  Ordered and unordered data delivery on a per-stream basis
+   o  Bundling and fragmentation of user data
+   o  Congestion and flow control
+   o  Support for continuous monitoring of reachability
+   o  Graceful termination of association
+   o  Support of multi-homing for added reliability
+   o  Protection against blind denial-of-service attacks
+   o  Protection against blind masquerade attacks
+
+   SCTP is used as the transport protocol for telephony signalling
+   applications.  Message boundaries are preserved during data transport
+   by SCTP, so each UAL can specify its own message structure within the
+   SCTP user data.  The SCTP user data can be delivered by the order of
+   transmission within a stream (in sequence delivery) or unordered.
+
+   SCTP can be used to provide redundancy at the transport layer and
+   below.  Telephony applications needing this level of redundancy can
+   make use of SCTP's multi-homing support.
+
+   SCTP can be used for telephony applications where head-of-line
+   blocking is a concern.  Such an application should use multiple
+   streams to provide independent ordering of telephony signalling
+   messages.
+
+3.  Issues for Transporting Telephony Signalling over SCTP
+
+   Transport of telephony signalling requires special considerations.
+   In order to use SCTP, an implementation must take special care to
+   meet the performance, timing, and failure management requirements.
+
+3.1.  Congestion Control
+
+   The basic mechanism of congestion control in SCTP has been described
+   in [RFC2960].  SCTP congestion control sometimes conflicts with the
+   timing requirements of telephony signalling application messages
+   which are transported by SCTP.  During congestion, messages may be
+   delayed by SCTP, thus sometimes violating the timing requirements of
+   those telephony applications.
+
+
+
+
+Coene & Pastor-Balbas        Informational                      [Page 5]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+   In an engineered network (e.g., a private intranet), in which network
+   capacity and maximum traffic are very well controlled, some telephony
+   signalling applications may choose to relax the congestion control
+   rules of SCTP in order to satisfy the timing requirements.  In order
+   to do this, they should employ their own congestion control
+   mechanisms.  This must be done without destabilizing the network;
+   otherwise, it would lead to potential congestion collapse of the
+   network.
+
+   Some telephony signalling applications may have their own congestion
+   control and flow control techniques.  These techniques may interact
+   with the congestion control procedures in SCTP.
+
+3.2.  Detection of Failures
+
+   Often, telephony systems must have no single point of failure in
+   operation.
+
+   The UAL must meet certain service availability and performance
+   requirements according to the classical signalling layers they are
+   replacing.  Those requirements may be specific for each UAL.
+
+   For example, telephony systems are often required to be able to
+   preserve stable calls during a component failure.  Therefore, error
+   situations at the transport layer and below must be detected quickly
+   so that the UAL can take appropriate steps to recover and preserve
+   the calls.  This poses special requirements on SCTP to discover
+   unreachability of a destination address or a peer.
+
+3.2.1.  Retransmission TimeOut (RTO) Calculation
+
+   The SCTP protocol parameter RTO.Min value has a direct impact on the
+   calculation of the RTO itself.  Some telephony applications want to
+   lower the value of the RTO.Min to less than 1 second.  This would
+   allow the message sender to reach the maximum
+   number-of-retransmission threshold faster in the case of network
+   failures.  However, lowering RTO.Min may have a negative impact on
+   network behaviour [ALLMAN99].
+
+   In some rare cases, telephony applications might not want to use the
+   exponential timer back-off concept in RTO calculation in order to
+   speed up failure detection.  The danger of doing this is that, when
+   network congestion occurs, not backing off the timer may worsen the
+   congestion situation.  Therefore, this strategy should never be used
+   on the public Internet.
+
+   It should be noted that not using delayed SACK will also increase the
+   speed of failure detection.
+
+
+
+Coene & Pastor-Balbas        Informational                      [Page 6]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+3.2.2.  Heartbeat
+
+   For faster detection of (un)availability of idle paths, the telephony
+   application may consider lowering the SCTP parameter HB.interval.  It
+   should be noted this might result in a higher traffic load.
+
+3.2.3.  Maximum Number of Retransmissions
+
+   Setting Path.Max.Retrans and Association.Max.Retrans SCTP parameters
+   to lower values will speed up both destination address and peer
+   failure detection.  However, if these values are set too low, the
+   probability of false fault detections might increase.
+
+3.3.  Shorten End-to-End Message Delay
+
+   Telephony applications often require short end-to-end message delays.
+   The method described in Section 3.2.1 for lowering RTO may be
+   considered.  The different paths within a single association will
+   have a different RTO, so using the path with the lowest RTO will lead
+   to a shorter end-to-end message delay for the application running on
+   top of the UALs.
+
+3.4.  Bundling Considerations
+
+   Bundling small telephony signalling messages at transmission helps
+   improve the bandwidth usage efficiency of the network.  On the
+   downside, bundling may introduce additional delay to some of the
+   messages.  This should be taken into consideration when end-to-end
+   delay is a concern.
+
+3.5.  Stream Usage
+
+   Telephony signalling traffic is often composed of multiple,
+   independent message sequences.  It is highly desirable to transfer
+   those independent message sequences in separate SCTP streams.  This
+   reduces the probability of head-of-line blocking in which the
+   retransmission of a lost message affects the delivery of other
+   messages not belonging to the same message sequence.
+
+4.  User Adaptation Layers
+
+   Users Adaptation Layers (UALs) are defined to encapsulate different
+   signalling protocols for transport over SCTP/IP.
+
+   There are UALs for both access signalling (DSS1) and trunk signalling
+   (SS7).  A brief description of the standardized UALs follows in the
+   next sub-sections.
+
+
+
+
+Coene & Pastor-Balbas        Informational                      [Page 7]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+   The delivery mechanism in several UALs supports:
+
+   o  Seamless operation of UALs user peers over an IP network
+      connection.
+   o  The interface boundary that the UAL user had with the traditional
+      lower layer.
+   o  Management of SCTP transport associations and traffic between SGs
+      and ISEPs or two ISEPs
+   o  Asynchronous reporting of status changes to management.
+
+   Signalling User Adaptation Layers have been developed for both Access
+   and Trunk Telephony Signalling.  They are defined as follows.
+
+   Access Signalling: This is the signalling that is needed between an
+   access device and an exchange in the core network in order to
+   establish, manage, or release the voice or data call paths.  Several
+   protocols have been developed for this purpose.
+
+   Trunk Signalling: This is the signalling that is used between the
+   exchanges inside the core network in order to establish, manage, or
+   release the voice or data call paths.  The most common protocols used
+   for this purpose are known as the SS7 system, which belongs to the
+   Common Channel Signalling (CCS) philosophy.  The SS7 protocol stack
+   is depicted below:
+
+              +------+-----+-------+- -+-------+------+-----+------+
+              |      |     |       |   |       |  MAP | CAP | INAP |
+              +      |     + RANAP |...| BSSAP +-------------------+
+              | ISUP | TUP |       |   |       |       TCAP        |
+              +      |     +---------------------------------------+
+              |      |     |                  SCCP                 |
+              +----------------------------------------------------+
+              |                          MTP3                      |
+              +----------------------------------------------------+
+              |                          MTP2                      |
+              +----------------------------------------------------+
+              |                          MTP1                      |
+              +----------------------------------------------------+
+
+                       Figure 2: SS7 Protocol Stack
+
+
+
+
+
+
+
+
+
+
+
+Coene & Pastor-Balbas        Informational                      [Page 8]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+   The Telephony Signalling Protocols to be transported with the already
+   designed UALS are:
+
+   o  ISDN Q.921 Users: Q.931
+   o  V5.2/DSS1
+   o  DPNSS/DASS2 [RFC4129]
+   o  SS7 MTP3 Users: SCCP, ISUP, TUP
+   o  SS7 MTP2 Users: MTP3
+   o  SS7 SCCP Users: TCAP, RANAP, BSSAP, ...
+
+   Two main scenarios have been developed to use the different UALS for
+   IP Signalling Transport:
+
+   1.  Intercommunication of traditional Signalling transport nodes and
+       IP based nodes.
+
+                        Traditional               Telephony
+                         Telephony                Signalling
+             *********   Signalling   **********   over IP    ********
+             *  SEP  *----------------*   SG   *--------------* ISEP *
+             *********                **********              ********
+
+             +-------+                                        +-------+
+             |SigProt|                                        |SigProt|
+             +-------+                +----+----+             +-------+
+             |       |                |    |UAL |             |  UAL  |
+             |       |                |    +----+             +-------+
+             | TTST  |                |TTST|SCTP|             | SCTP  |
+             |       |                |    +----+             +-------+
+             |       |                |    | IP |             |  IP   |
+             +-------+                +---------+             +-------+
+
+                   SEP     -   Signalling Endpoint
+                   SG      -   Signalling Gateway
+                   ISEP    -   IP Signalling Endpoint
+                   SigProt -   Signalling Protocol
+                   TTSP    -   Traditional Telephony Signalling Protocol
+                   UAL     -   User Adaptation Layer
+                   SCTP    -   Stream Control Transport Protocol
+
+          Figure 3: General Architecture of SS7-IP Interworking
+
+   This is also referred to as SG-to-AS communication.  AS is the name
+   that UAL usually gives to the ISEP nodes.  It stands for Application
+   Server.
+
+
+
+
+
+
+Coene & Pastor-Balbas        Informational                      [Page 9]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+   2.  Communication inside the IP network.
+
+                                      Telephony
+                                      Signalling
+                         *********     over IP      *********
+                         * ISEP  *------------------*  ISEP *
+                         *********                  *********
+
+                         +-------+                  +-------+
+                         |SigProt|                  |SigProt|
+                         +-------+                  +-------+
+                         |  UAL  |                  |  UAL  |
+                         +-------+                  +-------+
+                         | SCTP  |                  | SCTP  |
+                         +-------+                  +-------+
+                         |  IP   |                  |  IP   |
+                         +-------+                  +-------+
+
+         Figure 4: General Architecture of Intra-IP Communication
+
+   This is also referred to as IPSP communication.  IPSP stands for IP
+   Signalling Point and describes the role that the UAL plays on an
+   IP-based node.
+
+   The first scenario is applied for both types of signalling (access
+   and trunk signalling).  On the other hand, the peer-to-peer basis can
+   only be used for trunk signalling.
+
+4.1.  Access Signalling
+
+   The SIGTRAN WG has developed UALs to transport the following Access
+   Signalling protocols:
+
+   o  ISDN Q.931
+   o  V5.2
+   o  DPNSS/DASS2
+
+4.1.1.  IUA (ISDN Q.921 User Adaptation)
+
+   UAL: IUA (ISDN Q.921 User Adaptation)
+
+   This document supports both ISDN Primary Rate Access (PRA) as well as
+   Basic Rate Access (BRA) including the support for both point-to-point
+   and point-to-multipoint modes of communication.  This support
+   includes Facility Associated Signalling (FAS), Non-Facility
+   Associated Signalling (NFAS), and NFAS with backup D channel.
+
+
+
+
+
+Coene & Pastor-Balbas        Informational                     [Page 10]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+   It implements the client/server architecture.  The default
+   orientation is for the SG to take on the role of server while the
+   ISEP is the client.  The SCTP (and UDP/TCP) Registered User Port
+   Number Assignment for IUA is 9900.
+
+   Examples of the upper layers to be transported are Q.931 and QSIG.
+
+   The main scenario supported by this UAL is the SG-to-ISP
+   communication where the ISEP role is typically played by a node
+   called an MGC, as defined in [RFC2719].
+
+
+
+                   ******   ISDN        ******      IP      *******
+                   *PBX *---------------* SG *--------------* MGC *
+                   ******               ******              *******
+
+                   +-----+                                  +-----+
+                   |Q.931|              (NIF)               |Q.931|
+                   +-----+           +----------+           +-----+
+                   |     |           |     | IUA|           | IUA |
+                   |     |           |     +----+           +-----+
+                   |Q.921|           |Q.921|SCTP|           |SCTP |
+                   |     |           |     +----+           +-----+
+                   |     |           |     | IP |           | IP  |
+                   +-----+           +-----+----+           +-----+
+
+                   NIF  - Nodal Interworking Function
+                   PBX  - Private Branch Exchange
+                   SCTP - Stream Control Transmission Protocol
+                   IUA  - ISDN User Adaptation Layer Protocol
+
+                 Figure 5: ISDN-IP Interworking using IUA
+
+   The SCTP (and UDP/TCP) Registered User Port Number Assignment for IUA
+   is 9900.
+
+   The value assigned by IANA for the Payload Protocol Identifier in the
+   SCTP Payload Data chunk is "1".
+
+
+
+
+
+
+
+
+
+
+
+
+Coene & Pastor-Balbas        Informational                     [Page 11]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+4.1.2.  V5UA (V5.2-User Adaptation) Layer
+
+   UAL: V5UA (V5.2-User Adaptation)
+
+   V5UA is an extension from the IUA layer with the modifications needed
+   to support the differences between Q.921/Q.931, and V5.2 layer
+   2/layer 3.  It supports analog telephone access, ISDN basic rate
+   access and ISDN primary rate access over a V5.2 interface.  It is
+   typically implemented in an interworking scenario with SG.
+
+               ******   V5.2        ******      IP      *******
+               * AN *---------------* SG *--------------* MGC *
+               ******               ******              *******
+
+
+               +-----+                                  +-----+
+               |V5.2 |              (NIF)               |V5.2 |
+               +-----+           +----------+           +-----+
+               |     |           |     |V5UA|           |V5UA |
+               |     |           |     +----+           +-----+
+               |LAPV5|           |LAPV5|SCTP|           |SCTP |
+               |     |           |     +----+           +-----+
+               |     |           |     | IP +           | IP  |
+               +-----+           +-----+----+           +-----+
+
+               AN    - Access Network
+               NIF   - Nodal Interworking Function
+               LAPV5 - Link Access Protocol for the V5 channel
+               SCTP  - Stream Control Transmission Protocol
+
+                 Figure 6: V5.2-IP Interworking using V5UA
+
+   The SCTP (and UDP/TCP) Registered User Port Number Assignment for
+   V5UA is 5675.
+
+   The value assigned by IANA for the Payload Protocol Identifier in the
+   SCTP Payload Data chunk is "6".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Coene & Pastor-Balbas        Informational                     [Page 12]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+4.1.3.  DUA (DPNSS/DASS User adaptation) Layer
+
+   UAL: DUA (DPNSS/DASS2 User Adaptation)
+
+   The DUA is built on top of IUA and defines the necessary extensions
+   to IUA for a DPNSS/DASS2 transport.  DPNSS stands for Digital Private
+   Network Signalling System and DASS2 for Digital Access Signalling
+   System 2.
+
+                  ******   DPNSS       ******      IP      *******
+                  *PBX *---------------* SG *--------------* MGC *
+                  ******               ******              *******
+
+                  +-----+                                  +-----+
+                  |DPNSS|              (NIF)               |DPNSS|
+                  | L3  |                                  | L3  |
+                  +-----+           +-----+----+           +-----+
+                  |     |           |     | DUA|           | DUA |
+                  |DPNSS|           |DPNSS+----+           +-----+
+                  | L2  |           | L2  |SCTP|           |SCTP |
+                  |     |           |     +----+           +-----+
+                  |     |           |     | IP +           | IP  |
+                  +-----+           +-----+----+           +-----+
+
+             PBX  - Private Branch eXchange
+             NIF  - Nodal Interworking Function
+             SCTP - Stream Control Transmission Protocol
+             DUA  - DPNSS User Adaptation Layer Protocol
+
+                 Figure 7: DPNSS-IP Interworking using DUA
+
+   The value assigned by IANA for the Payload Protocol Identifier in the
+   SCTP Payload Data chunk is "10".  .
+
+4.2.  Network Signalling
+
+   The SIGTRAN WG has developed UALs to transport the following SS7
+   protocols:
+
+   o  MTP2 Users: MTP3
+   o  MTP3 Users: ISUP, TUP, SCCP
+   o  SCCP Users: TCAP, RNSAP, RANAP, BSSAP, ...
+
+
+
+
+
+
+
+
+
+Coene & Pastor-Balbas        Informational                     [Page 13]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+4.2.1.  MTP lvl3 over IP
+
+   UALs:
+
+   o  M2UA (SS7 MTP2 User Adaptation [RFC3331])
+   o  M2PA (SS7 MTP2-User Peer-to-Peer Adaptation [RFC4165])
+
+4.2.1.1.  M2UA (SS7 MTP2-User Adaptation) Layer
+
+   M2UA protocol is typically used between a Signalling Gateway (SG) and
+   Media Gateway Controller (MGC).  The SG will terminate up to MTP
+   Level 2, and the MGC will terminate MTP Level 3 and above.  In other
+   words, the SG will transport MTP Level 3 messages over an IP network
+   to an MGC.
+
+   MTP3 and MTP3b are the only SS7 MTP2 User protocols that are
+   transported by this UAL.
+
+   The SG provides an interworking of transport functions with the IP
+   transport to transfer MTP2-User signalling messages with an
+   Application Server (e.g., MGC) where the peer MTP2-User exists.
+
+                  ******    SS7    ******      IP     *******
+                  *SEP *-----------* SG *-------------* MGC *
+                  ******           ******             *******
+
+                  +----+                              +----+
+                  |S7UP|                              |S7UP|
+                  +----+                              +----+
+                  |MTP3|                              |MTP3|
+                  |    |            (NIF)             |    |
+                  +----+         +----+----+          +----+
+                  |    |         |    |M2UA|          |M2UA|
+                  |    |         |    +----+          +----+
+                  |MTP2|         |MTP2|SCTP|          |SCTP|
+                  |    |         |    +----+          +----+
+                  |    |         |    |IP  |          |IP  |
+                  +----+         +---------+          +----+
+
+                  MGC  - Media Gateway Controller
+                  SG   - Signalling Gateway
+                  SEP  - SS7 Signalling Endpoint
+                  NIF  - Nodal Interworking Function
+                  IP   - Internet Protocol
+                  SCTP - Stream Control Transmission Protocol
+
+                 Figure 8: SS7-IP Interworking using M2UA
+
+
+
+
+Coene & Pastor-Balbas        Informational                     [Page 14]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+   The SCTP (and UDP/TCP) Registered User Port Number Assignment for
+   M2UA is 2904.
+
+   The value assigned by IANA for the Payload Protocol Identifier in the
+   SCTP Payload Data chunk is "2".
+
+4.2.1.2.  M2PA (SS7 MTP2-User Peer-to-Peer Adaptation)
+
+   M2PA protocol is used between SS7 Signalling Points employing the MTP
+   Level 3 protocol.  The SS7 Signalling Points may also use standard
+   SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level
+   3 signalling messages.
+
+   Both configurations: communication of SS7 and IP with SG and
+   communication between ISEPs are possible.
+
+   Connection of SS7 and IP nodes:
+
+               ********  SS7   ***************   IP   ********
+               * SEP  *--------*     SG      *--------* IPSP *
+               ********        ***************        ********
+
+               +------+                               +------+
+               | TCAP |                               | TCAP |
+               +------+                               +------+
+               | SCCP |                               | SCCP |
+               +------+        +-------------+        +------+
+               | MTP3 |        |    MTP3     |        | MTP3 |
+               +------+        +------+------+        +------+
+               |      |        |      | M2PA |        | M2PA |
+               |      |        |      +------+        +------+
+               | MTP2 |        | MTP2 | SCTP |        | SCTP |
+               |      |        |      +------+        +------+
+               |      |        |      | IP   |        | IP   |
+               +------+        +------+------+        +------+
+
+                       SEP   - SS7 Signalling Endpoint
+
+                  Figure 9: SS7-IP Interworking with M2PA
+
+
+
+
+
+
+
+
+
+
+
+
+Coene & Pastor-Balbas        Informational                     [Page 15]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+   Communication between two IP nodes:
+
+                              ********   IP   ********
+                              * IPSP *--------* IPSP *
+                              ********        ********
+
+                              +------+        +------+
+                              | TCAP |        | TCAP |
+                              +------+        +------+
+                              | SCCP |        | SCCP |
+                              +------+        +------+
+                              | MTP3 |        | MTP3 |
+                              +------+        +------+
+                              | M2PA |        | M2PA |
+                              +------+        +------+
+                              | SCTP |        | SCTP |
+                              +------+        +------+
+                              |  IP  |        |  IP  |
+                              +------+        +------+
+
+                       IP    - Internet Protocol
+                       IPSP  - IP Signalling Point
+                       SCTP  - Stream Control Transmission Protocol
+
+               Figure 10: Intra-IP Communication using M2PA
+
+   These figures are only an example.  Other configurations are
+   possible.  For example, IPSPs without traditional SS7 links could use
+   the protocol layers MTP3/M2PA/SCTP/IP to route SS7 messages in a
+   network with all IP links.
+
+   Another example is that two SGs could be connected over an IP network
+   to form an SG mated pair, similar to the way STPs are provisioned in
+   traditional SS7 networks.
+
+   The SCTP (and UDP/TCP) Registered User Port Number Assignment for
+   M2PA is 3565.
+
+   The value assigned by IANA for the Payload Protocol Identifier in the
+   SCTP Payload Data chunk is "5".
+
+
+
+
+
+
+
+
+
+
+
+Coene & Pastor-Balbas        Informational                     [Page 16]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+4.2.1.3.  Main Differences between M2PA and M2UA
+
+   o  M2PA: IPSP processes MTP3/MTP2 primitives.
+   o  M2UA: MGC transports MTP3/MTP2 primitives between the SG's MTP2
+      and the MGC's MTP3 (via the NIF) for processing.
+   o  M2PA: SG-IPSP connection is an SS7 link.
+   o  M2UA: SG-MGC connection is not an SS7 link.  It is an extension of
+      MTP to a remote entity.
+
+4.2.2.  M3UA (SS7 MTP3 User Adaptation) Layer
+
+   UAL: M3UA (SS7 MTP3 User Adaptation)
+
+   M3UA protocol supports the transport of any SS7 MTP3-User signalling
+   such as TUP, ISUP, and SCCP over IP using the services of SCTP.
+
+   Interconnection of SS7 and IP nodes:
+
+               ********   SS7   *****************   IP   ********
+               * SEP  *---------*      SGP      *--------* ASP  *
+               ********         *****************        ********
+
+               +------+         +---------------+        +------+
+               | ISUP |         |     (NIF)     |        | ISUP |
+               +------+         +------+ +------+        +------+
+               | MTP3 |         | MTP3 | | M3UA |        | M3UA |
+               +------|         +------+-+------+        +------+
+               | MTP2 |         | MTP2 | | SCTP |        | SCTP |
+               +------+         +------+ +------+        +------+
+               |  L1  |         |  L1  | |  IP  |        |  IP  |
+               +------+         +------+ +------+        +------+
+
+                   SEP  - SS7 Signalling End Point
+                   SCTP - Stream Control Transmission Protocol
+                   NIF  - Nodal Interworking Function
+
+                 Figure 11: SS7-IP Interworking using M3UA
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Coene & Pastor-Balbas        Informational                     [Page 17]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+   Communication between two IP nodes:
+
+                           ********    IP    ********
+                           * IPSP *----------* IPSP *
+                           ********          ********
+
+                           +------+          +------+
+                           |SCCP- |          |SCCP- |
+                           | User |          | User |
+                           +------+          +------+
+                           | SCCP |          | SCCP |
+                           +------+          +------+
+                           | M3UA |          | M3UA |
+                           +------+          +------+
+                           | SCTP |          | SCTP |
+                           +------+          +------+
+                           |  IP  |          |  IP  |
+                           +------+          +------+
+
+               Figure 12: Intra-IP Communication using M3UA
+
+   M3UA uses a client-server architecture.  It is recommended that the
+   ISEP acts as the client and initiate the SCTP associations with the
+   SG.  The port reserved by IANA is 2905.  This is the port upon which
+   the SG should listen for possible client connections.
+
+   The assigned payload protocol identifier for the SCTP DATA chunks is
+   "3".
+
+4.2.3.  SUA (SS7 SCCP User Adaptation) Layer
+
+   UAL: SUA (SS7 SCCP User Adaptation)
+
+   SUA protocol supports the transport of any SS7 SCCP-User signalling
+   such as MAP, INAP, SMS, BSSAP, or RANAP over IP using the services of
+   SCTP.  Each of the applications using SUA has its own set of timing
+   requirements that can be found in its respective standards documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Coene & Pastor-Balbas        Informational                     [Page 18]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+   Possible configurations are showed in the pictures below.
+
+   - Interconnection of SS7 and IP:
+
+               ********         ***************        ********
+               * SEP  *   SS7   *             *   IP   *      *
+               *  or  *---------*     SG      *--------* ASP  *
+               * STP  *         *             *        *      *
+               ********         ***************        ********
+
+               +------                                 +------+
+               | SUAP |                                | SUAP |
+               +------+         +------+------+        +------+
+               | SCCP |         | SCCP | SUA  |        | SUA  |
+               +------+         +------+------+        +------+
+               |      |         |      |      |        |      |
+               | MTP3 |         | MTP3 | SCTP |        | SCTP |
+               |      |         |      |      |        |      |
+               +------+         +------+------+        +------+
+               | MTP2 |         | MTP2 |  IP  |        |  IP  |
+               +------+         +------+------+        +------+
+
+                 SUAP - SCCP/SUA User Protocol (TCAP, for example)
+                 STP  - SS7 Signalling Transfer Point
+
+                 Figure 13: SS7-IP Interworking using SUA
+
+   - IP Node to IP Node communication:
+
+                             ********        ********
+                             *      *   IP   *      *
+                             * IPSP *--------* IPSP *
+                             *      *        *      *
+                             ********        ********
+
+                             +------+        +------+
+                             | SUAP |        | SUAP |
+                             +------+        +------+
+                             | SUA  |        | SUA  |
+                             +------+        +------+
+                             | SCTP |        | SCTP |
+                             +------+        +------+
+                             |  IP  |        |  IP  |
+                             +------+        +------+
+
+                Figure 14: Intra-IP Communication using SUA
+
+
+
+
+
+Coene & Pastor-Balbas        Informational                     [Page 19]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+   IANA has registered SCTP Port Number 14001 for SUA.  It is
+   recommended that SGs use this SCTP port number for listening for new
+   connections.  The payload protocol identifier for the SCTP DATA
+   chunks is "4".
+
+5.  Security Considerations
+
+   UALs are designated to carry signalling messages for telephony
+   services.  As such, UALs 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.  Although some security needs overlap, any security
+   solution should fulfill all the different parties' needs.  See
+   specific Security Considerations in each UAL Technical specification
+   for details (for general security principles of SIGTRAN, see
+   [RFC3788]).
+
+   SCTP only tries to increase the availability of a network.  SCTP does
+   not contain any protocol mechanisms directly related to communication
+   security, i.e., user message authentication, integrity, or
+   confidentiality functions.  For such features, SCTP depends on
+   security protocols.  In the field of system security, SCTP includes
+   mechanisms for reducing the risk of blind denial-of-service attacks
+   as described in Section 11 of [RFC2960].
+
+   This document does not add any new components to the protocols
+   included in the discussion.  For secure use of the SIGTRAN protocols,
+   readers should go through the "Security Considerations for SIGTRAN
+   Protocols" [RFC3788]).  According to that document, the use of the
+   IPsec is the main requirement to secure SIGTRAN protocols in the
+   Internet, but Transport Layer Security (TLS) is also considered a
+   perfectly valid option for use in certain scenarios (see [RFC3436]
+   for more information on using TLS with SCTP).  Recommendations of
+   usage are also included.
+
+6.  Informative References
+
+   [ALLMAN99]  Allman, M. and V. Paxson, "On Estimating End-to-End
+               Network Path Properties", Proc. SIGCOMM'99, 1999.
+
+   [RFC2960]   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.
+
+   [RFC3257]   Coene, L., "Stream Control Transmission Protocol
+               Applicability Statement", RFC 3257, April 2002.
+
+
+
+
+Coene & Pastor-Balbas        Informational                     [Page 20]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+   [RFC2719]   Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene,
+               L., Lin, H., Juhasz, I., Holdrege, M., and C. Sharp,
+               "Framework Architecture for Signaling Transport", RFC
+               2719, October 1999.
+
+   [RFC3057]   Morneault, K., Rengasami, S., Kalla, M., and G.
+               Sidebottom, "ISDN Q.921-User Adaptation Layer", RFC 3057,
+               February 2001.
+
+   [RFC3331]   Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B.,
+               and J. Heitz, "Signaling System 7 (SS7) Message Transfer
+               Part 2 (MTP2) - User Adaptation Layer", RFC 3331,
+               September 2002.
+
+   [RFC3332]   Sidebottom, G., Morneault, K., and J. Pastor-Balbas,
+               "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3)
+               - User Adaptation Layer (M3UA)", RFC 3332, September
+               2002.
+
+   [RFC3436]   Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
+               Layer Security over Stream Control Transmission
+               Protocol", RFC 3436, December 2002.
+
+   [RFC3868]   Loughney, J., Sidebottom, G., Coene, L., Verwimp, G.,
+               Keller, J., and B. Bidulock, "Signalling Connection
+               Control Part User Adaptation Layer (SUA)", RFC 3868,
+               October 2004.
+
+   [RFC4165]   George, T., Dantu, R., Kalla, M., Schwarzbauer, H.J.,
+               Sidebottom, G., Morneault, K.,"SS7 MTP2-User Peer-to-Peer
+               Adaptation Layer", RFC 4165, September 2005.
+
+   [RFC3807]   Weilandt, E., Khanchandani, N., and S. Rao, "V5.2-User
+               Adaptation Layer (V5UA)", RFC 3807, June 2004.
+
+   [RFC4129]   Mukundan, R., Morneault, K., and N. Mangalpally, "Digital
+               Private Network Signaling System (DPNSS)/Digital Access
+               Signaling System 2 (DASS 2) Extensions to the IUA
+               Protocol", RFC 4129, September 2005.
+
+   [RFC3788]   Loughney, J., Tuexen, M., and J. Pastor-Balbas, "Security
+               Considerations for Signaling Transport (SIGTRAN)
+               Protocols", RFC 3788, June 2004.
+
+
+
+
+
+
+
+
+Coene & Pastor-Balbas        Informational                     [Page 21]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+Authors' Addresses
+
+   Lode Coene
+   Siemens
+   Atealaan 34
+   Herentals  B-2200
+   Belgium
+
+   Phone: +32-14-252081
+   EMail: lode.coene@siemens.com
+
+
+   Javier Pastor-Balbas
+   Ericsson
+   Via de los Poblados 13
+   Madrid  28033
+   Spain
+
+   Phone: +34 91 339 1397
+   EMail: J.Javier.Pastor@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Coene & Pastor-Balbas        Informational                     [Page 22]
+
+RFC 4166           Telephony Signalling over SCTP AS       February 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Coene & Pastor-Balbas        Informational                     [Page 23]
+