Simulation of the SCTP Failover Mechanism

Transcription

1 Simulation of the SCTP Failover Mechanism M Minnaar, DW Ngwenya, and WT Penzhorn Telkom, NNOC Tier 2 University of Pretoria, South Africa University of Pretoria, South Africa minnaarm@telkom.co.za; dumisa.ngwenya@eng.up.ac.za; walter.penzhorn@eng.up.ac.za Abstract: Some features of SCTP provide opportunities for creating redundancies for signalling over IP networks. This paper presents the behaviour of SCTP in failover scenarios, based on literature review and simulations. Simulations were carried out using NS2 in a multi-homing environment. It was found, as expected, that when failover took place, the undelivered chunks were retransmitted to the secondary path while new messages were still transmitted to the primary path until the error count was exceeded whereupon the primary path was declared inactive and a new primary path was chosen. The simulations raised some concerns regarding the duration of failover for different PRL values. * Keywords: SCTP, Failover, Multi-homing. I. INTRODUCTION The communication industry is going though a period of explosive change that is both enabling and driving the convergence of services. IP is considered the most promising media on which to build the new integrated services. There is an ongoing integration of the PSTN and IP networks. Signalling in the PSTN uses the SS7 network. SS7 places high demands on underlying transport protocol to enable reliability and fast recovery from failures. To maintain the same robustness for converged networks as there is for the PSTN it is necessary to have a robust signalling system over IP. In the past several proprietary solutions for transporting signalling traffic over IP have appeared. As the interest in signalling over IP grew, it was generally agreed that both TCP and UDP was unsuitable transport protocols. In 1999 the IETF Signalling Transport (SIGTRAN) group was formed to standardize a suitable transport protocol for signalling traffic over IP. Today SCTP is being seen as the preferred protocol to transport of SS7 MTP primitives for signalling over IP Essentially, SCTP is a reliable message-oriented data transport protocol operating on top of a potentially unreliable connectionless packet service such as IP. It allows SS7 messages to be transported over an IP infrastructure by offering acknowledged error-free nonduplicated transfer of datagram. The objective of this study was to gather information on SCTP and carry out simulations on failover scenarios * This paper has been sponsored by Unisys South Africa to validate SCTP failover mechanisms. This study forms a basis for further work on SCTP and for development of innovative and more robust algorithms for congestion control, adaptive failover, and multi-homed s for redundancy. Section II describes SCTP packets and gives an overview of features of SCTP that were important for simulations carried out in this study. Comparison of TCP and SCTP is also presented. Section III outlines some literature results on the subject. Experimental setup and results of simulations carried out in this study are described in section IV. II. OVERVIEW OF SCTP A. SCTP Packets A SCTP packet is composed of a common header and several chunks multiplexed into one packet. A chunk may contain either control information or user data. Figure 1 shows a SCTP packet with several chunks. Each chunk begins with a chunk type field, which is used to distinguish data chunks and different types of control chunks, followed by chunk specific flags and a chunk length field needed because chunks have a variable length. The value field contains the actual payload of the chunk. Type Source Port Flags Verification Tag Checksum Destination Port Length Type Flags Length SCTP Common Header Chunk 1 Chunk N Figure 1: An SCTP packet format There are thirteen different chunk types described in the RFC 296 as follows: Payload Data (DATA) Initiation (INIT) - used to initiate a SCTP association between two endpoints. Initiation Acknowledgement (INIT ACK) - used to acknowledge the initiation of an SCTP association.

