[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04                                                
 Internet Draft                                         Seok J. Koh, KNU
 Internet Engineering Task Force                      Mee Jeong Lee, EWU
 draft-sjkoh-sctp-mobility-04.txt          Maximilian Riegel, Siemens AG
 Expires December 2004                                   Mary Li Ma, UBC
                                                    Michael Tuexen, UASM
                                                               June 2004



                  Mobile SCTP for Transport Layer Mobility



 Status of this Memo

    By submitting this Internet-Draft, I certify that any applicable
    patent or other IPR claims of which I am aware have been disclosed,
    and any of which I become aware will be disclosed, in accordance with
    RFC 3668 [1].

    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

    This document discusses the architecture of mobile SCTP (mSCTP) for
    IP mobility support. The SCTP is the third transport layer protocol
    next to TCP/UDP. It can also be used for IP mobility from the multi-
    homing features. The SCTP with the ADDIP extension (or mSCTP) would
    provide seamless or soft handover for the mobile host without support
    of routers or agents in the networks. For location management, the
    mSCTP could be used along with Mobile IP, Session Initiation Protocol
    or Reliable Server Pooling.






 Koh, Lee, Riegel, Ma, Tuexen                                  [Page 1]


 Internet Draft    mSCTP for Transport Layer Mobility         June 2004







                            Table of Contents

    1. Introduction..................................................3
    2. Terminology...................................................3
    3. Motivations on Mobile SCTP....................................4
       3.1 IP Mobility Issues........................................4
       3.2 SCTP Multihoming Feature..................................5
       3.3 Session Type considered in Mobile SCTP....................5
    4. Procedures for mSCTP Handover.................................6
       4.1 Session Initiation by Mobile Client.......................7
       4.2 Obtaining an IP address for a new location................7
       4.3 Adding the new IP address to the SCTP association.........7
       4.4 Changing the Primary IP address...........................7
       4.5 Deleting the old IP address from the SCTP association.....9
       4.6 Repeating the handover procedures.........................9
    5. Further Considerations for mSCTP Handover.....................9
       5.1 Requirement for Mobile SCTP...............................9
       5.2 Number of IP addresses used by Fixed Server...............9
       5.3 Dynamic IP address configuration.........................10
       5.4 AAA Functionality........................................10
       5.5 Link Layer Support for Multi-homing......................10
    6. Location Management for mSCTP................................11
       6.1 Use of mSCTP with Mobile IP..............................11
       6.2 Use of SCTP with SIP.....................................11
       6.3 Use of SCTP with RSerPool................................11
    7. Comparison of mSCTP with SIP, Mobile IP and RSerPool.........12
    8. Security Considerations......................................13
    9. Acknowledgement..............................................13
    10. References..................................................14
       10.1 Normative References....................................14
       10.2 Normative References....................................14
    Author's Addresses..............................................15
    Full Copyright Statement........................................16
    Intellectual Property...........................................16












  Koh, Lee, Riegel, Ma, Tuexen                                [Page 2]


 Internet Draft    mSCTP for Transport Layer Mobility         June 2004

 1. Introduction

    SCTP (Stream Control Transmission Protocol), as defined in RFC 2960
    [3], is the third transport layer protocol following TCP and UDP. The
    SCTP is featured multi-streaming and multihoming, differently from
    TCP. It is noted that the multihoming feature of SCTP enables the
    SCTP to support the IP mobility.

    More specifically, the SCTP with the ADDIP extension [4], which is
    called mobile SCTP (mSCTP) in this document, can be used to provide
    seamless handover for mobile hosts that are moving into different IP
    network regions during the active session [5, 6].

    The mSCTP may be used as an alternative scheme against the handover
    schemes based on Mobile IP [7, 8]. Differently from the Mobile IP
    based handover schemes, which rely on the support of network routers
    for tunneling between access routers, the mobile SCTP provides the
    handover management at the transport layer without help of routers.

    The mSCTP can be used to provide seamless handover for mobile hosts
    that are moving in to different IP networks. In other words, the
    mSCTP is targeted for the client-server services, in which the mobile
    client initiates an SCTP session with the fixed server. For
    supporting the peer-to-peer services, in which a session is
    terminated at the mobile host, the mSCTP must be used along with an
    additional location management scheme such as Mobile IP [9], Session
    Initiation Protocol (SIP), Reliable Server Pooling (RSerPool) [11] or
    Dynamic DNS (DDNS).

    This document describes the architecture of SCTP for IP mobility
    support. Specifically, we describe the use of SCTP for seamless
    handover by using the SCTP ADDIP extension [5]. We also discuss how
    to integrate SCTP with SIP, MIP or RSerPool for location management.

    This document is intended to continue discussion to explore the use
    of SCTP for IP mobility support. 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>.


 2. Terminology

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in RFC 2119 [2].

    In this document, "mSCTP" is short for "mobile SCTP".





  Koh, Lee, Riegel, Ma, Tuexen                                [Page 3]


 Internet Draft    mSCTP for Transport Layer Mobility         June 2004

 3. Motivations on Mobile SCTP

    In this section, we discuss motivations on the use of SCTP for IP
    mobility support, in the viewpoint of IP mobility management issues.


 3.1 IP Mobility Issues

    IP mobility issues have been focused and are regarded as a core
    technology required for providing seamless mobility in the wireless
    mobile networks such as WLAN, 3G Cellular. IP mobility issues can be
    classified into Location Management and Handover Management.


 3.1.1 Location Management

    Location Management is used to identify the current location of
    mobile nodes and also to keep track of the their location changes as
    they move on.

    In Mobile IP [7, 8], the mobility agents such as Home Agent (HA) and
    Foreign Agent (only for IPv4) are employed for location management as
    well as data transport. In the schemes, Home Address (HoA) and Care-
    of Address (CoA) are used for a terminal identifier and a location
    identifier of the IP host, respectively. For location management, the
    Mobile IP uses the binding update messages, in which a mobile node
    has to inform its current location (CoA) to its HA.

    SIP can also be used for location management. In SIP, a UA registers
    its new location with the location database via SIP Registrar server
    by sending an SIP Register message containing a Contact Header.

    So far, the Dynamic DNS (DDNS) has also been discussed as one of the
    candidate approaches for location management, which would not require
    special servers or procedures for mSCTP client.


 3.1.2 Handover Management

    The handover management is targeted to provide the mobile hosts for
    seamless handover whenever they change their point of attachment to
    IP networks (as represented by cell regions or IP subnets). The main
    objective of the handover management is to minimize the service
    disruption due to data loss and/or handover latency during handover.

    In Mobile IP, the Low Latency or Fast handover schemes have been
    designed for handover management. These schemes rely on the tunneling
    between old and new access routers for seamless handover.




  Koh, Lee, Riegel, Ma, Tuexen                                [Page 4]


 Internet Draft    mSCTP for Transport Layer Mobility         June 2004

    The mobile SCTP can be used as an alternative scheme against such
    Mobile IP based handover schemes. Differently from the Mobile IP
    handover schemes that rely on the help of network routers for
    tunneling between access routers, the mobile SCTP provides the
    handover management at the transport layer without help of routers.


 3.2 SCTP Multihoming Feature

    The SCTP intrinsically provides the multihoming feature [3], in which
    a mobile node is allowed to simultaneously bind multiple IP addresses
    to its network interface.

    The recent works on the SCTP include the ADDIP extension [4]. The
    ADDIP extension enables the SCTP to add, delete and change the IP
    addresses during active SCTP association.

    In this document, the SCTP implementation with the ADDIP extension is
    called the mobile SCTP (mSCTP) [5]. The mSCTP can be used for
    seamless handover while the mobile node is moving into different IP
    network regions over the session period. This document aims at
    discussing the use of mSCTP for seamless handover, which includes the
    specific handover procedures and associated implementation issues.


 3.3 Session Type considered in Mobile SCTP

    Sessions considered in mobile communications can be classified into
    the following two types:

     a. Session originated from mobile host toward fixed host
     b. Session originated from fixed host toward mobile host

    The mobile sessions in (a) seem to be a natural extension of the
    client-server model, in which the mobile host originating the session
    can be viewed as a client, while the counter endpoint will function
    as a server.

    On the other hand, the case (b) requires the additional location
    management functionality for the session originator to find the
    current location of the mobile host and to keep track of the location
    changes, which has so far been addressed by Mobile IP [7, 8].

    The mobile SCTP, in the present form, is targeted for seamless
    handover of mobile session associated with the case (a). To support
    the session type of the case (b), the mSCTP must be used along with
    an additional location management scheme such as SIP, Mobile IP [9]
    or RSerPool.




  Koh, Lee, Riegel, Ma, Tuexen                                [Page 5]


 Internet Draft    mSCTP for Transport Layer Mobility         June 2004

 4. Procedures for mSCTP Handover

    In this section, we describe the generic algorithm of mobile SCTP for
    handover in the procedural manner, which is designed based on the
    scheme in [5].

    The mSCTP handover needs to be triggered by MC because only the MC
    knows the movement of itself and the signal strength from the old and
    new ARs.

    More specifically, we consider a mobile client (MC) that initiates an
    SCTP association with a fixed server (FS), and then moves from
    Location A (2.2.2.x domain) to Location B (3.3.3.x domain), as shown
    in Figure 1.



                                 [1.1.1.2]
                                  +----+
                                  | FS |
                                  +----+
                                    ||
                                ##########
                                # Router # [1.1.1.1]
                                ##########
                                    ||
                                 *******
                              ***       ***
                             **            **
                             **   Internet   **
                             **              **
                             **           **
                                ***       ***
                             ||  ******** ||
                             ||           ||
                          #######         #######
             [2.2.2.1]   # AR1 #         # AR2 #  [3.3.3.1]
                         #######         #######
                            |               |
                 Location A |               | Location B
                            |               |
                         +----+          +----+
                         | MC |=========>| MC |
                         +----+          +----+
                       [2.2.2.2]        [3.3.3.2]


                    Figure 1. SCTP for Seamless Handover




  Koh, Lee, Riegel, Ma, Tuexen                                [Page 6]


 Internet Draft    mSCTP for Transport Layer Mobility         June 2004

    Figure 1 illustrates an example of the use of mobile SCTP for
    seamless handover in IPv4 networks. Based on this figure, the
    handover procedures are described in the succeeding sections.


 4.1 Session Initiation by Mobile Client

    We assume that the MC initiates an SCTP association with the FS. The
    resulting SCTP association has the set of IP addresses with [2.2.2.2]
    for MC and [1.1.1.2] for FS. It is also assumed that the MC can get
    an IP address ([2.2.2.2]) with help of DHCP or IPv6 stateless address
    auto-configuration.

    Note that the FS is in the single homing with [1.1.1.2], and the MC
    is also in single homing state, in which the IP address [2.2.2.2] is
    set to its primary IP address in the SCTP initiation process.


 4.2 Obtaining an IP address for a new location

    Let us assume that the MC moves from Location A to B. In this phase,
    we also need to assume that the MC can obtain a new IP address
    belonging to the Location B, which may be possible with help of the
    DHCP or IPv6 address auto-configuration capability in the Location B.

    Obtaining a new IP address may also rely on the support of the
    wireless signaling control at the physical layer, in order for the MC
    to get the IP address information via IP control packets from the
    Location B.

    By SCTP, the newly obtained IP address ([3.3.3.2] in the figure) MUST
    be signaled or informed to the SCTP protocol stack, and then the SCTP
    will bind the new IP address to the existing SCTP association.


 4.3 Adding the new IP address to the SCTP association

    After obtaining a new IP address, the SCTP of MC MUST inform the
    Fixed Server about the new IP address by sending Address
    Configuration Change (ASCONF) Chunk to the FS. The MC may receive the
    corresponding ASCONF-ACK Chunk from the FS.


 4.4 Changing the Primary IP address

    While the MC continues to move toward the Location B, it needs to
    change its primary IP address to the new IP address according at an
    appropriate rule.




  Koh, Lee, Riegel, Ma, Tuexen                                [Page 7]


 Internet Draft    mSCTP for Transport Layer Mobility         June 2004

    Actually, the configuration of a specific rule for changing the
    primary IP address is a challenging issue of the mobile SCTP.

    Some of the possible rules for triggering the primary IP address
    change are listed below:

    a. As soon as a new IP address is detected

     When the MC receives the ASCONF-ACK from FS, it sends another
     ASCONF with "Address Configuration Parameter" set to "Set Primary
     Address".

     FS sends back ASCONF-ACK once receives the second ASCONF to confirm
     the handover successfully.

     This choice may be preferred in terms of the handover latency, in
     particular, for the fast-moving MC. However, it is less suitable
     when the MC shows a so-called oscillation (or ping-pong) behavior
     across those two locations.

    b. By using an explicit indication from the underlying layer

     In this case, the underlying PHY layer of MC detects and compares
     the signal strength, and determines the time on when the SCTP sends
     an ASCONF with "Set Primary Address".

     If the underlying physical layer can detect and compare the signal
     strength of the physical media, and also inform the SCTP about a
     certain indication (possibly by using a up-call), then the MC may
     trigger the primary address change according to the indication.

     This rule is a more preferred choice, but seems to depend on the
     wireless system concerned and its implementations.

    c. By using an indication from the upper layer

     The change of the primary IP address may also be triggered by an
     indication from the upper layer of the MC.  In particular, this
     scenario may be considered when an MC is in an overlay mobile
     communication environment where two or more networks are available
     at the same time, such as the so-called intersystem handover or
     vertical handover between WLAN and 3GPPs.  In this case, a vertical
     handover of the MC can be triggered from an upper layer indication
     by considering a trade-off between connection bandwidth, coverage
     and cost from the concerned systems/locations.

    If once the primary address is changed, the FS will send the upcoming
    data over the new primary IP address.




  Koh, Lee, Riegel, Ma, Tuexen                                [Page 8]


 Internet Draft    mSCTP for Transport Layer Mobility         June 2004

    There is still a further issue on how the MC should handle the data
    packets queued in the outgoing buffer with the source IP address of
    the old primary IP address.


 4.5 Deleting the old IP address from the SCTP association

    As the MC progresses to move toward the Location B, if the old IP
    address gets inactive, the MC MUST delete the IP address from the
    address list. The rule for determining that the IP address is
    inactive may also be implemented by using additional information from
    the underlying network or physical layer, as done in the previous
    step (for changing the primary address.)


 4.6 Repeating the handover procedures

    The procedural steps for seamless handover described above will be
    repeated whenever the MC moves to a new location, until the SCTP
    association will be released.

    One particular further consideration in the handover procedures is
    that Steps 4.3 (adding), 4.4 (primary change) and 4.5 (deleting) can
    possibly be performed at the same time, which may depend on a
    specific implementation of mSCTP or network environment concerned.
    This issue needs to be investigated for further study.


 5. Further Considerations for mSCTP Handover

 5.1 Requirement for Mobile SCTP

    The only requirement for providing the seamless handover based on
    SCTP is that the MC and FS hosts are equipped with the Mobile SCTP
    implementations, (i.e., SCTP with ADDIP extension.)

 5.2 Number of IP addresses used by Fixed Server

    In this document, we assume that the FS is in the single homing, i.e.
    the FS and MC are in a 1-to-2 asymmetric multi-homing configuration
    [10]. In a certain case, we may need to consider the multi-homed FS.

    It is noted that there are still many further issues on how to handle
    the mSCTP handover or which is better in the performance aspect for
    each of the single-homed and multi-homed FS cases. For more
    information on this issue, please refer to [5, 6].






  Koh, Lee, Riegel, Ma, Tuexen                                [Page 9]


 Internet Draft    mSCTP for Transport Layer Mobility         June 2004

 5.3 Dynamic IP address configuration

    The basic assumption for seamless handover to a new IP subnet region
    is that the MC is able to obtain a new IP address from the new
    location. Typically, this will be implemented by using DHCP in IPv4
    networks and DHCPv6 or Stateless address auto-configuration in IPv6
    networks.

    The handover latency incurred for obtaining the new IP address via
    DHCP or IPv6 needs to be examined by experiments. The concerned
    handover latency also includes the delay required for the handover
    delay between the wireless links.


 5.4 AAA Functionality

    It is envisioned that the deployment of mSCTP will be done along with
    the appropriate AAA server in the respective access network domains.
    The AAA server is used to authenticate and the MC in the locations,
    and also to authorize the new IP address configuration via DHCP and
    IPv6 stateless configuration. However, this issue is outside the
    scope of this document.


 5.5 Link Layer Support for Multi-homing

    To support the multi-homing capability for Mobile Client, we need to
    consider the characteristics of the wireless links such as WLAN and
    Cellular systems. It is noted that Cellular systems are expected to
    easily support the link-level multi-homing features, whereas the WLAN
    system case is for further study.

    The multi-homing feature enables the mSCTP to support seamless
    handover by simultaneous binding of two different addresses while
    staying the overlapping region. Time interval for an MC to stay in
    the overlapping region will give impact on the performance of the
    handover procedures.

    It is also noted that the handover based on mSCTP depends on the
    support of the underlying physical and link layers to measure the
    wireless signal strength. The measured signal strength information
    can helpfully used for the SCTP to trigger the addition and deletion
    of IP addresses, and the change of the primary address. The handover
    performance will depend on such capability in terms of data loss and
    delay during handover.







  Koh, Lee, Riegel, Ma, Tuexen                               [Page 10]


 Internet Draft    mSCTP for Transport Layer Mobility         June 2004

 6. Location Management for mSCTP

    The mSCTP can provide only the handover for mobile hosts or the
    sessions initiated by mobile hosts. To support the mobile sessions
    that are terminated at mobile hosts, the mSCTP needs to be used along
    with a location management scheme such as Mobile IP or SIP.

 6.1 Use of mSCTP with Mobile IP

    In this scenario, Mobile IP will be used to locate a mobile host and
    then for Home Agent to forward the data packet (SCTP INIT chunk) to
    the mobile host. The succeeding process for SCTP association
    initiation, including SCTP INIT-ACK, COOKIE-ECHO, and COOKIE-ACK,
    will be done directly between the mobile host and the peering host,
    not via Home Agent.

    After an SCTP association is successfully setup, the mSCTP will be
    used for providing seamless handover for the mobile host. Details of
    SCTP with MIP are described in [9].

 6.2 Use of SCTP with SIP

    In this scenario, each host uses SCTP instead of TCP/UDP as the
    transport protocol. After the call setup by SIP signaling, the SCTP
    will be used for data transport and seamless handover.

    The SIP provides location management functionality by using SIP
    REGISTER messages. When a mobile host moves into a visiting network,
    it will update its current location (e.g., IP address or SIP URL) by
    sending a SIP Register (with a Contact Header) to the (home) SIP
    Registrar server. The Registrar server will then update the location
    database as indicated by the REGISTER message.

    When a call setup is requested with a mobile host, the (home) SIP
    proxy server will interrogate the location database to locate the
    mobile host and then relay the SIP INVITE message to the (visiting)
    SIP Proxy server up to the mobile host. If once the SCTP association
    is established via the SIP signaling, the data transport between two
    concerned hosts will be done according to the mSCTP handover
    mechanisms.

 6.3 Use of SCTP with RSerPool

    RSerPool [11] can be used for location management. A mobile server
    registers a pool handle such that it becomes part of a pool. It is
    allowed that a pool consists of one pool element only. A client
    (mobile or not) must know the pool handle of the mobile server it
    wants to talk to. It sends a name resolution request to one of the
    ENRP servers and gets back the current IP-addresses. Since the ENRP



  Koh, Lee, Riegel, Ma, Tuexen                               [Page 11]


 Internet Draft    mSCTP for Transport Layer Mobility         June 2004

    servers within an operational scope share its state it is not
    important which ENRP server is contacted. If the MS changes its IP-
    address it re registers at the home ENRP server.

    So the pool handles can be used to address a server with changing IP-
    addresses. If the MC or the MS change their addresses due to
    handovers mSCTP can be used to handle this, except for the case were
    the MC and the MS change their addresses simultaneously. In this case
    mSCTP fails i.e. the SCTP association terminates. The RSerPool
    session concept can be used to reestablish a new SCTP association
    using the new addresses and continuing the RSerPool session.
    Depending on the application the impact of this session failover for
    the application can be very small.


 7. Comparison of mSCTP with SIP, Mobile IP and RSerPool

    Table 1 summarizes the comparison of mSCTP with Mobile IP, SIP and
    RSerPool.


         Table 1. mSCTP, MIP, SIP and RSerPool for Mobility Support

    +---------------+------------+-------------+------------+-----------+
    |   Category    |    mSCTP   |  Mobile IP  |    SIP     |  RSerPool |
    +---------------+------------+-------------+------------+-----------+
    |Protocol Layer | Transport  |  Network    |Application |  Session  |
    +---------------+------------+-------------+------------+-----------+
    |    Location   |     Not    | Supported   |  Supported | Supported |
    |   Management  | Supported  |             |            |           |
    +---------------+------------+-------------+------------+-----------+
    |    Handover   | Supported  | FMIP needed | Supported  | Supported |
    |   Management  |            |             | with mSCTP |with mSCTP |
    +---------------+------------+-------------+------------+-----------+
    |     Route     | Provided   |   Binding   |    Not     | Provided  |
    | Optimization  | Bacially   |Update needed|   Provided |with mSCTP |
    +---------------+------------+-------------+------------+-----------+
    |    Network    |    Not     | Required    |     Not    |    Not    |
    |    Support    |  Required  |             |  Required  |  Required |
    +---------------+------------+-------------+------------+-----------+
    |    Special    |    No      | Home Agent, |SIP servers,|   ENRP    |
    |    Agents     |            |Foreign Agent| Registrar  |  Server   |
    +---------------+------------+-------------+------------+-----------+


    As described in Table 1, the mSCTP can be used for seamless handover
    in the transport layer. To use mSCTP, it is required that the CN and
    MN hosts should be aware of the mobile SCTP. Instead, mSCTP does not
    need the support of network routers for seamless handover.



  Koh, Lee, Riegel, Ma, Tuexen                               [Page 12]


 Internet Draft    mSCTP for Transport Layer Mobility         June 2004

    Furthermore, the mSCTP intrinsically provides the Route Optimization
    without using any additional Binding Update procedures.

    For location management, the mSCTP may be used along with MIP or SIP.
    In case of using MIP for location management, only the MN needs to be
    aware of MIP, whereas the CN need not use MIP. Using mSCTP with MIP,
    the MN must also be able to bind the CoA as well as HoA to its
    applications. The HoA will be used only for location management.
    After establishment of an SCTP session, the HoA will not be used for
    data transport. Instead, the CoA is employed for the SCTP data
    transport. On the other hand, in MIP, only HoA is bound to the
    applications of MN regardless of the different CoAs.

    The MIP provides the location and management in the network layer,
    and it can support seamless handover with help of neighboring routers
    such as tunneling between old and new ARs. On the other hand, SIP is
    an application signaling protocol that supports the location
    management for user or personal mobility. SIP itself does not provide
    seamless handover. It may be used together with mSCTP for seamless
    handover.

    Reliable Server Pooling [11] can be used to provide the location
    management functionality. Used in combination with mSCTP it provides
    all functionalities required for a mobility solution. Simultaneous
    handovers of a MS and a MC will result in a session failover.


 8. Security Considerations

    This document discusses architecture of SCTP mobility support. The
    associated security issues will be identified as further works go on.


 9. Acknowledgement

    The Authors would like to give special thanks to the following people
    for their valuable contributions:

       Moon Jeong Chang, Ewha Women University
       Hee Young Jung, ETRI
       Randall Stewart, Cisco Systems
       Qiabing Xie, Motorola










  Koh, Lee, Riegel, Ma, Tuexen                               [Page 13]


 Internet Draft    mSCTP for Transport Layer Mobility         June 2004

 10. References

 10.1 Normative References

   [1] S. Bradner, " Intellectual Property Rights in IETF Technology",
      BCP 79, RFC 3668, February 2004.

   [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement
      Levels", BCP, RFC 2119, March 1997.

   [3] Stewart, R., et al., "Stream Control Transmission Protocol", RFC
      2960, October 2000.


 10.2 Normative References

   [4] Stewart, R., "Stream Control Transmission Protocol (SCTP) Dynamic
      Address Reconfiguration", draft-ietf-tsvwg-addip-sctp-07, February
      2003.

   [5] Riegel, M. and Tuexen M., "Mobile SCTP", draft-riegel-tuexen-
      mobile-sctp-03, August 2003.

   [6] Coene, L. (ed.), "Multihoming issues in the SCTP", draft-coene-
      sctp-multihome-04, June 2003.

   [7] Perkins, C. (ed.), "IP Mobility Support for IPv4", RFC 3344,
      August 2002.

   [8] Johnson, D., et al., "Mobility Support in IPv6", draft-ietf-
      mobileip-ipv6-24, June 2003

   [9] Koh, S. J., et al., "mSCTP with Mobile IP for Transport Layer
      Mobility", draft-sjkoh-mobile-sctp-mobileip-04, June 2004

   [10] Stewart, R. Xie, Q., "Stream Control Transmission Protocol: A
      Reference Guide", Addison Wesley Longman, 2001.

   [11] Tuexen, M. et al., "Requirements for Reliable Server Pooling",
      RFC 3237, January 2002.












  Koh, Lee, Riegel, Ma, Tuexen                               [Page 14]


Internet Draft    mSCTP for Transport Layer Mobility         June 2004

 Author's Addresses

      Seok J. Koh
      sjkoh@knu.ac.kr
      Department of Computer Science
      Kyungpook National University, Korea

      Mee Jeong Lee
      lmj@ewha.ac.kr
      Ewha Womans University (EWU), Korea

      Maximilian Riegel
      Maximilian.Riegel@icn.siemens.de
      Siemens AG, Germany

      Mary Li Ma
      maryma@interchange.ubc.ca
      University of British Columbia (UBC), USA

      Michael Tuexen
      tuexen@fh-muenster.de
      University of Applied Science in Muenster (UASM), Germany






























 Koh, Lee, Riegel, Ma, Tuexen                               [Page 15]


Internet Draft    mSCTP for Transport Layer Mobility         June 2004

  Full Copyright Statement

   Copyright (C) The Internet Society (2004).  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
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



  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
   http://www.ietf.org/ipr.

   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 ietf-
   ipr@ietf.org.















 Koh, Lee, Riegel, Ma, Tuexen                               [Page 16]