Overview

The current implementation of the IETF adapter layers in the EAGLE uses three adapter layers: SUA, M3UA, and M2PA. These adapter layers are assigned to SCTP associations which define the connection to the far end. An SCTP association is defined in the EAGLE by the local host name, the local SCTP port, the remote host name, and the remote SCTP port.

The three adapter layers used in the EAGLE are supported depending on the type of IP card being used for the IP connection. The SUA and M3UA adapter layers can be used only on IPGWx cards (cards running either the SS7IPGW or IPGWI applications). The M2PA adapter layer can be used only on IPLIMx cards (cards running either the IPLIM or IPLIMI applications).

SCTP associations on IPGWx cards use routing keys to distinguish between the IP devices being connected to. SCTP associations cannot be assigned directly to routing keys. To get an SCTP association ultimately assigned to a routing key, the IETF adapter layers use the concept of the application server (AS). The SCTP association is assigned to an application server. One or more associations are normally actively processing traffic. A group of associations (up to 16) can be assigned to an application server. An application server, a logical entity serving a specific routing key, is assigned to a routing key. This results in assigning the SCTP association, up to a maximum of 16, to a routing key.

The IETFSUA and M3UA adapter layers are supported on IPGWx cards. These adapter layers support the full implementation of the AS and routing key for the EAGLE. SCTP associations assigned to IPGWx cards can be assigned to application servers and routing keys.

The IETFM2PA adapter layer is supported on IPLIMx cards. The M2PA adapter layer does not support application servers, therefore SCTP associations assigned to M2PA links on IPLIMx cards cannot be assigned to application servers.

Figure 2-12 shows a typical configuration with four connections (SCTP associations) out of the EAGLE using IPGWx cards. Each association is connected to a process on the far end.

Figure 2-12 AS/Association Relationship

Feature Components

The EAGLE with IP⁷ Secure Gateway functionality is used as a signaling gateway between the PSTN and IP networks as shown in Figure 2-13. This figure shows that signaling gateways interface with media gateway controllers (MGCs) and MGCs interface with media gateways (MGs).

Figure 2-13 SG/MGC/MG Network Diagram

To provide a signaling gateway solution that will be able to communicate with a larger number of IP devices, the EAGLE needs to be able to communicate with multiple MGCs which are using SCTP as the transport layer and M3UA, M2PA, or SUA as an adapter layer. On an IPLIMx card, the M2PA adapter layer can be used with SCTP as shown in Figure 2-14. On an IPGWx card, the M3UA and SUA adapter layers can be used with SCTP as shown in Figure 2-15.

Figure 2-14 IPLIMx Protocol Stack with SCTP as the Transport Layer

Figure 2-15 IPGWx Protocol Stack with SCTP as the Transport Layer

SUA Layer

The SUA layer, only supported on IP cards running either the SS7IPGW or IPGWI applications (IPGWx cards), was designed to fit the need for the delivery of SCCP-user messages (MAP & CAP over TCAP, RANAP, etc.) and new third generation network protocol messages over IP between two signaling endpoints. Consideration is given for the transport from an SS7 signaling gateway to an IP signaling node (such as an IP-resident database). This protocol can also support transport of SCCP-user messages between two endpoints wholly contained within an IP network. The layer is expected to meet the following criteria:

• Support for transfer of SS7SCCP-User Part messages (for example, TCAP, RANAP, etc.)
• Support for SCCP connectionless service.
• Support for the seamless operation of SCCP-User protocol peers
• Support for the management of SCTP transport associations between a signaling gateway and one or more IP-based signaling nodes).
• Support for distributed IP-based signaling nodes.
• Support for the asynchronous reporting of status changes to management

Depending upon the SCCP-users supported, the SUA layer supports the four possible SCCP protocol classes transparently. The SCCP protocol classes are defined as follows:

• Protocol class 0 provides unordered transfer of SCCP-user messages in a connectionless manner.
• Protocol class 1 allows the SCCP-user to select the in-sequence delivery of SCCP-user messages in a connectionless manner.
• Protocol class 2 allows the bi-directional transfer of SCCP-user messages by setting up a temporary or permanent signaling connection.
• Protocol class 3 allows the features of protocol class 2 with the inclusion of flow control. Detection of message loss or mis-sequencing is included.

Protocol classes 0 and 1 make up the SCCP connectionless service. Protocol classes 2 and 3 make up the SCCP connection-oriented service.

