[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09

Network Working Group                                          M. Riegel
Internet-Draft                                    Nokia Siemens Networks
Intended status: Experimental                             M. Tuexen, Ed.
Expires: May 8, 2008                  Muenster Univ. of Applied Sciences
                                                        November 5, 2007

                              Mobile SCTP

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on May 8, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


   Transport layer mobility management is presented in addition to
   Mobile IP for providing seamless mobility in the Internet.  By use of
   SCTP (Stream Control Transmission Protocol) and some of its currently
   proposed extensions a seamless handover can be fully accomplished in
   the mobile client without any provisions in the network, only
   assisted by functions embedded in Mobile SCTP enabled servers.

Riegel & Tuexen            Expires May 8, 2008                  [Page 1]

Internet-Draft                 Mobile SCTP                 November 2007

   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 transport layer mobility in
   the Internet.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Intention  . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Network layer mobility . . . . . . . . . . . . . . . . . .  3
     1.3.  Transport layer mobility . . . . . . . . . . . . . . . . .  3
     1.4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . .  3
   2.  Transport protocols  . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Transport layer functions  . . . . . . . . . . . . . . . .  3
     2.2.  Transport protocols supporting multihoming . . . . . . . .  4
     2.3.  Mobility enabled transport protocols . . . . . . . . . . .  4
   3.  Transport layer mobility . . . . . . . . . . . . . . . . . . .  5
     3.1.  Transport layer mobility by example  . . . . . . . . . . .  5
       3.1.1.  Initial connection to the Internet . . . . . . . . . .  5
       3.1.2.  Soft handover  . . . . . . . . . . . . . . . . . . . .  6
       3.1.3.  Tear down of the initial link  . . . . . . . . . . . .  6
       3.1.4.  The procedure continues... . . . . . . . . . . . . . .  6
   4.  Mobile SCTP, the mobility enabled profile of SCTP  . . . . . .  7
     4.1.  Support of multihoming . . . . . . . . . . . . . . . . . .  7
     4.2.  Dynamic addition and deletion of IP-addresses  . . . . . .  7
   5.  Requirements for Mobile SCTP enabled hosts . . . . . . . . . .  8
     5.1.  Requirements for mobile clients  . . . . . . . . . . . . .  8
     5.2.  Requirements for Mobile SCTP enabled servers . . . . . . .  9
   6.  Further considerations . . . . . . . . . . . . . . . . . . . .  9
     6.1.  Crossing different network technologies  . . . . . . . . .  9
     6.2.  Combination of link layer mobility and transport layer
           mobility . . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.3.  Time multiplexed network interfaces  . . . . . . . . . . . 10
     6.4.  Mobile servers . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13

Riegel & Tuexen            Expires May 8, 2008                  [Page 2]

Internet-Draft                 Mobile SCTP                 November 2007

1.  Introduction

1.1.  Intention

   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

1.2.  Network layer mobility

   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'.

1.3.  Transport layer mobility

   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.

1.4.  Acknowledgements

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

2.  Transport protocols

2.1.  Transport layer functions

   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

Riegel & Tuexen            Expires May 8, 2008                  [Page 3]

Internet-Draft                 Mobile SCTP                 November 2007

   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

   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.

2.2.  Transport protocols supporting multihoming

   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.

2.3.  Mobility enabled transport protocols

   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.

Riegel & Tuexen            Expires May 8, 2008                  [Page 4]

Internet-Draft                 Mobile SCTP                 November 2007

3.  Transport layer mobility

   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.

3.1.  Transport layer mobility by example

   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
      ######### []              *******
      #       #I- - - - -I       ********     **
      #       #I         A     **  **    **     **
      #########         / \___*    *    *******  *
         | |                 *   *********  *  ***           +------+
    Moving from A to B       ****               **  []|      |
        \| |/                *     Internet  ***  *----------|      |
    Loc B\ /                * *              **   * []+------+
      #########             *  **   *    **   *   *           Server
      #       #I            *    ********     *  *
      #       #I- - - - -I   *        **     * **
      ######### []A    *        *******
     Mobile Client      / \____*          *

                                 Figure 1

3.1.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.].  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

Riegel & Tuexen            Expires May 8, 2008                  [Page 5]

Internet-Draft                 Mobile SCTP                 November 2007

   [e.g.] and starts using the provided service.

3.1.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 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.

3.1.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 no longer reachable by the first IP address
   and removes this IP address from the association.

3.1.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.

Riegel & Tuexen            Expires May 8, 2008                  [Page 6]

Internet-Draft                 Mobile SCTP                 November 2007

4.  Mobile SCTP, the mobility enabled profile of SCTP

   The Stream Control Transmission Protocol (SCTP) as currently being
   defined in [RFC4960] with the extension described in [RFC5061] is an
   example of a mobility enabled transport protocol supporting

   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
   [RFC3758] for more details.

4.1.  Support of multihoming

   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

   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 [RFC4960], [RFC3257], and

4.2.  Dynamic addition and deletion of IP-addresses

   The SCTP extension described in [RFC5061] 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

Riegel & Tuexen            Expires May 8, 2008                  [Page 7]

Internet-Draft                 Mobile SCTP                 November 2007


5.  Requirements for Mobile SCTP enabled hosts

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

