SigTran

There has been interest in interworking SS7 and IP for quite some time. However, the initial solutions were proprietary. This began to change in the late 1990s, when an effort to standardize Switched Circuit Network (SCN) signaling (SS7) over IP transport began in the IETF.

The IETF SigTran Working Group was founded after a Birds of a Feather (BOF) session, which was held at the Chicago 1998 IETF meeting, to discuss transport of telephony signaling over packet networks. The result of the BOF was the creation of the SigTran Working Group to do the following:

• Define architectural and performance requirements for transporting SCN signaling over IP.

• Evaluate existing transport protocols, and, if necessary, define a new transport protocol to meet the needs and requirements of transporting SCN signaling.

• Define methods of encapsulating the various SCN signaling protocols.

The SigTran Working Group first met at the Orlando 1998 IETF meeting.

The SigTran Working Group defined the framework architecture and performance requirements in RFC 2719 [126]. The framework included the concept of reconstructing the traditional circuit switch into MGC, MG, and SG elements, thereby separating the signaling and the media control plane.

The framework document identified three necessary components for the SigTran protocol stack:

• A set of adaptation layers that support the primitives of SCN telephony signaling protocols

• A common signaling transport protocol that meets the requirements of transporting telephony signaling

• IP [127] network protocol

Figure 14-2 shows the three layers of the protocol stack.

Further functional requirements were defined for the transport protocol and adaptation layers. The transport had to be independent of the telephony protocol it carried, and, more importantly, had to meet the stringent timing and reliability requirements of that telephony protocol.

The Working Group began evaluating the two commonly used transport protocols, User Datagram Protocol (UDP) [128] and Transport Control Protocol (TCP) [129], against these requirements. UDP was quickly ruled out because it did not meet the basic requirements for reliable, in-order transport. While TCP met the basic requirements, it was found to have several limitations. A team of engineers from Telcordia (formerly Bellcore) completed an analysis of TCP against SS7's performance and reliability requirements. Their analysis was documented in an IETF draft [130], which introduced the following limitations of TCP:

• Head-of-line blocking— Because TCP delivery is strictly sequential, a single packet loss can cause subsequent packets to also be delayed. The analysis showed that a 1% packet loss would cause 9% of the packets being delayed greater than the one-way delay time.

• Timer granularity— While this is not a limitation of the TCP protocol, it is a limitation of most implementations of TCP. The retransmission timer is often large (typically one second) and is not tunable.

The Working Group noted additional TCP limitations, including the following:

• A lack of built-in support for multihoming. This support is necessary for meeting reliability requirements, such as five 9s and no single point of failure.

• Also, because of a timer granularity issue and the lack of a built-in heartbeat mechanism, it takes a long time to detect failure (such as a network failure) in a TCP connection.

Because of the deficiencies of UDP and TCP, a new transport protocol, Stream Control Transmission Protocol (SCTP) [131], was developed for transporting SCN signaling. Note that SCTP is a generic transport that can be used for other applications equally well.

Stream Control Transmission Protocol (SCTP)

The SigTran Working Group presented several proposals for a new transport protocol. One proposal was Multinetwork Datagram Transmission Protocol (MDTP), which became the foundation for SCTP. RFCNext Generation Network2960 defines SCTP, which has been updated with RFC 3309 [132] to replace the checksum mechanism with a 32-bit CRC mechanism. Further, there is an SCTP Implementers Guide [133] that contains corrections and clarifications to RFC 2960.

SCTP provides the following features:

• Acknowledged error-free, nonduplicated transfer of user data

• Data segmentation to conform to path MTU size (dynamically assigned)

• Ordered (sequential) delivery of user messages on a per "stream" basis

• Option for unordered delivery of user messages

• Network-level fault tolerance through the support of multihoming

• Explicit indications of application protocol in the user message

• Congestion avoidance behavior, similar to TCP

• Bundling and fragmenting of user data

• Protection against blind denial of service and blind masquerade attacks

• Graceful termination of association

• Heartbeat mechanism, which provides continuous monitoring of reachability

SCTP is a connection-oriented protocol. Each end of the connection is a SCTP endpoint. An endpoint is defined by the SCTP transport address, which consists of one or more IP addresses and an SCTP port. The two endpoints pass state information in an initialization procedure to create an SCTP association. After the association has been created, user data can be passed. Figure 14-3 provides an example of two SCTP endpoints in an association.

In Figure 14-3, Host A has endpoint [10.82.82.4, 10.82.83.4 : 2905] and Host B has endpoint [10.82.82.24, 10.82.83.24 : 2905]. The association is the combination of the two endpoints.

The following sections discuss how SCTP addresses the deficiencies of TCP that are related to meeting the requirements for delivering telephony signaling over IP. For additional details about the internals of SCTP, the Stream Control Transmission Protocol, A Reference Guide, by Randall Stewart and Qiaobing Xie, is a good resource.