2 Selective Acknowledgement (SACK) - sent to a peer endpoint to acknowledge received DATA chunks and to inform the peer endpoint of gaps in the received subsequences of DATA chunks as represented by their Transmission Sequence Numbers (TSNs). Heartbeat Request (HEARTBEAT) - send this chunk to a peer endpoint to probe the reachability of a particular destination transport address defined in the present association. Heartbeat Acknowledgement (HEARTBEAT ACK) - send this chunk to its peer endpoint as a response to a HEARTBEAT chunk. Abort (ABORT) - sent to the peer of an association to close the association. Shutdown (SHUTDOWN) - used to initiate a graceful close of the association with its peer. Shutdown Acknowledgement (SHUTDOWN ACK) - used to acknowledge the receipt of the SHUTDOWN chunk at the completion of the shutdown process. Operation Error (ERROR) - endpoint sends this chunk to its peer endpoint to notify it of certain error conditions. State Cookie (COOKIE ECHO) - sent by the initiator of an association to its peer to complete the initialization process. Cookie Acknowledgement (COOKIE ACK) - used to acknowledge the receipt of a COOKIE ECHO chunk. Shutdown Complete (SHUTDOWN COMPLETE) - used to acknowledge the receipt of the SHUTDOWN ACK chunk at the completion of the shutdown process. B. SCTP core features Multi-streaming, association, and multi-homing are features of SCTP that make it superior to other transport protocols, such as TCP. Multi-streaming and association With SCTP data is partitioned into multiple streams that have the property of being delivered independently. In this way SCTP creates independence between data transmission and data delivery. Each DATA chunk in the protocol uses two sets of sequence numbers, a TSN (Transmission Sequence Number) that governs the transmission of messages and the detection of message loss, and the Stream ID or Stream Sequence Number (SSN) pair, which is used to determine the sequence of delivery of received data. The delivery of one stream does not affect the delivery another stream. On the other hand lossy links and, hence, congestion in links can be determined and reliable transfer of data is achieved. Streaming between two hosts takes place in the context of association. Within an association data chunks belong to a specific stream. Data ordering occur within a stream. Unordered or partially ordered data may be supported, unlike with TCP. Multi-homing SCTP supports endpoints with multiple IP addresses, a phenomenon referred to as multi-homing. If the SCTP s and associated IP network are configured in such a way that traffic from one to another travels on physically different paths if different destination IP address are used, associations become tolerant against physical network failures and other problems of that kind. Both multi-homing and multi-streaming can allow redundancies and, hence, a more robust and resilient transport mechanism. SCTP functional description Figure 2 shows a functional view for SCTP transport services as described in [1]. SCTP User Application Divided into streams fragmentation Chunk Bundling Transmission Path Management Association startup and takedown SCTP User Application Sequenced delivery within Stream Acknowledgement and Congestion Avoidance Packet Validation Figure 2: SCTP Transport Service C. Comparison: TCP and SCTP One of the main drawbacks of TCP is that it bytestream-oriented, living the burden of tracking message boundaries to the application. Streams in SCTP are message oriented. Also TCP preserves order too strictly, making it restrictive. With SCTP each stream can be delivered with its own characteristics and are independent of each other. Ordering, non-ordering and partial ordering is supported. Multi-streaming in SCTP also overcomes the TCP headof-line blocking problem. TCP does not support multi-homing, which means that efficient failover mechanisms may not be possible. III. FAILOVER MECHANISMS In an SS7 network using MTP as the transport protocol, multiple links are used to provide redundancy. The same requirements must be fulfilled in a network using SCTP as the transport protocol. Traditionally, SS7 MTP2 Adaptation Layer (M2PA) provides broadband signalling links across an IP-based network, below which a transport protocol may be required. In Figure 3 SCTP is shown as transport protocol below M2PA. We consider two possible means of providing redundancy over the IP network in Figure 3. One scenario is when M2PA relies on its lower layer for redundancy [2]. Here SCTP should have one association with multi-homed IP addresses. The other scenario is

