Network Working Group M. Riegel, M. Tuexen INTERNET DRAFT Siemens AG Expires August 20, 2002 February 20, 2002 Mobile SCTP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Transport layer mobility management is proposed as an alternative to Mobile IP for realizing seamless mobility in the Internet. Mobility management is accomplished by use of SCTP (Stream Control Transmission Protocol) and some of its currently proposed extensions. With mobile SCTP seamless handover even crossing physical, link and network layer technologies is fully realized in the mobile client at the end of the network not needing any additional provisions in the network. Mobile services can be provided to such clients by mobile SCTP enabled servers from everywhere in the Internet. Client mobility management based on mobile SCTP seems not to require any new protocol development. It is a particular application of SCTP eventually solving the requirements of mobility in the Internet. It is the intention of this I-D to initiate a discussion to explore the nits and nuts of transport layer mobility management. Please send comments to the mailing list 'mobile@sctp.de'. For subscription please send a mail to mobile-request@sctp.de. Riegel, Tuexen [Page 1] Internet Draft Mobile SCTP February 2002 1. Introduction 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 staying 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'. 2. Transport layer mobility Transport layer mobility management keeps the circuit-less 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. 2.1. Transport layer 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 mostly 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. The transport layer shields the application from the actual network beneath and provides virtual circuits end to end through the Internet. As long as the virtual circuit provided by the transport layer stays intact most application protocols, exept those using IP addresses in messages of their own will continue to work even when the IP address of the network layer beneath changes. 2.2. Mobility extension of the transport layer 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. Riegel, Tuexen [Page 2] Internet Draft Mobile SCTP February 2002 2.3. Transport layer mobility by example The following picture illustrates the concept of transport layer mobility. 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 / \____* * ******** Figure 1 2.3.1. Initial connection to the Internet 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. 2.3.2. Soft handover 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 link already existing 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 the way of two different networks. The mobile client tells the corresponding server using the established transport layer connection that it is now reachable by at 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 Riegel, Tuexen [Page 3] Internet Draft Mobile SCTP February 2002 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. By reaching location B the mobile client may leave the coverage of the access point at location A and may loose the link for the first IP address of the mobile client. 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 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. 2.3.3. Tear down of the initial link 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 not reachable any more by the first IP address and removes this IP address from the association. 2.3.4. The procedure continues... 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. 3. Mobile SCTP, the mobility enabled profile of SCTP It is not necessary to develop a new protocol for transport layer mobility. All the functionality described above providing transport layer mobility already exists in the Stream Control Transmission Protocol (SCTP) when the proposed extension for dynamic addition of IP addresses is added. Further extensions to the SCTP protocol also enables the unreliable 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). 3.1. Mobility enabling functions of SCTP The thrill using SCTP for mobility is due to two features provided by SCTP: Riegel, Tuexen [Page 4] Internet Draft Mobile SCTP February 2002 (1) an end-point can use multiple IP-addresses for one connection (2) an end-point can change these multiple addresses dynamically without affecting the established association. An association is a connection between two SCTP end-points. 3.1.1. Support of multihoming An SCTP end-point 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 [SCTPOVER], [SCTPAPPL] or [RFC2960]. 3.1.2. Dynamic addition and deletion of IP-addresses Using the multihoming feature provides multiple paths through the network. This does not solve the problem of having different IP- addresses at different locations. Therefore the IP addresses of an SCTP end-point have to be modified without affecting an established association. It is also helpful to tell the peer what path to use as the primary. An extension to SCTP providing exactly these features is described in [ADDIP]. 4. Considerations for mobile SCTP enabled hosts The only general requirement is that the transport protocol must be SCTP with the extensions described in [ADDIP]. 4.1. Requirements for SCTP mobility enabled mobile clients To motivate the requirements for the mobile client one has to consider the situation where the client has connections to multiple access point. Figure 2 shows this scenario with two access points. Riegel, Tuexen [Page 5] Internet Draft Mobile SCTP February 2002 ******* +--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 Figure 2 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. 4.2. Requirements for SCTP mobility enabled servers The server must use multiple IP-addresses and a SCTP implementation supporting the extension [ADDIP]. 5. Combination of link layer mobility and transport layer mobility 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 favorably combined with transport layer mobility management reducing the processing requirements at the server side for handling all the handovers. Riegel, Tuexen [Page 6] Internet Draft Mobile SCTP February 2002 6. Possible extensions 6.1. Mobile servers 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 protocl 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]. 6.2. Time multiplexed network interfaces All descriptions in this I-D assume mobile clients with at least two network interfaces. Some kind of wireless technologies 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. 7. Acknowledgements The authors would like to thank M. Bokaemper, H. J. Schwarzbauer and many others for their valuable comments and suggestions. 8. IPR Considerations 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. 9. References [SCTPOVER] L. Ong, Y. Yoakum, "An Overview of the SCTP", , January 2002. Riegel, Tuexen [Page 7] Internet Draft Mobile SCTP February 2002 [ADDIP] R. R. Stewart, Q. Xie, M. Tuexen, I. Rytina, "SCTP Dynamic Addition of IP Addresses", , January 2002. [SCTPAPPL] L. Coene et al., "Stream Control Transmission Protocol Applicability Statement", , November 2001. [RFC2002] C. Perkins, "IP Mobility Support", RFC 2002, October 1996. [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [RFC2960] R. R. Stewart et al., "Stream Control Transmission Protocol", RFC 2960, November 2000. [RFC3237] M. Tuexen et al., "Requirements for Reliable Server Pooling", RFC 3237, January 2002. 10. Authors' Addresses Maximilian Riegel Tel.: +49 89 722 49557 Siemens AG e-mail: maximilian.riegel@icn.siemens.de Hofmannstr 51 81359 Munich Germany Michael Tuexen Tel.: +49 89 722 47210 Siemens AG e-mail: michael.tuexen@icn.siemens.de Hofmannstr 51 81359 Munich Germany This Internet Draft expires August 20, 2002. Riegel, Tuexen [Page 8]