On the Use of SCTP in Failover-Scenarios

Transcription

1

2

3

4 On the Use of SCTP in Failover-Scenarios Andreas Jungmaier, Erwin P. Rathgeb Computer Networking Technology Group, IEM, University of Essen Ellernstr. 29, Essen, Germany Michael Tüxen ICN WN CC SE 7, Siemens AG, Hofmannstr. 51, Munich, Germany ABSTRACT The new general purpose transport protocol SCTP (Stream Control Transmission Protocol) has been developed for transport of signaling data, such as Signaling System No. 7 MTP level 2 or 3 user primitives, over IP networks. Since this application has especially high requirements towards the underlying transport protocol concerning reliability and fast recognition and recovery from failures, SCTP-based transmission must provide a high degree of network level fault tolerance. In our contribution we look at a typical link failure scenario in a multi-homed setup, and investigate two options for fast recovery from such an event, namely seamless SCTP switch-over, and a user level switch-over as has been suggested for the MTP Level 2 peer adaptation layer. Moreover, we will analyze necessary parameter settings for fast recovery from the failure situation. 1 Keywords: Transport Protocol, Stream Control Transmission Protocol, Failover, Signaling System No. 7, MTP Level 2 1. INTRODUCTION As a consequence of the steady growth of the integrated services digital network (ISDN) and the introduction of new cellular networks and services such as GPRS (General Packet Radio Service) and UMTS (Universal Mobile Telecommunications System) the underlying network infrastructures must provide enhanced support for voice, data and multimedia services. For useful and economically sound overall solutions, cooperation among ISDNbased, and newer, IP-based infrastructures is a key issue. The trend of convergence between these different technologies necessitates that signaling transport can also be provided via pure IP based networks with the required reliability and performance. Therefore, a corresponding protocol suite has been defined in the Signaling Transport (SIGTRAN) working group of the Internet Engineering Task Force (IETF). The basis of this suite is the Stream Control Transmission Protocol (SCTP), an end-to-end protocol for reliable data transport via IP networks. On top of this protocol, a number of adaptation layers have been defined for transport of Signaling System No. 7 primitives (cf. section 2.). 1 Acknowledgement: This work was partially funded by the Bundesministerium für Bildung und Forschung (BMBF) of the Federal Republic of Germany (Förderkennzeichen 1AK45). The authors alone are responsible for the content of the paper. 2. THE SIGNALING SYSTEM NO. 7 The ISDN protocol reference model separates the functions used for user data transfer (User Plane) from those used for controlling the network and the user data channels (Control Plane). To exchange signalling information between the user terminals and the local exchange, the Digital Subscriber Signaling System No. 1 (DSS1) is used, whereas the transfer of signaling information among the switches within the network is performed by using the Signaling System No. 7 (SS7)[5]. This architecture leads to the definition of logically separate networks for user data (typically 64 kbit/s channels) and for signaling information (packet oriented). Figure 1 shows the basic protocol architecture of a SS7 network. The functions related to the transfer of signaling messages are handled by the Message Transfer Part (MTP) protocols [6]. The MTP Level 1 (MTP1) provides signalling data link functions typical for OSI layer 1. MTP Level 2 (MTP2) provides a HDLClike data link protocol (OSI layer 2) with enhancements related to fast discovery of link failures and reliability. MTP Level 3 (MTP3) provides a simple packet oriented connectionless service a subset of OSI layer 3 and management function for the signaling network and its links. The basic transfer capability of the MTP is used by various user parts implementing functions of the OSI layers 4 to 7, one of which is the ISDN User Part (ISUP) that manages circuit switched ISDN user connections. The Signaling Control Connection Control Part (SCCP) extends the MTP to the full functionality of an OSI NSAP (Network Service Access Point) by providing, e.g. a connection oriented service. SCCP is commonly used in combination with the so-called Transaction Capabilities (TC) in order to provide transaction oriented services to various applications, including System Management (SMAP), mobility management for cellular networks, or the Intelligent Network (IN). 2.1 LINKSETS The nodes in the SS7 network are called signaling points (SP) and are connected by signaling links, the bandwidth of which is typically 64 kbit/s. There can be up to 16 links that may be used between any two SPs which is referred to as a linkset. This is done for two reasons: 1. Multiple links in a linkset may be used to provide the necessary bandwidth by using a loadsharing algorithm. For a detailed discussion of this topic see [4]. 363

