Mobile SCTP

It is the intention of this I-D to continue a discussion to explore the nits and nuts of transport layer mobility management. Please send comments to the mailing list 'mobile@sctp.de'. To subscribe to this mailing list, please send a mail to mobile-request@sctp.de.

Traditionally mobility in the Internet is accomplished by making sure the moving host is reachable by its originally assigned IP address even when the address leaves the network area the address belongs to. To keep reachability by an address outside its assigned area the protocol Mobile IP RFC2002 can be used installing an agent in the home area taking care of all packets sent to a mobile host currently outside its native network area. The home agent knows about the foreign location of the mobile host and forwards all packets addressed to it to an agent in the foreign location which finally delivers the packets to the mobile host. Home agent and foreign agent are connected by a tunnel making the mobility enabled network layer 'circuit switched'.

Transport layer mobility management keeps the circuitless nature of the network layer of the Internet untouched and implements the whole functionality for providing mobility to hosts in the transport layer entities at both ends of the network. The transport layer of the Internet is the first layer going up the networking stack which provides end-to-end control.

The authors would like to thank M. Bokaemper, A. Chana, C. Ross, H. J. Schwarzbauer and many others for their valuable comments and suggestions.

A client host accesses a particular service over the Internet by establishing a transport layer connection to a server host providing such service. This connection is typically made reliable by an appropriate transport control protocol and carries the application protocol elements and all the user data of a particular service between the hosts over the Internet. Applications needing a reliable transport may use the Transmission Control Protocol (TCP) which provides a reliable, duplicate free and in-sequence delivery of user data. The transport layer makes use of transport layer addresses. For the Transmission Control Protocol this is a pair consisting on an IP-address and a port number. A TCP connection is established between two TCP endpoints, each of the TCP endpoints being identified by one transport layer address of TCP. It is important that the two TCP endpoints of a TCP connection can not change during the lifetime of a TCP connection. When a host changes its IP address, for example by attaching to a new network, existing TCP connections can not use this new address because the TCP endpoint can not be changed. This is one of the reasons why today Mobile IP is used to provide the mobile host with a constant IP address which is used for communication with the peer.

A host is called multihomed if it has multiple network layer addresses. In case of IP networks this means that the host has multiple IP-addresses. This does not necessarily mean that the host has also multiple link layer interfaces. Multiple IP addresses can be configured on a single link layer interface. A transport protocol supports multihoming if the endpoints can have more than one transport layer addresses. These transport layer addresses are considered as logically different paths of the peer towards the endpoint with the multiple transport addresses.

Transport layer protocols allowing the modification of the endpoints during the lifetime of a connection are called mobility enabled transport protocols. A mobility enabled transport protocol allows for the change of the IP address of the network layer while keeping the end-to-end connection intact. If the transport protocol supports multihoming and the host can attach to multiple networks the transport protocol can make use of the simultaneous connection.

The mobility enabled transport layer shields the application not only from the actual network beneath and provides virtual circuits end to end through the Internet but also hides the change of underlying network addresses. Most application protocols, except those using IP addresses in messages of their own will continue to work when being ported to a mobility enabled transport layer. Since the mobility is now handled by the endpoints which reside in the hosts and not in the network the transport layer mobility connection harmonises fully with the nature of the Internet.

The following picture illustrates the concept of transport layer mobility. This example is based on a mobility enabled transport protocol supporting multihoming. Also only a mobile client connecting to a server is considered

Loc A ######### [2.0.0.2] ******* # #I- - - - -I ******** ** # #I A ** ** ** ** ######### / \___* * ******* * | | * ********* * *** +------+ Moving from A to B **** ** [8.0.0.4]| | \| |/ * Internet *** *----------| | Loc B\ / * * ** * [8.0.0.5]+------+ ######### * ** * ** * * Server # #I * ******** * * # #I- - - - -I * ** * ** ######### [4.0.0.3]A * ******* Mobile Client / \____* * ********

A mobile client connects to the Internet by some wireless technology and gets assigned an IP address from the local address space at location A [e.g. 2.0.0.2]. This can be accomplished by any of the techniques currently known for dynamic address assignment, like PPP or DHCP. The mobile client being now reachable over the Internet establishes a transport layer connection to a server anywhere 'in' the Internet [e.g. 8.0.0.4] and starts using the provided service.

The mobile client moves from location A towards location B and gets knowledge of reaching the coverage of another network by information from the physical layer of its NIC. In addition to the already existing link the mobile client establishes a link to the network at location B and gets assigned an IP address of the network at location B on its second network interface. Thus the mobile client becomes multi-homed and is now reachable by two different networks. The mobile client tells the corresponding server using the established transport layer connection that it is now reachable by a second IP address. Technically speaking, it adds the newly assigned IP address to the association identifying the connection to the server. To enable easy distinction of the two links at the mobile client several IP addresses should be assigned to the network interface of the server. This allows to represent different links by different entries in the routing table of the mobile client. On reaching location B the mobile client may leave the coverage of the access point at location A and may loose the link for its first IP address. The data stream between server and mobile client gets interrupted and the reliability behavior of the transport protocol ensures that all data is sent over the second link in the case of permanent failure of the first link. If the mobile client has access to information about the strength of the wireless signal the handover to the second link will be initiated before severe packet loss occurs, making the handover more soft.

When the mobile client has proved by information from the physical layer that the failure of the first link is permanent, it will inform its peer that it is now no longer reachable by the first IP address and removes this IP address from the association.

