Mobile Stream Control Transmission Protocol

2.3.1. Overview

The Stream Control Transmission Protocol (SCTP) [33][34] is standardized by the IEFT as a reliable transport protocol over IP networks. One of the core features of SCTP is supporting multi-homing. It has the ability for a single SCTP endpoint to support multiple IP addresses. To support multi-homing, SCTP endpoints exchange lists of addresses during initiation of the connection. This multi-homing feature enables SCTP to be used for Internet mobility support without any support of network routers or special agents. Due to its attractive features such as streaming and multi-homing which promise load balancing ability [35], SCTP has received much attention from the network community, in terms of both research and development.

A single message transmitted over an SCTP association from the originating host to the destination host will be sent using a single destination IP address chosen from the set of destination IP addresses available for that association. The paths used by the IP packets across the network might be different depending on the destination IP address. If a message fails to reach its destination, SCTP may retransmit the message using a different destination IP address.

An SCTP packet is composed of a 12 byte common header and chunks. In the header, a 32-bit checksum is used to detect transmission errors. SCTP packets with an invalid checksum are silently discarded. A randomly created 32 bit verification tag allows a receiver to verify that the SCTP packet belongs to the current association and not to an old one. The chunk on the other hand may contain either control information or user data. Chunks have variable length and there are currently 13 types of them in standard use. Multiple chunks can be bundled into one SCTP packet up to the MTU size, except for the INIT, INIT ACK, and SHUTDOWN COMPLETE chunks.

- 43 -

Figure 11. A schematic view of an SCTP association

SCTP extended with the ADDIP extension is called mobile Stream Control Transmission Protocol (mSCTP) [36][37]. The ADDIP extension enables an mSCTP endpoint to add a new IP address or delete an unnecessary IP address, and also to change the primary IP address used for the association during an on-going session.

When one of these events occurs, the mSCTP endpoint will notify the corresponding event to the remote endpoint by sending an Address Configuration Change (ASCONF) chunk and wait for Address Configuration Acknowledgment (ASCONF ACK) from the remote endpoint. There are seven new parameters: Set Primary Address, Adaptation Layer Indication, Supported Extensions, Add IP Address, Delete IP Address, Error Cause Indication, and Success Indication.

2.3.2. Protocol Descriptions

The association establishment in mSCTP, as in SCTP, uses the four-way handshake as shown in Figure 12. The passive side is called a server and the other is a client. The handshake procedure is as follows: First, the server receives an INIT chunk.

Using its data, the server generates a secure hash of these values and a secret key.

These values along with a MAC are put into a COOKIE, and returned in an INIT-ACK chunk. The client using the received COOKIE assembles a COOKIE-ECHO chunk and returns it to the server. Finally, the server verifies with the MAC, that the COOKIE is the same as it sent, and replies with a COOKIE-ACK chunk.

Figure

Now the association is established. When one of the communicating parties wants to end the association, it can be done in two ways: Either by graceful shutdown, ensuring that no data is lost, or hard termination (abort), not taking care of the peer.

Unlike TCP, when either endpoint performs a shutdown, both of the endpoints stop accepting data.

During association startup, a list of transport addresses (i.e. IP address

is provided between the communicating entities. These addresses are used as the endpoints of different streams.

source/destination combinations. Also one of the addresses is selected as initial primary path, which may be changed later if needed.

The mSCTP handover needs to be triggered by the mobile node because only the mobile node knows the movement of itself and

new access routers. Figure

initiated an mSCTP association with the CN. The resulting association consists of IP address @1 for MN and IP address @

decides to move to a new

are repeated every time MN moves into a new location:

Step 1: Obtaining an IP address for new location.

another access router

MN obtains the new IP address from the DHCPv6 [17] or IPv6

- 44 -

Figure 12. SCTP association setup message sequence

Now the association is established. When one of the communicating parties wants he association, it can be done in two ways: Either by graceful shutdown, ensuring that no data is lost, or hard termination (abort), not taking care of the peer.

Unlike TCP, when either endpoint performs a shutdown, both of the endpoints stop During association startup, a list of transport addresses (i.e. IP address

is provided between the communicating entities. These addresses are used as the endpoints of different streams. Association spans transfers over all of the possible source/destination combinations. Also one of the addresses is selected as initial primary path, which may be changed later if needed.

The mSCTP handover needs to be triggered by the mobile node because only the mobile node knows the movement of itself and the signal strength from the old and

Figure 13 shows a typical mSCTP handover process.

SCTP association with the CN. The resulting association consists of IP for MN and IP address @CN for CN (the primary path). After a while, MN to a new access router and configure address @2. The following steps are repeated every time MN moves into a new location:

Step 1: Obtaining an IP address for new location. As MN is moving towards ss router, at some point it reaches the overlapping region. Then MN obtains the new IP address from the new access router with the help of

or IPv6 stateless address auto-configuration [38].

Now the association is established. When one of the communicating parties wants he association, it can be done in two ways: Either by graceful shutdown, ensuring that no data is lost, or hard termination (abort), not taking care of the peer.

Unlike TCP, when either endpoint performs a shutdown, both of the endpoints stop During association startup, a list of transport addresses (i.e. IP address-port -pairs) is provided between the communicating entities. These addresses are used as the ssociation spans transfers over all of the possible source/destination combinations. Also one of the addresses is selected as initial The mSCTP handover needs to be triggered by the mobile node because only the the signal strength from the old and shows a typical mSCTP handover process. The MN has SCTP association with the CN. The resulting association consists of IP imary path). After a while, MN

- 45 -

Step 2: Adding the new IP address to the SCTP association. MN informs CN of the new address by sending an Address Configuration Change (ASCONF) chunk. As a reply the ASCONF-ACK is sent.

Step 3: Changing the primary IP address. While MN further continues to move towards the new access router, it needs to set the new address as its primary address. The changing of addresses is done according to specific rules, for example as soon as a new IP address is detected. However, the configuration of this change triggering rule is a challenging issue for mSCTP.

Step 4: Deleting the old IP address. As MN has totally moved away from the old access router, the old IP address becomes inactive, and it is deleted from the address list. The knowledge from underlying layers can be used to determine when the address becomes inactive.

Figure 13. An mSCTP handover scenario

2.3.3. Shortcomings

The mobility presents its own minor problems to mSCTP. The protocol is mainly targeted for client-server services, in which the MN initiates the session with a fixed server. For supporting peer-to-peer services, the mSCTP must be used along with an additional location management scheme, e.g. MIPv4 or MIPv6. As for seamless

- 46 -

handover, more work needs to be done in the test and implementation to make it work as expected.

Performance in wireless environments can also cause problems for mSCTP. The protocol assumes that all losses are caused by congestion despite the fact that higher bit error rates and more frequent delay spikes are encountered in wireless networks. This will cause mSCTP to back-off unnecessarily, and result in poor throughput.

Another problematic issue arises when the underlying network operates on IPv6.

Certain address types supported by IPv6 are not routable (i.e. link-local) or reachable outside of specific domains (i.e. site-local). If a peer lists one of these addresses to a peer that has no connectivity to that address, an association could self-destruct and create a black hole effect.