The SUA layer supports the following SCCP network management functions:

• Coord Request
• Coord Indication
• Coord Response
• Coord Confirm
• State Request
• State Indication
• Pcstate Indication

The SUA layer provides interworking with SCCP management functions at the signaling gateway for seamless inter-operation between the SCN network and the IP network. This means:

• An indication to the SCCP-user at an application server process that a remote SS7 endpoint/peer is unreachable.
• An indication to the SCCP-user at an application server process that a remote SS7 endpoint/peer is reachable.
• Congestion indication to SCCP-user at an application server process.
• The initiation of an audit of remote SS7 endpoints at the signaling gateway.

M3UA Layer

The M3UA layer, supported on only IPGWx cards, was designed to fit the need for signaling protocol delivery from an SS7 signaling gateway to a media gateway controller (MGC) or IP-resident database. The layer is expected to meet the following criteria:

• Support for the transfer of all SS7MTP3-User Part messages (for example, ISUP, SCCP, TUP, etc.)
• Support for the seamless operation of MTP3-User protocol peers
• Support for the management of SCTP transport associations and traffic between a signaling gateway and one or more MGCs or IP-resident databases
• Support for MGC or IP-resident database process fail-over and load-sharing
• Support for the asynchronous reporting of status changes to management

The M3UA layer at an application server provides a set of primitives at its upper layer to the MTP3-Users that is the equivalent of those provided by the MTP Level 3 to its local users at an SS7 SEP. In this way, the ISUP or SCCP layer at an application server process is unaware that the expected MTP3 services are offered remotely from an MTP3 Layer at a signaling gateway, and not by a local MTP3 layer. The MTP3 layer at a signaling gateway may also be unaware that its local users are actually remote user parts over the M3UA layer. The M3UA layer extends access to the MTP3 layer services to a remote IP-based application. The M3UA layer does not provide the MTP3 services.

The M3UA layer provides the transport of MTP-TRANSFER primitives across an established SCTP association between a signaling gateway and an application server process and between IPSPs. The MTP-TRANSFER primitives are encoded as MTP3-User messages with attached MTP3 Routing Labels as described in the message format sections of the SCCP and ISUP recommendations. In this way, the SCCP and ISUP messages received from the SS7 network are not re-encoded into a different format for transport to or from the server processes. All the required MTP3 Routing Label information (OPC, DPC, and SIO) is available at the application server process and the IPSP as is expected by the MTP3-User protocol layer.

At the signaling gateway, the M3UA layer also provides inter-working with MTP3 management functions to support seamless operation of the signaling applications in the SS7 and IP domains. This includes:

• Providing an indication to MTP3-Users at an application server process that a remote destination in the SS7 network is not reachable.
• Providing an indication to MTP3-Users at an application server process that a remote destination in the SS7 network is now reachable.
• Providing an indication to MTP3-Users at an application server process that messages to a remote MTP3-User peer in the SS7 network are experiencing SS7 congestion
• Providing an indication to MTP3-Users at an application server process that a remote MTP3-User peer is unavailable.

The M3UA layer at the signaling gateway maintains the availability of all configured remote application server processes, in order to manage the SCTP Associations and the traffic between the signaling gateway and application server processes. As well, the Active/Inactive state of remote application server processes is also maintained - Active application server processes are those currently receiving traffic from the signaling gateway.

M2PA Layer

The M2PA layer, supported only on IPLIMx cards, is a peer-to-peer protocol and provides mappings for all SS7 messages. In a peer-to-peer mode, either side of the IP connection may initiate the connection.

The M2PA layer lies below MTP3 in the protocol stack. Figure 2-16 shows the protocol layers in three interconnected nodes involving the M2PA layer.

Figure 2-16 M2PA in the IP⁷ Signaling Gateway

The M2PA layer receives the primitives sent from MTP3 to its lower layer. The M2PA layer processes these primitives or maps them to appropriate primitives at the M2PA/SCTP interface. Likewise, the M2PA layer sends primitives to MTP3 like those used in the MTP3/MTP2 interface.

The M2PA layer provides MTP2 functionality that is not provided by SCTP. This includes:

• Reporting of link status changes to MTP3
• Processor outage procedure
• Link alignment procedure

The M2PA layer allows MTP3 to perform all of its Message Handling and Network Management functions with IPSPs as with other SS7 nodes.