3 when it relies on its higher layer [2]. In the latter scenario SCTP association does not have to provide a redundancy and it is single homed. Investigations on these scenarios are discussed in [2]. Investigations were carried out to determine optimum parameters for changeover on failure. Here when the primary path becomes inactive the SCTP protocol will experience transmission timer timeouts. The endpoint should try to send the data to the alternate active destination transport address. After the error counter for the failed path has been exceeded, the path is reported unreachable and the user makes the alternate (secondary) path its new primary. Association 1 path 1 Signaling Gateway Signaling Gateway A1 B1 MTP 2 MTP 1 MTP 3 M2PA SCTP IP M2PA SCTP IP MTP 3 MTP 2 MTP 1 Host A A2 B2 Host B SS7 IP-based SS7 Association 1 path 2 Figure 5: Failover investigation of multi-homed associations Figure 3: Protocol stack for signalling over an IP network A. Failover with single-homing In this scenario M2PA relies on the MTP3 links for redundancy. Two SCTP associations are used with two MTP3 links as illustrated in Figure 4, instead of a multihomed association. Host A A1 Association 1 B1 Host B C. SCTP finite state machine for failover The SCTP state machine for failover, shown Figure 6, is discussed in [3]. The association could be in one of three states: Phase I, Phase II and Phase III. Phase I is the normal phase where both destinations are reachable. The first timeout on the primary destination triggers a transition into Phase II. This phase counts timeouts toward the SCTP parameter PRL. If the primary responds before PRL is exceeded the association returns to Phase I, otherwise it enters Phase III. Phase III redirects the traffic to the alternate address. The association will remain in Phase III until the primary responds and will then return to Phase I. A2 B2 i = 1 j = 2 Association 2 Figure 4: Failover investigation single-homed associations Phase I D i active New => D i RTO i D i responds Phase II D i errors New => D i PRL exceeded Phase III D i failed New => D j Data is transmitted onto Association 1 by the SCTP user application until the link-failure occurs. During this time Association 2 remains idle. The SCTP protocol then experiences a retransmission timer timeout, unacknowledged data are transmitted onto the failed link and a new retransmission timer is started. After a few retransmissions, the error counter exceeds the association limit. The SCTP application receives a failure announcement and then retrieves all the unacknowledged data chunks and sends these chunks onto Association 2. B. Failover with multi-homing When the MTP3 layer has only one link, M2PA relies on the lower SCTP layer for redundancy. Therefore SCTP should use one association with multi-homed endpoints. Figure 5 illustrates the SCTP multi-homed failover scenario. D i responds Figure 6: SCTP state machine for failover IV. FAILOVER SIMULATIONS A. Simulation setup Simulations were carried using the Simulator 2 (NS2). NS2 is an open-source simulation tool. It is a discreet event simulator targeted at networking research and provides substantial support for simulation of routing, multicast protocols and IP protocols, such as UDP and TCP over wired and wireless networks. It also NS2 supports several algorithms in routing and queuing. A SCTP patch for NS2 was developed by the University of Delaware [4] to run on top of NS2. The SCTP module has NS2 upper layer API support.

4 The NS2 architecture does not allow a with multi-homed interfaces. To overcome this limitation a setup in [5] is used. In this setup each with multihomed interfaces is actually made up of more than one. There is a "core " and multiple "interface s" to simulate the interfaces. The SCTP agent resides on all the s, but traffic only goes to and from the interface s. The core is used for routing and is connected to each interface via a uni-directional link towards the interface. Traffic does not traverse this link. Instead, these links are used to dynamically determine which outgoing interface to use for sending to a particular destination. reached a peak after the primary link has been announced inactive. In the case where PRL = 5 (Figure 11) the RTO value also increased after the failover, but only reached the peak when the primary link became inactive at the maximum value of RTO, which is 6s Output vs. Time (PRL = 2) Interface Output [chunks per seconds] Primary link Secondary link Host 2 1 Interface Figure 7: Emulated multi-homed interfaces in NS Figure 8: Throughput on the association with PRL=2 B. Simulation results A network was set up in NS2 to simulate the SCTP multi-homing environment, as suggested in the previous section. Each endpoint is defined as an SCTP-agent and an association connection was set up between these two agents. Duplex links were set up between the hosts in different endpoints. Each link has a bandwidth of.5 Mbps and a delay of 1 ms and one of these links were set to be the primary path. A heartbeat is sent out to all the s at 3-second intervals. During failover, undelivered packets on the primary path were transmitted to the receiver on the secondary path. New packets were still transmitted on the primary (failed) path, while retransmissions occurred on the secondary path. Each time a retransmission timer expired, the error counter for that address was incremented. When the value in the error counter exceeded the PRL value of that address, the endpoint marked it inactive. In Figure 8 and Figure 9 the output on the primary and secondary path can be observed for different PRL values. In both cases the failure occurred at time = 1s. It can be seen how the traffic picks up on the primary path within the first few seconds and how dramatically it drops when the link fails. Immediately after the failure the primary path still sends out packets, but the secondary path needs to retransmit them. Because of the higher PRL value in Figure 9, the time before timeout is very high. In Figure 8 the primary path is announced inactive at time = 18s, whereas in Figure 9 the primary path is announce inactive at time = 85s. Figure 1 and Figure 11 show the effect on RTO values. The failover takes place at time = 1s. RTO values increased after the failover, while the retransmission on the secondary path took place, and Output [chunks per seconds] RTO Output vs. Time (PRL = 5) Figure 9: Throughput on the association with PRL= RTO vs Time (PRL = 2) Primary Secondary Time Figure 1: RTO values for primary path (PRL=2)