5 7 4,5, OSI Layer Appl. for Mobility Managem. and IN ASEs TCAP ISP SMAP OMAP SCCP TC Signaling Network Functions Signaling Link Functions Signaling Data Link Functions Application Programs for Call Control ISUP MTP Other User Parts CCS7 Level Terminology OSI Open Systems Interconnection CCS7 Common Channel Signaling System No.7 MTP Message Transfer Part SCCP Signaling Connection Control Part TC Transaction Capabilities ISP Intermediate Service Part TCAP Transaction Capabilities Application Part ASE Application Service Element OMAP Operation,Maintenance & Administration Part SMAP Systems Management Application Process Figure 1: SS7 protocol architecture 2. Multiple links may be used to provide redundancy. If one link fails, the traffic is distributed to the other links in the linkset. This contribution will focus on the second aspect. If, in a linkset with two links, one link fails, the following actions take place: 1. MTP2 of the the failed link informs MTP3 of the SP about failure. 2. MTP3 of the SP recovers all messages from MTP2 of the failed link which have not been successfully delivered to the peer SP. 3. MTP3 of the SP resends all those messages to the peer using the second link. This procedure is called change-over and is designed to minimize packet loss and missequencing of signalling messages in case of a link failure. [7] requires that the change-over procedure does take no longer than 8 ms. 2.2 RELIABILITY REQUIREMENTS OF SS7 NETWORKS An SS7 network is the most sensitive part of the ISDN network and, therefore, has to fulfill strict reliability requirements. These are specified in [7] and include the following: Not more than one in 1 7 messages may be lost due to failure in the MTP. Not more than one in 1 1 messages may be delivered outof-sequence to the user parts due to failure in the MTP. This also includes duplication of messages. The availability of any signaling relation (i.e. between SPs that originate and consume signaling messages) has to be at least corresponding to a downtime of at most 1 minutes/year. 3. IP-BASED SIGNALING TRANSPORT The Signaling Transport working group of the IETF has described the general architecture of IP-based signaling transport in [2]. In these scenarios messages of different MTP levels are transported via an adapation layer (specific to the concerned MTP level) on top of a SCTP association. Most of these SCTP adaptation layers provide the ability to connect IP-based devices running only upper layers of the SS7 protocol stack to the SS7 network. These devices are connected to so called Signaling Gateways (SGs) which are connected to both the SS7 network and an IP-based network. A Signaling Gateway runs the lower layers of the SS7 protocol stack. These solutions are typically asymmetric. 3.1 SS7 MTP2 PEER ADAPTATION LAYER The SS7 MTP2 Peer Adapation Layer (M2PA) currently being defined in [3] provides an IP-based signaling link. There is no strict bandwidth limitation like in the case of typical (narrowband) signaling links. Therefore M2PA conveniently provides broadband IP-based signaling links, used in a symmetric way. Figure 2 shows the protocol stacks involved in a M2PA architecture between two Signaling Gateways. Signaling Gateway MTP 2 MTP 1 SS7 network M2PA SCTP IP IP based network Signaling Gateway MTP 3 MTP 3 M2PA SCTP IP MTP 2 MTP 1 SS7 network Figure 2: Protocol stacks used for M2PA based communication 364