When the mobile client moves on, it may reach the coverage of another wireless network. It will repeat the procedure described above gaining seamless mobility while keeping running applications working.

The Stream Control Transmission Protocol (SCTP) as currently being defined in RFC2960 and RFC3309 with the extension described in ADDIP is an example of a mobility enabled transport protocol supporting multihoming. A further extension to the SCTP protocol also enables the partial reliable transport of data extending the applicability of transport layer mobility management from applications based on a reliable transport protocol (TCP, for example) to applications currently realized on an unreliable transport protocol (UDP, for example). See PRSCTP for more details.

An SCTP transport address is a pair of an IP-address and a port number as in the case of TCP. But an SCTP endpoint can be identified by a sequence of SCTP transport addresses all sharing the same port number. An association is a connection between two SCTP endpoints. An SCTP endpoint can use multiple IP-addresses for an association. These are exchanged during the initiation of the association. The multiple addresses of the peer are considered as different paths towards that peer. This means that a server must use multiple IP-addresses to provide the mobile client with multiple paths. These will be used while moving between locations. It should be mentioned that this path-concept is used only for redundancy, not for load sharing. Therefore one path is used for normal transmission of user data. It is called the primary path. For a more detailed description see RFC2960, RFC3257, RFC3286 and RFC3309.

The SCTP extension described in ADDIP makes SCTP a mobilty enabled transport protocol. This means that it allows an SCTP endpoint to change its IP-addresses. Furthermore it is possible for an SCTP endpoint to signal to its peer which IP-address it should use as the primary path. This is very useful in case of multiple Internet acesses with different parameters.

The only general requirement is that the transport protocol must be SCTP with the extensions described in ADDIP.

To motivate the requirements for the mobile client one has to consider the situation where the client has connections to multiple access point. The following figure shows this scenario with two access points.

******* +--I ******** ** [2.0.0.2]| A ** ** ** ** | / \___* * ******* * ######### | * ********* * *** +------+ # #I------+ **** ** [8.0.0.4]| | # #I------+ * Internet *** *----------| | ######### | * * ** * [8.0.0.5]+------+ [4.0.0.3]| * ** * ** * * +--I * ******** * * A * ** * ** / \____* ******* Mobile Client ********* Server During the time where the mobile client is reachable via two different access networks it has to make sure that it uses both links. Thus, for example, the forwarding of the mobile client has to be set up in a way that the traffic towards 8.0.0.4 uses the upper link (interface 2.0.0.2) and the traffic towards 8.0.0.5 uses the lower link (interface 4.0.0.3). The mobile client also knows the quality of the two links and can make sure that it uses the better one whenever appropriate. Using the ability to request the server to modify its primary path it is also possible that the mobile client makes sure that the traffic from the server towards the mobile client uses the better link. It should be mentioned that this link handover has to be done carefully to avoid oscillation and frequent switching. Summarizing this, the mobile client must use an implementation of SCTP with the extension ADDIP. Furthermore the forwarding table of the mobile client has to be modified according the connectivity state.

The server must use multiple IP-addresses and a SCTP implementation supporting the extension ADDIP.

Keeping seamless connectivity while switching between different network technologies, e.g. using wireless LAN in a hot-spot area and automaticaly switching over to a second or third generation public mobile network when leaving the hot-spot area, can be accomplished by Mobile SCTP without any additional functionality. It doesn't matter for Mobile SCTP whether the network interfaces belong to the same technology or different technologies as long as it is possible to establish a connection to the Internet via the interfaces. Depending on the technology of the network interfaces different strategies may be applied for selecting the link to be used.

Some radio technologies like IEEE802.11 wireless LAN provide mobility management functionalities in the link layer. Link layer handover is mostly restricted to micro mobility but can be advantageously combined with transport layer mobility management reducing the processing requirements at the server side for handling all the handovers.

All descriptions in this I-D assume mobile clients with at least two network interfaces. Some kind of wireless technology might allow to use one network interface card to establish several network connections quasi in parallel in a time multiplexed manner. This might lead to some considerable cost benefits for mobile clients, but does not change the basic procedures of transport layer mobility management.

The description up to now mostly focuses on mobile clients using services from fixed servers. Sometimes the other way round might be necessary; addressing mobile hosts from fixed hosts. Due to location dependent dynamic assignment of IP addresses to mobile hosts the normal way using the DNS is not appropriate. Therefore some kind of paging protocol or a special adoption of the DNS may become necessary. Others possiblilities may involve some application layer protocols. One possible technique to handle the mobility of hosts can be based on the RSerPool protocol suite. This allows to access a server, or a pool element in RSerPool terminology, by using a pool handle. The RSerPool protocol suite can be implemented on small devices like cellular phones as required in RFC3237.

If IPSec is used to secure the SCTP communication new security associations have to be established during the addition/deletion of IP addresses. This introduces an additional delay. If TLS RFC3436 is used this can be avoided.

This proposal in is full conformance with RFC2026. Siemens may have patent rights on technology described in this document which employees of Siemens contribute for use in IETF standards discussions. In relation to any IETF standard incorporating any such technology, Siemens hereby agrees to license on fair, reasonable and non-discriminatory terms, based on reciprocity, any patent claims it owns covering such technology, to the extent such technology is essential to comply with such standard. There may be claims by other parties on technology described in this document. Please regard the IPR pages on the IETF web-site for further information.