5.1.  Requirements for 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.  The following figure shows this scenario with two
   access points.

                      +--I       ********     **
             []|  A     **  **    **     **
                      | / \___*    *    *******  *
      #########       |      *   *********  *  ***           +------+
      #       #I------+      ****               **  []|      |
      #       #I------+      *     Internet  ***  *----------|      |
      #########       |     * *              **   * []+------+
             []|     *  **   *    **   *   *
                      +--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 uses the upper
   link (interface and the traffic towards uses the
   lower link (interface

   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

Riegel & Tuexen            Expires May 8, 2008                  [Page 8]

Internet-Draft                 Mobile SCTP                 November 2007

   SCTP with the extension [RFC5061].  Furthermore the forwarding table
   of the mobile client has to be modified according the connectivity

5.2.  Requirements for Mobile SCTP enabled servers

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

6.  Further considerations

6.1.  Crossing different network technologies

   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

6.2.  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 advantageously
   combined with transport layer mobility management reducing the
   processing requirements at the server side for handling all the

   If Mobile SCTP is used in a IEEE802.11 environment a mobile client
   has o make four decisions:
   o  Depending of physical parameters the mobile client has to decide
      when to associate with a base station.  For making this decision
      it can take, for example, the signal strength into account.
   o  After establishing the wireless link layer a method for IP-
      configuration has to be used.  But it makes only sense to do this,
      if the wireless link is stable and there is a chance to really use
   o  After the configuration of the new link is completed a decision
      has to be made when this new path is announced to the peer using
      the ADDIP mechanisms.

Riegel & Tuexen            Expires May 8, 2008                  [Page 9]

Internet-Draft                 Mobile SCTP                 November 2007

   o  The last decision is when to ask the peer to use the new pathas
      the primary path.

   The first decision clearly depends on link layer parameters.  All
   four decisions have in common that they must be done in a way which
   avoids oscillations.  For doing this link layer information has to be
   used in all four decisions.  For example, you want to do the last
   decision only when you are quite sure that the new path will have the
   best transmission characteristics for some time.

6.3.  Time multiplexed network interfaces

   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

6.4.  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.  In this case
   there are two additional problems to solve:
   o  Due to location dependent dynamic assignment of IP addresses to
      mobile hosts there must be a way to address the mobile host
      independently from their dynamically assigned addresses.
   o  Mobile SCTP does not handle the simultaneous handover of both SCTP
      endpoints.  If both endpoints perform a handover at the same time,
      the SCTP association will be lost.  Please note, that Mobile SCTP
      can handle handovers of both SCTP endpoints if they happen

   The method to solve the above problems must take into account the
   frequency of handovers.  The second problem might not occur that
   often compared to the first one.

   One possible solution of the first problem can be based on special
   adoptions to the DNS to take care of the IP-address changes.  Such a
   solution will not solve the second problem.

   Another 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].

Riegel & Tuexen            Expires May 8, 2008                 [Page 10]

Internet-Draft                 Mobile SCTP                 November 2007

   Mobile host would be addressed by a pool handle and in case a mobile
   host changes its IP-addresses it would reregister with the new IP-
   Addresses itself.  This information would be distributed
   automatically between all RSerPool name servers.  It should be noted,
   that this solution might not be appropriate for the Internet but for
   a smaller IP-based network correlating to an RSerPool operational

   In case of the simultaneous handover the RSerPool session would stay
   intact even if the SCTP association breaks.  If the mobile node have
   implemented a way of resynchronizing their states the communication
   between them might only be affected slightly.  RSerPool provides a
   COOKIE mechanism which can be used in some scenarios for
   resynchronizing the states.

7.  Security Considerations

   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.

8.  IANA Considerations

   There are no actions needed.

9.  References

9.1.  Normative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

9.2.  Informative References

   [RFC3758]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
              Conrad, "Stream Control Transmission Protocol (SCTP)
              Partial Reliability Extension", RFC 3758, May 2004.

   [RFC2002]  Perkins, C., "IP Mobility Support", RFC 2002,
              October 1996.

   [RFC3237]  Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L.,
              Loughney, J., and M. Stillman, "Requirements for Reliable
              Server Pooling", RFC 3237, January 2002.

Riegel & Tuexen            Expires May 8, 2008                 [Page 11]

Internet-Draft                 Mobile SCTP                 November 2007

   [RFC3257]  Coene, L., "Stream Control Transmission Protocol
              Applicability Statement", RFC 3257, April 2002.

   [RFC3286]  Ong, L. and J. Yoakum, "An Introduction to the Stream
              Control Transmission Protocol (SCTP)", RFC 3286, May 2002.

   [RFC3436]  Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
              Layer Security over Stream Control Transmission Protocol",
              RFC 3436, December 2002.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
              Kozuka, "Stream Control Transmission Protocol (SCTP)
              Dynamic Address Reconfiguration", RFC 5061,
              September 2007.

Authors' Addresses

   Maximilian Riegel
   Nokia Siemens Networks
   St.-Martin Strasse 76
   81541 Munich

   Phone: +49 89 636 75194
   Email: maximilian.riegel@nsn.com

   Michael Tuexen (editor)
   Muenster Univ. of Applied Sciences
   Stegerwaldstr. 39
   48565 Steinfurt

   Email: tuexen@fh-muenster.de

Riegel & Tuexen            Expires May 8, 2008                 [Page 12]

Internet-Draft                 Mobile SCTP                 November 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Riegel & Tuexen            Expires May 8, 2008                 [Page 13]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/