The M2PA layer also supports full retrieval because it assigns sequence numbers to all protocol messages and provides for acknowledgements from the M2PA peer. This means that an M2PA signaling link is able to execute the Change-Over and Change-Back procedures. The M2PA layer makes use of the SS7 Extended Changeover (XCO) and SS7 Extended Changeover Acknowledgement (XCA) messages in order to communicate 24-bit sequence numbers with the peer.

SCTP

SCTP is a protocol designed to operate on top of a non-reliable protocol such as IP, while providing a reliable data delivery to the SCTP user. The SCTP protocol is designed to be a discrete protocol.

Although SCTP is similar in some respects to the Transport Control Protocol (TCP), it differs in several key areas. The two protocols are similar in that they both provide reliable data delivery over a non-reliable network protocol (IP). The SCTP protocol is a more robust and higher performance protocol than TCP.

Broader Definition of Connection Four-Tuple

The TCP protocol defines a connection via a four-tuple – a specific local IP address, local transport protocol port, a specific remote host IP address and remote transport protocol port. The TCP connection is point-to-point and once the session is established the four-tuple can not change. SCTP uses a similar four-tuple concept, but provides for the local and remote IP address values to be a list of IP addresses. SCTP allows a multi-homed host, with multiple network interfaces and more than one way to reach the far-end host, the capability to make use of this additional network connectivity to support the transport of data via the SCTP protocol. Redundancy through the support of multi-homing session end-points is a major SCTP advantage.

Multiple Streams

TCP is a point-to-point byte stream oriented transport protocol. In such a protocol if a single byte is corrupted or lost, then all data that follows must be queued and delayed from delivery to the application until the missing data is retransmitted and received to make the stream valid. With the TCP protocol, all data being transmitted is affected because there is only one path from end-to-end. The SCTP protocol addresses this limitation by providing the capability to specify more than one transport path between the two end-points. In SCTP, the four-tuple – with the multi-homing feature – defines what the SCTP protocol calls an association.

The association is composed of one or more uni-directional transport paths called streams. The number of inbound and outbound streams is independent of one another and is determined at session initiation time (for example, an association may be composed of three outbound and one inbound stream). In this scheme, a data retransmission only affects a single stream. If an association is defined with multiple streams and a packet is lost on a specific stream, data transmission on the other streams, which form this association, is not blocked. However, this feature is only beneficial if the upper layer application uses it.

In the EAGLE, a maximum of 2 inbound and 2 outbound streams can be defined for an association. Stream 0 in each direction is designated for Link Status messages. Stream 1 is designated for User Data messages. Separating the Link Status and User Data messages onto separate streams allows the adapter layer to prioritize the messages in a manner similar to MTP2. If the peer chooses to configure the association to have only one stream, then the signaling gateway will be able to use only stream 0 for both Link Status messages and User Data messages.

Datagram Stream

While TCP is implemented as a byte-oriented stream protocol, SCTP is based on a datagram-oriented protocol stream. By choosing the datagram as the smallest unit of transport, the SCTP protocol removes the need for the upper layer application to encode the length of a message as part of the message. An SCTP send results in the data being sent as a unit – a datagram – and received at the receiving node as a datagram.

Selective Acknowledgements

TCP acknowledgements are specified as the last consecutive byte in the byte stream that has been received. If a byte is dropped, the TCP protocol on the receiving side cannot pass inbound data to the user until the sender retransmits the lost byte; the stream is blocked. SCTP uses a feature known as selective acknowledgement in which each data chunk is identified by a chunk number – the Transmission Sequence Number (TSN) in SCTP terminology – and is explicitly acknowledged at a data chunk granularity. This means that if a data chunk is dropped, only that one data chunk needs to be retransmitted. In SCTP, a dropped data chunk only effects one stream, since ordered transmission of data is only enforced at the stream and not the association level.

Un-order Delivery Capability

The SCTP protocol provides a mechanism for un-ordered datagram delivery. This feature means that a datagram can be transmitted and received independent of datagram sequencing and thus not delayed while awaiting a retransmission. TCP does not provide an equivalent feature of this type.

Enhanced Security

The TCP protocol has a known and easily exploitable vulnerability to denial of service attacks (for example, SYN attacks). This weakness is due to the three-way handshake used by the TCP session-establishment protocol. The TCP session establishment method causes EAGLE resources to be committed prior to actually establishing the session. SCTP uses a four-way handshake where resources are not committed by the host being contacted until the contacting host confirms that it is actually making a contact request to prevent such attacks.