6 3.2 THE STREAM CONTROL TRANSMISSION PROTOCOL SCTP, as defined in [1], is a message-oriented, reliable transport protocol, explicitly supporting multi-homed endpoints, i.e. endpoints with more than one IP address. Contrary to TCP, the SCTP send- and receive-primitives will preserve message boundaries. The protocol can multiplex several short messages into one SCTP packet, which is subsequently transmitted as payload of one IP packet. SCTP provides its user with a very flexible method of data delivery by separating the reliable transfer of messages between endpoints (ensured by proper use of transmission sequence numbers, acknowledgements and retransmission timers) from the actual delivery to the user process which is performed in so-called streams. Streams refer to a sequence of messages usually delivered in order. This is achieved at the cost of having additional stream sequence numbers used for this end. Due to the complex effects of multi-homing and routing, the multi-homing feature as such neither guarantees the reachability of an endpoint nor does it guarantee a higher availabilty in case of network failures. In a carefully engineered network setup however, or in an internet setting with connectivity to more than one internet service provider (ISP), a protocol supporting multihoming greatly improves network level fault tolerance. 3.3 PATH AND PEER MONITORING For an SCTP endpoint, the notion of a path is equal to that of one peer destination address. By default, SCTP endpoints monitor the reachability of their peers as well as availability of each path to the peer by regularly sending heartbeat messages to all of the destination addresses of the peer endpoint. Upon reception of such a message, an endpoint is bound to reply with a heartbeat acknowledgment message. An SCTP endpoint keeps track of the number of consecutive retransmissions of data or heartbeat messages sent to the peer endpoint (increasing the association error counter), respectively to each path (increasing the respective path error counter). Each time a chunk is acknowledged, the relevant counter is cleared. Once it exceeds an error limit, the peer endpoint or the concerned path is considered unavailable. association uses multi-homed hosts. In case of network failures the built-in features of SCTP will be used to handle the failure. 2. Two SCTP associations will be used and the MTP3 has two links. The normal change-over procedure is used in case of network failures, and M2PA relies on its upper layer for providing redundancy. Thus, the SCTP associations need not provide redundancy, and are single-homed. 4.1 DESCRIPTION OF THE LAB SETUP We investigated the parameters for optimizing the change-over behaviour in a lab environment where an SCTP user application mimicks MTP3 by generating traffic and reacting to a link failure accordingly. Endpoint A sends data to endpoint B and the link carrying the main data load experiences a link failure. One scenario, motivated by section 3., uses one dual-homed SCTP association (see also fig. 4) while the other uses two distinct, singlehomed associations (cf. scenario 2, fig. 5). Both endpoints are connected by a router equipped with a WAN emulator, that emulates link delays between IP address A1 and B1, A2 and B2 respectively, of 1 ms, and a bandwidth restriction for these links of 2.48 MBit/s. The SCTP user application generates an exponentially distributed traffic pattern with a mean message arrival rate of 1 messages of 5 bytes length per second. Furthermore, it reacts to link failures accordingly. These parameters were chosen to emulate an environment where an IP/SCTP/M2PA-based signaling endpoint is connected to a signaling gateway that is not located far away from the SEP (say less than 1 km). For a simple IP network with few hops, the chosen link delay time is then appropriate. The presented results are based on a prototype SCTP implementation that has been realized in cooperation between the University of Essen and Siemens AG, Munich and is freely available under the GNU Public License from FAILOVER WITH MULTI-HOMING Association 1 Path PATH SELECTION IP A1 IP B1 In a multi-homed SCTP association, one path is selected as the primary path and carries the main load of the user data transmission. Other paths are only used for data retransmissions and heartbeat messages. Should the primary path become unreachable, an endpoint may send data to another, active address and report that failure to its user which can subsequently choose a new primary path. 4. INVESTIGATION OF FAILOVER SCENARIOS In section 2.1 it was noted that multiple links provide the necessary redundancy required for SS7 networks. The same requirements have to be fulfilled by M2PA-based communication. For M2PA there are two ways to provide redundancy: 1. The MTP3 has only one link, and the M2PA relies on its lower layer for providing redundancy. Therefore, one SCTP IP A2 WAN Emulator Association 1 Path 2 IP B2 Figure 4: Investigated scenario 1 - one dual-homed association At the time of failure, the SCTP protocol will experience transmission timer timeout events, and retransmit data onto the second path. New data will be transmitted to the failed path, and after a while be retransmitted on the second. After the error counter for the failed path has been exceeded, the path is reported unreachable and the user makes the second path new primary. At that time, retransmissions and new transmissions will use the second 365