Head-of-Line Blocking

SCTP uses streams as a means of decreasing the impact of head-of-line blocking. In SCTP, a stream is a unidirectional channel within an association. Streams provide the ability to send separate sequences of ordered messages that are independent of one another.

Figure 14-4 provides an example of head-of-line blocking with TCP. When packet 2 is dropped, packets 3 to 5 cannot be delivered to the application because TCP provides in-order delivery.

SCTP provides the ability to have multiple streams within an association. Each stream provides reliable delivery of ordered messages that are independent of other streams. Figure 14-5 shows an example of how SCTP can help resolve head-of-line blocking. In this example, packet 2 is dropped again. However, because packets 3, 4, and 5 belong to a different stream, they can be delivered to the application without delay.

Failure Detection

Quick failure detection and recovery is important for meeting the performance and reliability requirements that are specified for transporting SCN signaling. For a multihomed host, two types of failures can occur:

• One or more destination addresses in the peer endpoint become unavailable or unreachable.

• The peer endpoint becomes unavailable or unreachable.

A destination address can become unreachable for one of several reasons. First, there could be a failure in the network path to the destination address, or a failure in the Network Interface Card (NIC) that supports the destination address. Likewise, a peer endpoint can become unavailable for several reasons. By definition, the peer endpoint is unavailable or unreachable if all of its destination addresses are unavailable or unreachable. SCTP provides two mechanisms for detecting failures:

When an endpoint sends a data message to a particular destination address, an acknowledgement is expected in return. If the acknowledgement has not been received when the retransmission timer expires, SCTP increases an error counter for that destination address and then retransmits the data message to the same destination or to another destination address, if one is available. The destination address is considered unreachable if the error counter reaches a defined threshold (Path.Max.Retrans).

The other mechanism for detecting failures is a heartbeat mechanism. This mechanism is useful for monitoring idle destination addresses, such as a destination address that has not received a data within the heartbeat period. The heartbeat is sent periodically, based on a configured heartbeat timer. If a heartbeat response is not received, the same error counter is increased. Again, when the error counter reaches a defined threshold (Path.Max.Retrans), the destination address is considered unavailable or unreachable.

To determine the availability of the peer endpoint, an error counter is kept for the peer endpoint. This error counter represents the number of consecutive times the retransmission timer has expired. It is also increased each time a heartbeat is not acknowledged. When this error counter reaches a defined threshold (Association.Max.Retrans), the peer endpoint is considered unavailable or unreachable.

SCTP enables faster failure detection by encouraging implementations to support tunable parameters. As noted, TCP is limited in this respect because most implementations do not allow the application to tune key TCP parameters. SCTP encourages an implementation to support tunable parameters through the definition of the upper-layer interface to the application. In RFC 2960, Section 10 contains an example that describes the upper-layer interface definition. One function in this definition, SETPROTOCOLPARAMETERS(), provides a means setoff-setting parameters such as minRTO, maxRTO, and maxPathRetrans. More importantly, the SCTP sockets Application Programmer Interface (API) [134] defines a socket option (SCTP_RTOINFO) for setting key parameters.

Multihoming and Failure Recovery

Multihoming provides a means for path level redundancy. This feature enables SCTP endpoints to support multiple transport addresses. Each transport address is equivalent to a different path for sending and receiving data through the network. Figure 14-6 shows an example of multihoming.

In the case of multihoming, one network path is selected as the primary path. Data is transmitted on the primary path while that path is available. If a packet gets dropped—for instance, because of a failure in the path—the retransmission should be sent on the alternate path. Figure 14-7 provides an example based on the diagram in Figure 14-6, with the primary path between IP1 and IP3 (the 10.82.82.x network) and the alternate path between IP2 and IP4 (the 10.82.83.x network). In this example, the packet with Transmission Sequence Number (TSN) 1 is retransmitted on the alternate path.

Retransmitting on the alternate path decreases failure recovery time. Further, if the primary path fails, the alternate path is automatically selected as the primary path. The path failure recovery mechanism is completely transparent to the application that uses SCTP.

Proposed Additions

The IETF Transport Working Group proposes two promising additions to the SCTP protocol:

• Dynamic Address Reconfiguration [135]

• Partial Reliability [136]

The first proposal is to allow for IP address information reconfiguration on an existing association. This feature can be useful for hardware that provides for hot swap of an Ethernet card, for example. A new Ethernet card could be added and the Ethernet card's IP address could then be added to the association without requiring system downtime.

The second proposal allows for partially reliable transport on a per message basis. In other words, the application can determine how a message should be treated if it needs to be retransmitted. For instance, the application can decide that a message is stale and no longer useful if it has not been delivered for two seconds. SCTP then moves past that message and stops retransmitting it.