SCTP Connectivity Concepts

The basic connectivity provided by the SCTP protocol is illustrated by Figure 2-17:

Figure 2-17 SCTP Connectivity

Key elements of the SCTP connection include:

• SCTP Instance
• SCTP Endpoint
• SCTPAssociation
• SCTP Stream

An SCTP instance is defined by the local SCTP port number. Each local SCTP port number requires its own SCTP instance. An SCTP instance as an entity defines the various SCTP characteristics that will apply to “all” SCTP associations that are created as part of the SCTP instance. These include timeout values, maximum receive windows, and so forth.

In Figure 2-17 there are three hosts: SCTP node A, node B and node C. Node A has two SCTP instances: local SCTP port 2000 and 2100. Both node B and node C have a single SCTP instance, local SCTP port 3000 and 3000 respectively. The fact that both node B and C are using port 3000 does not tie them together in any way.

An SCTP endpoint is defined as the logical sender/receiver of SCTP packets. On a multi-homed host, an SCTP endpoint is represented to its peers as a combination of a set of eligible destination transport addresses to which SCTP packets can be sent and a set of eligible source transport addresses from which SCTP packets can be received. All transport addresses used by an SCTP endpoint must use the same port number, but can use multiple IP addresses. A transport address used by an SCTP endpoint must not be used by another SCTP endpoint. In other words, a transport address is unique to an SCTP endpoint.

The concept of SCTP instance clarifies this definition. In Figure 2-17, IP addresses are not shown, but to illustrate this definition, assume the following:

• Node A is multi-homed having two network interface cards with IP addresses 192.168.110.10 and 192.168.55.10
• Node B has a single network interface card with IP address of 192.168.110.20
• Node C is multi-homed having two network interface cards with IP addresses 192.168.110.30 and 192.168.55.30

Based on these IP addresses from above and the defined port numbers for Figure 2-17, there are four SCTP endpoints (Table 2-9).

Table 2-9 Sample SCTP Endpoints

Node	Local IP Address	Local SCTP Port
Node-1	192.168.110.10 192.168.55.10	2000
Node-1	192.168.110.10 192.168.55.10	2100
Node-2	192.168.110.20	3000
Node-3	192.168.110.30 192.168.55.30	3000

An SCTP association is defined as a protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state information including verification tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints must not have more than one SCTP association between them at any given time.

Based on this definition, given the endpoints listed above and Figure 2-17, there are three defined SCTP associations.

Table 2-10 Sample SCTP Associations

Association	Local IP Address	Local SCTP Port	Remote IP Address	Remote SCTP Port
Association-1	192.168.110.10 192.168.55.10	2000	192.168.110.20	3000
Association-2	192.168.110.10 192.168.55.10	2000	192.168.110.30 192.168.55.30	3000
Association-3	192.168.110.10 192.168.55.10	2100	192.168.110.30 192.168.55.30	3000

An SCTP stream is defined as a uni-directional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service.

Note:

The relationship between stream numbers in opposite directions is strictly a matter of how the applications use them. It is the responsibility of the SCTP user to create and manage these correlations if they are so desired.

Based on this definition and Figure 2-17, there are a total of seven streams for the three associations.

Table 2-11 Sample SCTP Associations

Association	Stream Number	Local IP Address	Local SCTP Port	Remote IP Address	Remote SCTP Port
Association-1	Stream 0 Out	192.168.110.10 192.168.55.10	2000	192.168.110.20	3000
Association-1	Stream 0 In	192.168.110.10 192.168.55.10	2000	192.168.110.20	3000
Association-2	Stream 0 Out	192.168.110.10 192.168.55.10	2000	192.168.110.30 192.168.55.30	3000
Association-2	Stream 1 Out	192.168.110.10 192.168.55.10	2000	192.168.110.30 192.168.55.30	3000
Association-2	Stream 0 In	192.168.110.10 192.168.55.10	2000	192.168.110.30 192.168.55.30	3000
Association-3	Stream 0 Out	192.168.110.10 192.168.55.10	2100	192.168.110.30 192.168.55.30	3000
Association-3	Stream 0 In	192.168.110.10 192.168.55.10	2100	192.168.110.30 192.168.55.30	3000