7 7 6 Message Delays: Absolute Values and Moving Average (RTOmin 4ms, PRL=4, RTOmax 2ms) Moving Average (1 values) Single Messages 7 6 Message Delays: Absolute Values and Moving Average (RTOmin 4ms, PRL=4, RTOmax 2ms) Moving Average (1 values) Single Messages Message Delay [ms] Message Delay [ms] Time (ms) Time (ms) Figure 3: Typical failover behaviour in scenarios 1 and 2 path, and the data that has queued up will be transmitted until the queue has emptied. At that time the failover procedure has completed. 4.3 FAILOVER WITH MULTIPLE ASSOCIATIONS IP A1 IP A2 Association 1 WAN Emulator Association 2 IP B1 IP B2 Figure 5: Investigated scenario 2 - two associations At the time of link-failure, the SCTP user application keeps transmitting data onto Association 1 (corresponding to link 1), while Association 2 (corresponding to link 2) is idle. As soon as the retransmission timer timeout event occurs, unacknowledged data will be retransmitted onto the failed link 1, and a new retransmission timer is started. After a few retransmissions, the error counter exceeds the association limit and an association failure is announced to the application. During that time, the second association is not used for retransmissions in this scenario. Then the application will retrieve all data chunks that were not acknowledged or transmitted, and send them again onto Association 2. Thus, the failover is performed from Association 1 to Association RELEVANT PROTOCOL PARAMETERS The SCTP parameters that influence the protocol behaviour in the above scenarios are the following: 1. RTO max, the maximum time for a retransmission timer timeout. 2. RTO min, the minimum time for a retransmission timer timeout. 3. RTO init, the initial value for RTO (before any measurement of a round-trip time has been performed. 4. ARL, the association retransmission limit. The first timeout after ARL consecutive retransmissions without any acknowledgement will cause the association to fail. 5. PRL, the path retransmission limit. The first timeout on a path after PRL consecutive retransmission to this path without an acknowledgement will cause the path to be announced unreachable. 6. The SACK delay, that determines the maximum time the receiver waits before an acknowledgement for a chunk is sent. After reception of two consecutive chunks, a receiver will stop a running SACK timer, and send an acknowledgment at once. The RFC 296 [1] recommends default values suitable for SCTP deployment in the public internet: Parameter Value RTO min 1 sec RTO max 6 sec RTO init 3 sec ARL 1 PRL 5 SACK delay 2 msec These parameters, however, will yield poor performance in the described scenarios and are not adapted to signaling transport requirements, since it takes at least = 63 seconds in our scenarios before the path failure (and in scenario 2 subsequently the association failure) is announced to the application. Then, all the queued data must be retransmitted which yields unacceptable performance for signalling data transport. 4.5 RESULTS Here we will determine what parameter settings are necessary so that in the described scenarios the requirements of [7] are met, 366

8 ms Limit Failover Duration (PRL=2) Failover Duration (PRL=3) Failover Duration (PRL=4) Failover Duration (PRL=5) ms Limit Failover Duration (ARL=2) Failover Duration (ARL=3) Failover Duration (ARL=4) Failover Duration (ARL=5) Figure 6: Absolute duration of failover in scenarios 1 and 2 (RTO min = 4ms) 12 1 ms limit Max. Message Delay (PRL=2) Max. Message Delay (PRL=3) Max. Message Delay (PRL=4) Max. Message Delay (PRL=5) 12 1 ms limit Max. Message Delay (ARL=2) Max. Message Delay (ARL=3) Max. Message Delay (ARL=4) Max. Message Delay (ARL=5) Figure 7: Maximum message delay during the failover (scenarios 1 and 2, RTO min = 4ms) namely the failover time be limited to 8 ms. In order to further judge the system behaviour, we also looked at individual (i.e. maximum) and average delays of messages during the failover procedure. The figures 6, 7 and 8 all show confidence intervals of 99% SCENARIO 1 - A DUAL-HOMED ASSOCIATION After the primary path failure, the receiver gets the first data chunks by sender retransmission on the second path. The sender keeps transmitting new chunks over the primary path until another retransmission timeout occurs. Figure 3 displays the effects of this behaviour in an example. Queued messages that are retransmitted have a decreasing delay, and for after each retransmission event new chunks queue up. After the failure has been recognized, all chunks are being transmitted directly over the second path, and the original state is achieved when the queue is emptied again. Figure 7 shows that the maximum delays grow strongly if a large number of chunks queue up, which effectively happens when the time for recognizing the link failure is high (as for PRL=5, RTO max=2ms, 25ms). For most of the tested parameters the maximum message delay was well below ms, and the average delay of messages during the failover below 2 ms SCENARIO 2 - TWO SINGLE-HOMED ASSOCIATIONS As figure 3 shows nicely, after the path failure no chunks are received until after the link and association failure have been announced. Then all chunks are sent on the second association where the send queue empties quickly, until the average delay of the chunks is back to normal. Figure 7 shows the maximum message delay for scenario 2. The maximum message delay depends on the time at which the sender determines that the path and consequently the association has failed. For low values of RTO max that is typically slightly lower than ARL RTO max. For ARL=2, the delay does not depend on RTO max, since the failure is recognized, before the actual RTO value has reached the maximum value. Note that for most of the tested parameters the maximum message delay higher than ms, and the average delay of messages higher than 2 ms. 367

9 1 12 8ms Limit Failover Duration (RTOmin = 2 ms, PRL=4) Failover Duration (RTOmin = 4 ms, PRL=4) Failover Duration (RTOmin = 6 ms, PRL=4) Max. Message Delay (RTOmin = 2 ms, PRL=4) Max. Message Delay (RTOmin = 4 ms, PRL=4) Max. Message Delay (RTOmin = 6 ms, PRL=4) Figure 8: Effects of changing the RTO min parameter: Failover Duration and Maximum Message Delay (Scenario 1) A COMPARISON OF BOTH SCENARIOS On the whole, both scenarios can be used to realize sufficiently fast recovery from a path failure (cf. figure 6). However there are some distinctions between the two: scenario 1 always allows a smoother transition in that it keeps the average delay per chunk during the failover period much lower than scenario 2 (often less than 5%) due to early and successful retransmissions over the second path. Scenario 1 also allows for a sufficiently fast failover within the mandatory 8 ms for a wider range of parameter settings, and is therefore recommended. SCTP protocol mechanisms may cause a slightly later recognition of the path failure in scenario 1 since the retransmission timer for the failed path 1 is only started again when new data is transmitted on this (primary) path. All retransmissions successfully use the secondary path, where the retransmission timer is stopped, then. In scenario 2 the retransmission timer is restarted directly after expiry, since all retransmissions use the same - failed - path. Nonetheless, the early and successful retransmission over a secondary path improves the failover behaviour compared to scenario 2. In our experiments we found that for all relevant parameter settings (with an overall recovery time lower than 8 ms), scenario 1 had a faster overall recovery compared to scenario EFFECTS OF THE MINIMUM RTO Figure 8 shows that by lowering the RTO min parameter the failover times as well the maximum message delays can be further reduced. However, with very low values of RTO min associations may become more susceptible to early, unwanted retransmission timer timeouts, and thus retransmissions. With very low PRL values this may even result in use of the secondary path before any actual failure has occurred, so it is generally not recommended to lower the RTO min parameter below RTO min,rec = 2 RTT. These spurious timeouts must also be avoided since they have a negative effect on the protocol throughput. 5. OUTLOOK AND FURTHER WORK In this contribution we compared two options for handling link failures where SCTP is used as transport protocol for IP based signaling data transmission. We identified and assessed valid SCTP parameter settings that make the investigated systems comply with requirements for signaling transport within traditional signaling networks. Thus we found that in a carefully setup environment the performance of IP/SCTP/M2PA based signaling transport is sufficient for transport of MTP3 primitives from a Signaling System No. 7 network. Imperative for this is an early recognition of a path failure, so that queueing of large number of messages is avoided, and a fast recovery can be achieved. To systematically investigate a larger set of parameters, simulative studies are being prepaired that will allow a more detailed analysis of optimal parameters for different and more complex IP-based networks. REFERENCES [1] R. Stewart, Q. Xie et al.: RFC Stream Control Transmission Protocol, IETF, Network Working Group, October 2. [2] L. Ong, I. Rytina, M. Garcia et al.: RFC Framework Architecture for Signaling Transport, IETF, Network Working Group, October [3] T. George et al.: SS7 MTP2-User Peer-to-Peer Adaptation Layer, draft-ietf-sigtran-m2pa-3.txt, Internet Draft, Work in Progress, July 21. [4] K. D. Gradischnig, St. Krämer, M. Tüxen: Loadsharing A key to the reliability of SS7-networks, DRCN 2. [5] ITU-T Recommendation Q.7: Introduction to CCITT Signalling System No. 7, International Telecommunication Union, Geneva, March [6] ITU-T Recommendation Q.71: Functional description of the message transfer part (MTP) of Signalling System No. 7, International Telecommunication Union, Geneva, March [7] ITU-T Recommendation Q.76: Signalling System No. 7 Message Transfer Part Signalling Performance, International Telecommunication Union, Geneva, March