5 RTO [seconds] RTO vs. Time (PRL =5) Figure 11: RTO values for primary path (PRL=5) V. FUTURE WORK SCTP multi-homing support does not deal with multiple endpoints [RFC3257]. Innovative algorithms to deal with this issue will be investigated as future work. The work on multi-homed endpoints will be coupled with investigations on more robust or adaptive failover mechanisms e.g. based on the two-level threshold failover mechanism proposed by Caro, et al. [3]. VI. DISCUSSION AND CUNCLUSION Simulations in this study confirmed the behaviour of SCTP on failover in a multi-homed environment. As the SS7 network converges with the IP network, an IP/SCTP/M2PA network, with carefully set up parameters, could be used to transport SS7 MTP3 messages. A concern raised by the simulations pertains to the duration of failover for the different PRL values. It is a requirement from the SS7 protocol that a failover takes place within 8ms. The failover durations were a lot longer than this specified value. This needs further investigation, the assumption being that the solution could be based on optimised values of SCTP parameters. BIOGRAPHY Mignon Minnaar (main author) is a MEng. student at the University of Pretoria. She works for Telkom SA in Intelligent Voice Services Support department as a Specialist Engineer. Her interest is in voice and control protocols. Dumisa Ngwenya holds a BSc. (Physics/Maths) degree, a BSc. (Engineering), and an MSc. (Engineering) degree. At present he is a Senior Lecturer in Telecommunications and Computer Engineering at the University of Pretoria. His research interest is in multiservice networks. Prior he has worked for the Swaziland Post and Telecommunications, Mintek, Alcatel Altech Telecoms, and Dimension Data. Walter Penzhorn holds degrees from University of Pretoria and University of London. After working for the CSIR for 17 years, he joined the Department of Electrical, Electronic and Computer Engineering at the University of Pretoria in 199 as Associate Professor. Since 1999 he is the director of Telkom's Centre of Excellence in Teletraffic at the Universtiy of Pretoria. He is a senior member of the IEEE, and member of the SAIEE and ECSA. He has more than 25 years of experience in the design and analysis of cryptosystems. REFERENCES [1] G. Wei, et al., SCTP Simulation on NS, Broadband Research centre, Beijing University of Posts and Telecommunication. [2] A. Jungmaier, E.P. Rathgeb and M. Tuxen, On the use of SCTP in Failover- Scenarios. The 6 th World Conference on Systematics, Cybernetics and Informatics, Florida, USA, July 22. [3] A. L. Caro, J. R. Iyengar, P.D. Amer, et al., Modeling SCTP Latency with Multi-Homing and Failovers, University of Delaware and Cisco Systems Inc. [4] [5] ns2sctp/sctp.readme