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

Versions: 00                                                            
Internet Engineering Task Force                            Faramak Vakil
INTERNET DRAFT                                           Ashutosh  Dutta
draft-itsumo-hmmp-00.txt                                  Jyh-Cheng Chen
Date: October 1999                                Telcordia Technologies
Expires: April 2000
                                                           Shinichi Baba
                                                        Yasuro Shobatake
                                           Toshiba Research America,Inc.

                   Host Mobility Management Protocol
                    Extending SIP to 3G-IP Networks
                       <draft-itsumo-hmmp-00.txt>

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.

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

   The distribution of this memo is unlimited.  It is filed as <draft-
   itsumo-hmmp-00.txt>, and expires April, 2000. Please send comments to
   either farm@research.telcordia.com or sbaba@tari.toshiba.com.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

ABSTRACT

   Host mobility management protocol (HMMP) is a protocol for supporting
   real-time and non-real-time multimedia applications on mobile
   terminals of 3G-IP networks. HMMP utilizes as well as extends session
   initiation protocol (SIP) to provide means of domain hand-off (i.e.,
   roaming), and subnet hand-off (i.e., macro mobility) so that users
   can access the network from any location using their own mobile



ITSUMO Group                                                    [Page 1]


Internet-Draft     Host Mobility Management Protocol        October 1999


   terminal. An advantage of HMMP is that it can spoof constant
   endpoints for mobile TCP connections and supports mobile TCP
   applications in a SIP environment without any changes to the TCP.

   The objective of this document is to present the preliminary
   specifications of HMMP, identify the impact of mobility on SIP, and
   propose necessary extensions to ensure that SIP can support roaming
   users adequately. Specifically, it proposes that

   a. the SIP INFO method provides a means of profile verification
      and/or replication, and address binding, b. the SIP REGISTER
   method designates a "RHO"
      CONTACT that allows the registrar to obtain a new address from the
      DHCP on behalf of the mobile, c. the SIP user agent is equipped
   with a SIP_EYE agent that maintains
      a record of ongoing TCP connections of the mobile, and d. the SIP
   user agent understands address binding INFO messages and
      takes necessary actions.

   Furthermore, it proposes that either the DHCP interact with the DNS
   and update it dynamically, or a new protocol be developed to allow
   applications to use SIP registrar for name to address and address to
   name mappings.

1.Introduction

1.1 The Rationale

   Driving the trend towards third generation wireless IP (3G-IP)
   technology are users' demand for perpetual ubiquitous access to the
   Internet, rapid proliferation of mobile Internet appliances, and
   providers' desire for deploying a flexible wireless and wireline IP
   platform that supports heterogeneous services economically [1, 2, 3].
   Furthermore, the current wisdom is that the existing circuit switched
   and 1G/2G (i.e., 1G and 2G) wireless systems will eventually evolve
   and merge into an end-to-end IP platform that provides ubiquitous
   real-time as well as non-real-time services. In a nutshell, it is
   envisioned that an end-to-end wireless/wireline IP platform
   comprising 3G wireless access networks and a wireline IP backbone
   will support real-time and non-real-time multimedia services in the
   future. Thus, supporting roaming users is an essential feature of the
   end-to-end signaling and control system of IP networks as well as a
   critical topic for consideration in the IETF SIP working group.

1.2 3G-IP Requirements and Issues

   A 3G-IP network is a wireless platform that will enable mobile users'
   IP appliances to access multimedia services on end-to-end



ITSUMO Group                                                    [Page 2]


Internet-Draft     Host Mobility Management Protocol        October 1999


   wireline/wireless IP platforms in future [6]. We envision that it
   will

   - eventually be built upon the packet mode capabilities of the 3G
     wireless technologies such as IMT-2000 [4, 5],

   - support mobile real-time and non-real-time services such as mobile
     telephony, mobile web access, and mobile data services [7, 8],

   - provide means of global roaming, offer intelligent services (e.g.,
     call forwarding, etc.) similar to those of today's intelligent
     networks,

   - strive to ensure that the quality (and price) of their service
     offerings will be comparable to those of today's wireless
     telephony and data services, and

   - be built upon enhancements of the current IETF standards to the
     extent possible so that the design and development cycle is
   minimized.

   Among the key issues in the design of the signaling and control
   system of 3G-IP networks are how to

   + support terminal as well as personal/user mobility,

   + satisfy the quality of service (QoS) requirements of services,
     particularly those of real-time applications for roaming users,

   + ensure privacy and security of the users as well as the network
     resources,

   + perform billing and accounting, and

   + maintain smooth interworking with the public switched telephone
     network (PSTN) and its 1G/2G wireless access networks.

   Although each of these issues may have some impact on the signaling
   protocols of IP networks that are being developed in the SIP working
   group, addressing all of them is beyond the scope of this document.
   This document exclusively focuses on the specifications of a mobility
   management protocol that uses an extended version of SIP to support
   multimedia services of roaming users.

1.3 Scope and Purpose

   The objective of this document is to present the preliminary
   specifications of host mobility management protocol (HMMP). We



ITSUMO Group                                                    [Page 3]


Internet-Draft     Host Mobility Management Protocol        October 1999


   - build upon the personal mobility feature of SIP to design HMMP that
     suppots terminal as well as personal mobility,
   - identify the impact of mobility on SIP,  and
   - propose necessary extensions to ensure that SIP can support roaming
     users via HMMP adequately.

   HMMP is a protocol for supporting real-time and non-real-time
   multimedia applications on mobile terminals. It provides means of
   domain hand-off (i.e., roaming), and subnet hand-off (i.e., macro
   mobility). However, HMMP primarily relies on the link layer to
   support the cell-hand-off (i.e., micro-mobility). HMMP also spoofs
   constant endpoints for mobile TCP connections and supports mobile TCP
   applications in a SIP environment without any changes to the TCP.

1.4 Related IETF Documents

   HMMP is primarily built upon the session initiation protocol (SIP) as
   specified in RFC 2543.  Other related IETF documents are
   - SDP: Session Description Protocol (RFC 2327),
   - DHCP: Dynamic Host configuration Protocol  (RFC 2131),
   - IP Encapsulation within IP (RFC 2003), and
   - Minimal Encapsulation within IP (RFC2004).

1.5 Organization of the Document

   This document is organized as follows. HMMP's assumptions on the
   underlying network environment are summarized in Section 2, where
   Section 2.1 describes the architecture of a 3G-IP network, and
   Section 2.2 summarizes its signaling architecture that is the
   substrate of HMMP.  Section 3 provides an overview of the HMMP
   operation and underscores the need for augmenting the SIP user agent
   with a SIP_EYE agent that tacks ongoing TCP connections of the mobile
   station.  Section 4 contains the detailed specifications of HMMP
   where we describe how HMMP utilizes SIP to provide means of
   registration, location service, and hand-off to roaming users. The
   function and basic operation of the SIP_EYE agent are described in
   Section 5. In Section 6, we summarize the impact of supporting
   mobility via HMMP on SIP specifications, and highlight necessary
   extensions for supporting mobility with SIP. Finally, Section 7
   concludes the document with open issues for further study.

2. Assumptions: A 3G-IP Environment

   This Section provides an overview of a 3G-IP network and its
   signaling architecture that serves as the foundation of HMMP.

2.1 Architecture of a 3G-IP Network




ITSUMO Group                                                    [Page 4]


Internet-Draft     Host Mobility Management Protocol        October 1999


   Figure 1 depicts the end-to-end packet platform of a 3G-IP network,
   which comprises 3G-IP access networks and a packet switched IP
   backbone network. The IP backbone network is an end-to-end wireline
   IP infrastructure that will comprise regional providers' wireline IP
   networks that are connected through the Internet. Besides mobile
   stations/terminals, a wireless access network usually comprises a set
   of base stations, base station controllers, and mobile switching
   centers [3].  In order to support the needs of its users, a wireless
   access network interacts with the network control and signaling
   entities that are shown as "Signaling & MAAAQ" in Figure 1.  What
   follows is a brief description of these elements and their functions.

Mobile Station (MS)

   It is the user mobile terminal that allows users to communicate, and
   also provides means of interaction (i.e., signaling) between users
   and the network.

Base Station (BS)

   It is an adaptive remote radio multiplexer/demultiplexer that
   provides physical and link layer functions and essentially serves as
   a MAC layer repeater.  In IMT-2000 programmable software radios can
   be used to provide flexibility across frequency bands at the MS and
   the BS.

Base Station Controller (BSC)

   It is a multi-port bridge (or switch) with an IP interface to MSC
   that interacts with the network control and management system (via
   the MSC) to control and manage base stations. A BSC may control one
   or more BSs.

Mobile Switching Center (MSC)

   An MSC is an IP router that connects the wireless access network and
   the regional wireline IP network.  In the IP parlance, each MSC is
   the default gateway of all IP MSs that are supported by BSCs that are
   connected to it. A couple of points are worth noting. First,
   different BSCs may be connected to different ports of an MSC.
   Second, the BSC and MSC functions may be implemented either in a
   single physical entity, or as two separate entities.









ITSUMO Group                                                    [Page 5]


Internet-Draft     Host Mobility Management Protocol        October 1999


                          +-----------+
                       -->| Signaling |<--
                      /   |  & MAAAQ  |   \
            /--------/    +-----------+    \--------\
           /                    |                    \
          \/                    |                    \/
    +-----------+               |                 +----------+
    | Signaling |               |                 | Signaing |
    |  & MAAAQ  | <-------------|---------------> | & MAAAQ  |
    +-----------+               |                 +----------+
          |                     |                     |
       ___|___              ____|__                ___|___
      /       \            /       \              /       \
     /         \          /         \            /         \
    /Regional IP\________/  Internet \_________ /Regional IP\
    \ Network   /        \           /          \ etwork    /
     \         /          \         /            \         /
      \_______/            \_______/              \_______/
          |                                             |
          |                                             |
       +-----+                                       +-----+
       | MSC |                                       | MSC |
       +-----+                                       +-----+
          |                                             |
          |                                             |
     +----------+                                 +----------+
     |   BSC    |                                 |   BSC    |
     +----------+                                 +----------+
       |       |                                   |       |
       |       |                                   |       |
    +----+   +----+                             +----+   +----+
    | BS |   | BS |                             | BS |   | BS |
    +----+   +----+                             +----+   +----+
               |                                  |        |
               |                                  |        |
            +-----+                            +-----+   +-----+
            | MS  |                            | MS  |   |  MS |
            +-----+                            +-----+   +-----+

   Figure 1.  End-to-end network architecture of a 3G-IP network

Signaling & MAAAQ

   Signaling provides connection management as well as means of
   interaction between users and network control system and interaction
   among network control entities. MAAAQ (Mobility, Authentication,
   Authorization, Accounting, and QoS) entities support mobility
   management, AAA, and QoS management functions for mobile users. These
   functional entities usually reside on the wireline backbone, and are



ITSUMO Group                                                    [Page 6]


Internet-Draft     Host Mobility Management Protocol        October 1999


   part of the overall signaling and control system of the end-to-end
   platform.  As Figure 1 indicates the home and visiting signaling &
   MAAAQ entities may either interact directly or via a third party
   signaling & MAAAQ entity on the global Internet. In the latter case,
   the third party signaling & MAAAQ entity serves as a trusted broker
   between the home and visiting network signaling and MAAAQ entities.

2.2 A Signaling Architecture for 3G-IP Networks

   The overall signaling architecture of a 3G-IP is shown in Figure 2.
   It uses session initiation protocol (SIP) [9, 10] as the basis of its
   end-to-end signaling and control architecture. The rationales for the
   choice of SIP are that:

   - SIP is a lightweight end-to-end protocol with a small set of
     messages that can be used for user as well as network node
     signaling.
   - SIP uses a single request message for session initiation, and scales
     well over wide-area networks.
   - SIP is ideal for IP mobiles, enables mobiles to perform some
     intelligent networking functions themselves, and supports non-IP
     mobiles via a customer gateway.
   - SIP provides a means of personal mobility that is a crucial part of
     mobility management in wireless environments.

       Visiting Network                           Home Network
   <-------------------->                    <-------------------->

     Visiting Registrar                          Home Registrar
       +----+                                       +----+
       | VR |                                       | HR |
       +----+                                       +----+
         |                                            |
         |                                            |
    +-----------+                                 +-----------+
    |  MAAAQ    |                                 |  MAAAQ    |
    +-----------+                                 +-----------+
    | SIP Server| <-----------------------------> | SIP Server|<...
    +-----------+                                 +-----------+   .
          |                                           |           .
       ___|___              _______                ___|___        .
      /       \            /       \              /       \       .
     /         \          /         \            /         \      .
    /Regional IP\________/  Internet \_________ /Regional IP\     .
    \ Network   /        \           /          \ Network   /     .
     \         /          \         /            \         /      .
      \_______/            \_______/              \_______/       .
          |                                             |         SIP



ITSUMO Group                                                    [Page 7]


Internet-Draft     Host Mobility Management Protocol        October 1999


          |                                             |         .
       ___|___                                       ___|___      .
      /       \                                     /       \      .
     /         \                                   /         \     .
    / 3G Access \                                 / 3G Acces  \    .
    \ Network   /                                 \ Network   /     .
     \         /                                  |\         /|     .
      \_______/                                   | \_______/ |     .
          |                                       |           |     .
          |                                       |           |     .
          |                                       |           |     .
          |                                       |           |     .
       +-----+                                 +-----+      +-----+..
       | MS  |                                 | MS  |      |  MS |
       +-----+                                 +-----+      +-----+

   Figure 2.  A signaling architecture for 3G-IP networks

   All MSs and fixed hosts have SIP user agents that provide means of
   interactions with the SIP servers (i.e., proxy servers, redirect
   servers, and registrar) within the network.  In Figure 2, the SIP
   server entity of a regional IP network represents the set of SIP
   proxy and SIP redirect servers within the regional network that
   perform the network control and signaling functions. Similarly, the
   registrar represents the server (or set of servers) that accepts
   (accept) SIP REGISTER requests and provides (provide) location
   services that are similar to those of the home/visiting location
   registries (HLR/VLR) in today's wireless telephony. As Figure 2 shows
   the MAAAQ entity is built on top of SIP, and uses the location and
   signaling services of SIP to support roaming users.

   The illustration of the MAAAQ entities and SIP server as a single
   module in Figure 2 shall not be interpreted as a requirement for
   having a centralized SIP server or MAAAQ entity per regional network.
   Figure 2 only shows the required functions, though each of the SIP
   and MAAAQ entities comprise a set of distributed agents. Similarly,
   the SIP registrars (i.e., HR and VR) may be implemented as either
   central or distributed databases.

   The remainder of this document focuses primarily on the
   specifications of a HMMP for the mobility management entity as well
   as necessary extensions to SIP for supporting roaming users.

3. An Overview of HMMP

   Figure 3 depicts an end-to-end 3G-IP platform in relative detail. Let
   us consider the scenario where a corresponding host communicates with
   a mobile host. For the sake of discussion, let us assume that



ITSUMO Group                                                    [Page 8]


Internet-Draft     Host Mobility Management Protocol        October 1999


   - the mobile has already registered with its home network using SIP
     REGISTER method, and
   - its communication with the corresponding host starts when it is at
     point A and continues as it moves towards point D.
   In general, a mobility management protocol shall provide three
   functions to the mobile users.  These functions are
     i.cell hand-off (micro mobility): that allows users to move from a
       cell to another, i.e., moving between base stations from A to B,
    ii.subnet hand-off (macro mobility): that allows users to move
       between different subnets within the same administrative domain
       from B to C, and
   iii.roaming (global mobility): that allows users to roam between
       different subnets that belong to different administrative domains
       from C to D.

       Visiting Network                           Home Network
   <-------------------->                    <-------------------->

     Visiting Registrar                          Home Registrar
       +----+                                       +----+
       | VR |                                       | HR |
       +----+                                       +----+
         |                                            |
         |                                            |
    +-----------+                                 +-----------+
    |  MAAAQ    |                                 |  MAAAQ    |
    +-----------+                                 +-----------+
    | SIP Server| <-----------------------------> | SIP Server|
    +-----------+                                 +-----------+
          |                                           |
          |                                           |
          |                                           |
       ___|___              ______                 ___|___
      /       \            /      \               /       \     +----+
     /         \          /        \             /         \----| CH |
    /Regional IP\________/ Internet \_ ________ /Regional IP\   +----+
    \ Network  /         \          /           \ Network   /
     \        /           \        /            |\         /|*
      \______/             \______/             | \_______/ |*
          |                                     |           |*                             |                                     |           |*
          |                                     |           |*
       +-------+                               +-------+    +-------+
       | MSC 3 |                               | MSC 2 |    | MSC 1 |
       +-------+                               +-------+    +-------+
          |                                     |                |*
          |                                     |                |*
     +----------+                         +-------+        +----------+
     |  BSC 3   |                         | BSC 2 |        |  BSC 1   |



ITSUMO Group                                                    [Page 9]


Internet-Draft     Host Mobility Management Protocol        October 1999


     +----------+                         +-------+        +----------+
       |       |                              |              |*      |
       |       |                              |              |*      |
    +----+   +----+                        +----+         +----+   +----+
    | BS |   | BS |                        | BS |         | BS |   | BS |
    +----+   +----+                        +----+         +----+   +----+
               |                              |              |*       |
               |                              |              |*       |
            +-----+                        +-----+        +-----+   +-----+
            | MS  |                        | MS  |        | MS  |   |  MS |
            +-----+                        +-----+        +-----+   +-----+
              D                               C              B         A

   Figure 3.  Cell hand-off in HMMP

   The cell hand-off (i.e., micro mobility) is not part of HMMP and is
   usually handled at the link layer, while HMMP uses SIP to provide the
   subnet hand-off (i.e., macro mobility) and roaming (i.e., global
   mobility) functions for mobile hosts on 3G-IP networks. What follows
   is a walk through the operation of HMMP using this example.

3.1 Cell hand-off

   As the mobile moves from A to B, then the link layer mobility
   management entity

   *  binds the mobile's MAC address (or CDMA sequence) to the BSC port
      destined for base station B, and
   *  updates the label translation table in BSC 1, so that the
      information destined for the mobile host is routed to base station
      B. Note that the label translation table refers to a table in the
      BSC that contains the binding of mobile's MAC addresses to BSC
      ports.

   If the mobile can communicate with two adjacent base stations
   simultaneously, the mobile's binding to base station A may be
   maintained for a time-out period after the hand-off so that the
   hand-off is soft and transient packets are not lost. Note that the IP
   address of the mobile remains the same.


3.2 Subnet hand-off

   The mobile moves further from B to C, and it is still registered with
   the network. HMMP supports subnet hand-off (i.e., macro mobility)
   during the session as follows.

   + The mobile asks a new temporary address from DHCP.  The mobile



ITSUMO Group                                                   [Page 10]


Internet-Draft     Host Mobility Management Protocol        October 1999


     requests a new address either directly (see Section 4.1.1) or via a
     SIP registrar (see Section 4.1.2).  The DHCP gives the mobile a
     temporary IP address, the address of its default gateway, and the
     subnet mask. Furthermore, the DHCP updates the domain name system
     (DNS) simultaneously.
   + In public networks, the network authenticates the mobile as a
     protection against fraud.  In principle, it is always desirable to
     authenticate a mobile before assigning network resources such as
     adresses to it. For instance, PPP has its own registration scheme
     using CHAP during session initiation and the MIP extension using
     NAI for registration prpose has been proposed. The registration
     approach described in Section 4.1.2 as well as the Dynamic
     Registration and Configuration Protocol(DRCP) proposed in McAuley,
     et.al [14] both can authenticate and assign an address to
     it simultaneously.
   + The mobile or SIP server re-invites the corresponding host to the
     temporary address (similar to the approach proposed by Wedlund and
     Schulzrinne [16]).
   + SIP server and network resource reservation scheme should create a
     new route with adequate resources between the corresponding host
     and the mobile.
       a. This new route with adequate resources is only created for
          real-time applications like voice. There have been several
          proposal for the use of Resource ReServation Protocol
          (RSVP)[21] for resource reservation in wireline networks that
          have SIP signaling [22]. However, due to its receiver
          initiated reservation scheme, RSVP is not suitable for a mobile
          wireless netwok.  The specifications of a resource reservation
          mechanism for supporting real-time mobile applications and its
          interaction with SIP require further study, and are beyond the
          scope of this document.
       b. The non-real-time applications are allowed to traverse the
          network hop-by-hop.
   + The mobile or SIP server ensures that the transient data is
     forwarded to the new address, i.e., it creates a short-lived tunnel
     between MSC 1 and MSC 2 to reduce loss of the transient data due to
     hand-off. In order to create this tunnel, the mobile or SIP server
     informs MSC-1 to bind the previous address of the mobile to its
     current one for a time-out period.  This requires
       *  SIP user agents at all MSCs (i.e., subnet routers), and
       *  the address of the most recent MSC which is the most recent
          default gateway.

       Visiting Network                           Home Network
   <-------------------->                    <-------------------->

     Visiting Registrar                          Home Registrar
       +----+                                       +----+



ITSUMO Group                                                   [Page 11]


Internet-Draft     Host Mobility Management Protocol        October 1999


       | VR |                                       | HR |
       +----+                                       +----+
         |                                            |
         |                                            |
    +-----------+                                 +-----------+
    |  MAAAQ    |                                 |  MAAAQ    |
    +-----------+                                 +-----------+
    | SIP Server| <-----------------------------> | SIP Server|
    +-----------+....                         ....+-----------+
          |         |                         |        |
          |       +----+                     +----+    |
          |       |DHCP|                     |DHCP|    |
          |       +----+                     +----+    |
       ___|___     |        _______   _        |    ___|___
      /       \....        /       \  _        ..../       \     +----+
     /         \          /         \ _         **/*********\----| CH |
    /Regional IP\________/  Internet \__________*/Regional IP\   +----+
    \ Network   /        \           /          *\ Network  /|
     \         /          \         /           *|\        / |
      \_______/            \ ______/            *| \______/  |
          |                                     *|           |
          |                                     *|           |
          |                                     *|           |
       +-------+                               +-------+    +-------+
       | MSC 3 |                               | MSC 2 |====| MSC 1 |
       +-------+                               +-------+    +-------+
          |                                    *|                |
          |                                    *|                |
     +----------+                         +-------+        +----------+
     |  BSC 3   |                         | BSC 2 |        |  BSC 1   |
     +----------+                         +-------+        +----------+
       |       |                             *|              |      |
       |       |                             *|              |      |
    +----+   +----+                        +----+         +----+   +----+
    | BS |   | BS |                        | BS |         | BS |   | BS |
    +----+   +----+                        +----+         +----+   +----+
               |                             *|              |       |
               |                             *|              |       |
            +-----+                        +-----+        +-----+   +-----+
            | MS  |                        | MS  |        | MS  |   |  MS |
            +-----+                        +-----+        +-----+   +-----+
              D                               C              B         A





   Figure 4. Subnet hand-off in HMMP



ITSUMO Group                                                   [Page 12]


Internet-Draft     Host Mobility Management Protocol        October 1999


3.3 Roaming

   Except for the fact that the mobile SHALL always be autheticated,
   roaming in HMMP is similar to subnet hand-off described in Section
   3.2. As the mobile moves further to D, HMMP operates as follows:

   + The mobile requests for a temporary address and receives one from
     DHCP. The DHCP updates the DNS simultaneously.
   + The mobile re-registers with its temporary address in the new domain
     using the SIP REGISTER method.
        * The mobile profile is added to the visiting registrar (VR),
          i.e., its profile is replicated either through interaction of
          the VR with the HR or by pre-planned profile replications [13]
          in the neighboring VRs. The pre-planned profile replications
          reflect the mobility pattern of the mobile, and its effective
          realization requires continuous monitoring of users' mobility
          patterns.
   + The mobile or SIP server re-invites the corresponding host to the
     temporary address (similar to the approach proposed by Wedlund and
     Schulzrinne [16]).
   + SIP server and network resource reservation scheme should create a
     new route with adequate resources between the corresponding host and
     the mobile.
       a. This new route with adequate resources is only created for
          real-time applications like voice. The specifications of a
          resource reservation mechanism for supporting real-time mobile
          applications and its interaction with SIP require further
          study, and are beyond the scope of this document.
       b. The non-real-time applications are allowed to traverse the
          network hop-by-hop.
   + The mobile or SIP server ensures that the transient data is
     forwarded to the new address, i.e., it creates a short-lived tunnel
     between MSC 2 and MSC 3 to reduce loss of the transient information
   + The mobile or SIP server informs MSC-2 to bind the previous address
     of the mobile to its current one for a time-out period. This
     requires
       * SIP user agents at all MSCs (i.e., subnet routers), and
       * the address of the most recent MSC which is the most recent
         default gateway.

       Visiting Network                           Home Network
   <-------------------->                    <-------------------->

     Visiting Registrar                          Home Registrar
       +----+                                       +----+
       | VR |                                       | HR |
       +----+                                       +----+
         |                                            |



ITSUMO Group                                                   [Page 13]


Internet-Draft     Host Mobility Management Protocol        October 1999


         |                                            |
    +-----------+                                 +-----------+
    |  MAAAQ    |                                 |  MAAAQ    |
    +-----------+                                 +-----------+
    | SIP Server| <-----------------------------> | SIP Server|
    +-----------+....                         ....+-----------+
          |         |                         |         |
          |       +----+                     +----+     |
          |       |DHCP|                     |DHCP|     |
          |       +----+                     +----+     |
       ___|___     |         _______            |    ___|___
      /       \....         /       \           ..../       \     +----+
     /*********\***********/*********\*************/*********\----| CH |
    /Regional IP\_________/  Internet \__________ /Regional IP\   +----+
    \*Network   /         \           /           \ Network   /
     \*        /           \         /            |\         /|
     *\_______/             \______ /             | \_______/ |
         *|                                       |           |
         *|                                       |           |
         *|                                       |           |
       +-------+                               +-------+    +-------+
       | MSC 3 |===============================| MSC 2 |    | MSC 1 |
       +-------+                               +-------+    +-------+
         *|                                     |                |
         *|                                     |                |
     +----------+                         +-------+        +----------+
     |  BSC 3   |                         | BSC 2 |        |  BSC 1   |
     +----------+                         +-------+        +----------+
       |      *|                              |              |      |
       |      *|                              |              |      |
    +----+   +----+                        +----+         +----+   +----+
    | BS |   | BS |                        | BS |         | BS |   | BS |
    +----+   +----+                        +----+         +----+   +----+
              *|                              |              |       |
              *|                              |              |       |
            +-----+                        +-----+        +-----+   +-----+
            | MS  |                        | MS  |        | MS  |   |  MS |
            +-----+                        +-----+        +-----+   +-----+
              D                               C              B         A


   Figure 5.  Roaming in HMMP

3.4 Supporting TCP Applications with HMMP

   Internet applications that require a reliable service from the
   transport mechanism, e.g., file transfer protocol (FTP), primarily
   use TCP. Thus, it is essential that HMMP support mobile TCP



ITSUMO Group                                                   [Page 14]


Internet-Draft     Host Mobility Management Protocol        October 1999


   applications without requiring any changes to the TCP.

   Although the fundamental abstraction of both SIP and TCP is the
   connection, they identify it differently. A session/call ID
   identifies a SIP connection/session, while a pair of endpoints
   identifies a TCP connection. Each TCP endpoint is identified with a
   pair of integers (host, port) where host is IP address of the
   endpoint, and port is the TCP port on the host. However, as a mobile
   roams, its IP address, i.e., the host integer of its TCP endpoint
   changes. In order to support TCP applications properly, HMMP shall
   spoof constant TCP endpoints despite changes in their host integers
   (i.e., IP addresses) due to roaming of the mobiles. The spoofing
   process is akin to mobile IP with route optimization [17, 18], and
   its underlying idea is that

   - the mobile informs the corresponding TCP endpoints about its new
     address,
   - the corresponding host(s) binds (bind) the initial IP address of the
     mobile with its new temporary (i.e., care of address) IP address,
     and
   - the corresponding host(s) uses (use) encapsulation to send the TCP
     packets bearing the initial source and destination addresses to the
     current location/address of the mobile.

   In order to support TCP applications on HMMP without modifying TCP,
   the SIP user agent SHALL be augmented with a SIP_EYE agent that
   tracks TCP connection set-ups and releases within the mobile. The
   SIP_EYE agent enables the SIP user agent to maintain a record of
   mobile's ongoing TCP connections, and their identifiers. SIP_EYE
   operates as follows:

    i. It examines headers of TCP packets to monitor the birth and death
       of TCP connections as well as identify their endpoints, i.e., the
       source and destination IP addresses and port numbers of these
       connections.
    ii. It maintains a current record of the mobile's ongoing TCP
        connections' identifiers, and the address of the current and last
        (i.e., most recent) MSCs (i.e., default gateways) within the
        mobile's SIP user agent.
    iii. SIP_EYE records a state comprising four integers, <original
         MS IP address, previous MS IP address, current MS IP
         address, original corresponding IP address>, per TCP
         connection. The original MS IP address is the IP address of
         the mobile at the beginning of the TCP session, previous mobile
         IP address is the last IP address of the mobile just before its
         current one, and current MS IP address is the current IP
         address of the mobile. The original corresponding IP address is
         the IP address of the corresponding host at the beginning of the



ITSUMO Group                                                   [Page 15]


Internet-Draft     Host Mobility Management Protocol        October 1999


         TCP session.
    iv. Upon a mobile station's successful registration with the visiting
        network, its SIP user agent sends
        (a) an INFO message (messages) to the SIP user agent(s) of
            corresponding host(s) to request binding of the original
            address of the mobile with its current one, and
        (b) also sends a INFO message to last MSC for binding the
            previous host address to the new one so that a short-lived
            tunnel is created for forwarding transient data to the
            mobile's location.
    v. The corresponding host and the MSC use IP encapsulation (either
       within IP [19] or minimal [20]) to forward the TCP information to
       the mobile's current location.

   The key advantage of this approach is that TCP stays as is; though
   the required IP encapsulation reduces the bandwidth efficiency of the
   channel.

   Since the DHCP interacts with DNS to dynamically update the name to
   address and address to name mappings, new TCP connections will be
   established using the current address of the mobile.  Another
   alternative for name to address mapping and vice-versa is that
   instead of a dynamic DNS, one develops a new protocol that allows
   applications to use SIP registrar for name to address and address to
   name mappings. The specifications of this alternative and its
   comparison with a dynamic DNS scheme require further study, and is
   beyond the scope of this docuement.

4. HMMP on SIP

   SIP supports personal mobility function. HMMP builds upon the
   personal mobility feature of SIP to enable users to access the
   network from any location using their own mobile terminal.  The two
   main functions of HMMP are registration, and mobility support. The
   registration involves assigning new address to a roaming mobile and
   authenticating it whenever necessary; while the mobility support
   comprises re-invitation, and/or tunneling via address binding. Let us
   explain how one can utilize and extend SIP to perform these
   functions.

4.1 Registration

   SIP REGISTER method allows users to register with the network and
   enable them to access the network from any terminal on the network.
   HMMP utilizes SIP to register and configure mobile terminals.  There
   are two ways to use SIP for mobile registration. The first approach
   requires no extension/modifications of SIP, while the second requires
   certain modifications and extensions of SIP.



ITSUMO Group                                                   [Page 16]


Internet-Draft     Host Mobility Management Protocol        October 1999


4.1.1 Registration: Approach 1

   The first registration approach utilizes the dynamic host
   configuration protocol (DHCP) [11], and SIP REGISTER and recently
   proposed INFO method [12] to perform the registration.  It operates
   as follows.

   + The mobile station (MS) requests a new address from DHCP.
   + DHCP assigns a temporary address to the MS.
   + The MS uses SIP REGISTER method with its temporary IP address as
     CONTACT in the REGISTER method. Note that if this registration is
     trigrred by the roaming of the MS in the middle of an ongoing
     session (i.e., re-registration), then the visiting registrar (VR)
     shall authenticate it with the home registrar (HR).

   The signaling flow for the registration is depicted in Figure 6. The
   MS broadcasts a DHCPDISCOVER message to the DHCP servers.  Several
   servers offer a new address to MS via DHCPOFFER; the MS selects one
   and sends a DHCPREQUEST to the corresponding DHCP server. The DHCP
   server send a DHCPACK to confirm the assignment of the address to the
   MS.  Simultaneously, the DHCP SHALL update the DNS address to name
   and name to address mappings. For instance, the DHCP can use the
   Dynamic DNS updates mechanism [RFC 2136] to perform the DNS mapping
   update [15].  Figure 6, does not show the DNS update in detail.  The
   MS sends a SIP REGISTER message whose CONTACT is set to the MS's new
   address to the visiting registrar (VR) that contains the service
   profile of the MS. The VR uses the SIP INFO method to send MS's
   profile to the HR for authentication.  The HR responds to the VR with
   a SIP OK if authentication is successful, otherwise, HR responds with
   a "603 Decline" response.  Then, the VR sends a SIP OK to the MS to
   confirm its registration with the visiting network.  Therefore,
   additional requirements for supporting this registration approach are
   the followings.

   - The DHCP SHALL interact with the DNS and update it dynamically.
   - The SIP INFO method SHALL be able to convey the question "Is profile
     [....] valid? " to the HR in the method message body.

     MS                   DHCP (several servers)   VR                 HR
      |     DHCP DISCOVER     |                    |                  |
      |---------------------->|                    |                  |
      |    DHCP OFFER         |                    |                  |
      |<----------------------|                    |                  |
      |   DHCP REQUEST        |                    |                  |
      |---------------------->|                    |                  |
      |     DHCP ACK          | DNS Update         |                  |
      |<----------------------|------------>       |                  |
      |                       |                    |                  |



ITSUMO Group                                                   [Page 17]


Internet-Draft     Host Mobility Management Protocol        October 1999


      |     SIP REGISTER      |                    |                  |
      |-----------------------|------------------->|                  |
      |                       |                    |    SIP INFO      |
      |                       |                    |----------------->|
      |                       |                    |    SIP OK        |
      |                       |                    |<-----------------|
      |                       |      SIP OK        |                  |
      |<----------------------|--------------------|                  |
      |                       |                    |                  |

   Figure 6. The signaling flow for the registration: Approach 1

   Assuming that the processing time is negligible, the maximum
   registration time using this approach equal to sum of the round trip
   (MS-DHCP-MS), the round trip (MS-VR-MS), and the round trip (VR-HR-
   VR) delays. The first term represents the time it takes to get a new
   address, the second and third is the registration time. The
   registration time comprises the time for mobile's interaction with
   the SIP registrar as well as the time it takes the VR to communicate
   with the HR in order to authenticate the mobile.

   In order to reduce the impact of roaming on the performance of
   interactive real-time services, it is essential to minimize the
   registration time of a mobile in a visiting network. As Figure 6
   indicates this goal can be achieved through minimizing the mobile
   authentication time as well address acquisition time.  The mobile
   authentication can be expedited through replicating a mobile's
   profile in networks that are most likely to be visited by the mobile
   [13]. This profile replication reduces the registration time by a
   VR-HR-VR round trip, though it increases the control load due to
   profile administration, and its effective realization requires
   continuous monitoring of user's mobility patterns.  An approach that
   augments the SIP registrar with DHCP functions and reduces the
   address acquisition time is described in Section 4.1.2.

4.1.2 Registration: Approach 2

   In a nutshell, this approach equips the SIP registrar with DHCP
   functions so that the address acquisition time is reduced.
   Realization of this approach requires the modification of SIP
   REGISTER method so that if the CONTACT field is set to a default
   registration/hand-off (i.e., "RHO") value , the SIP registrar (i.e.,
   registration server) shall also ask for a temporary address for the
   mobile. The registrars shall be equipped with a DHCP client as well
   as shall be co-located with a DHCP server that allows it to assign IP
   addresses to the mobiles. This registration algorithm operates as
   follows:




ITSUMO Group                                                   [Page 18]


Internet-Draft     Host Mobility Management Protocol        October 1999


   + The mobile uses a SIP REGISTER method with CONTACT = "RHO" to
     re-register as well as get it a new address. When the visiting
     registrar (VR) receives this message
     - the VR assigns a new temporary address to the mobile, i.e., its DHCP
       client ask for an address from its DHCP server,
     - the VR and HR interact to authenticate the mobile, if the
       authentication fails, VR sends a 603 Decline message to the mobile,
       otherwise,
       * the VR DHCP server updates the DNS, and
       * the VR send the temporary address to the mobile in the 200
         response as Contact header field.

   Assuming negligible processing time, the maximum registration time
   equals the sum of the round trip (MS-VR-MS), and round trip round
   trip (VR-HR-VR) delays. Like approach 1, a profile replication method
   may be used to eliminate the round trip delay (VR-HR-VR) involved in
   authentication, and minimize the registration time. The key
   advantages of this scheme (compared to approach 1) are that it

   a. reduces the address acquistion time becuase the registrar itself
      can assign new address, and
   b. protects network resources against fraud because the registrar
      authenticates the MS before sending the MS its new assigned
      address.

   The signaling flow of this registration procedure is shown in Figure
   7. Note that Figure 7 does not depict DNS update process in detail.


     MS                              VR                              HR
      |                               |                               |
      |         SIP REGISTER          |                               |
      |         CONTACT="RHO"         |                               |
      |------------------------------>|                               |
      |                               |           SIP INFO            |
      |                               |------------------------------>|
      |                               |             SIP OK            |
      |                               |<------------------------------|
      |                               |                               |
      |               SIP OK          |    DNSUpdate                  |
      |<------------------------------|---------->                    |
      |                               |                               |
      |                               |                               |

   Figure 7.  The signaling flow for registration: Approach 2

   The followings are additional requirements for supporting this
   registration approach with SIP.



ITSUMO Group                                                   [Page 19]


Internet-Draft     Host Mobility Management Protocol        October 1999


   ** The SIP REGISTER method SHALL designate a "RHO" CONTACT that allows
      the registrar to obtain a new address from the DHCP on behalf of
      the mobile.
   ** The DHCP sever of VR SHALL either update the DNS dynamically or a
      new protocol be developed to allow applications to use SIP
      registrar for name to address and address to name mappings.

   An interesting question is how does the SIP registrar inform the
   mobile about its new address?  The answer is exactly the way DHCP
   does it. The TCP(UDP)/IP software should accept and forward to the IP
   layer any IP packets delivered to the mobile's hardware address
   before its IP address is configured. The SIP registrar may use the
   limited broadcast IP address to force the IP layer to broadcast the
   registrar's response on the subnet so that it is delivered to the
   mobile's hardware address before the TCP(UDP)/IP software of the
   mobile is configured. If mobiles can accept hardware unicast
   datagrams before their TCP(UDP)/IP software are configured, the
   registrar may use this capability to deliver the mobile's
   new/temporary address.

   I believe the fact that VR is equipped with DHCP client and server
   capabilities is consistent with RFC 2543 requirement that explicitly
   states a SIP registrar cannot act as a SIP client. However, this
   point should be examined further.

4.2 Mobility Support

   The mobility support comprises two functions, i): location service,
   i.e., locating mobile users in response to new incoming session
   requests, and ii): hand-off, i.e., ensuring soft hand-off as the
   mobile user roams across subnets and/or domains. What follows
   describes how HMMP uses SIP to support these functions.

4.2.1 Location Service

   The mobile has moved to a new location when a corresponding host
   initiates a session. In this case, HMMP sets up the session as
   follows:
   - The corresponding host invites the mobile station (i.e., MS),
   - A SIP redirect server (SIP-RS) answers that the mobile is moved to a
     new location (i.e., temporary address),
   - The corresponding host re-invites the mobile at the temporary
     address, and
   - a session is set up between the corresponding and mobile hosts, and
     the data transfer begins.

   Figure 8 depicts the signaling flow for location service.




ITSUMO Group                                                   [Page 20]


Internet-Draft     Host Mobility Management Protocol        October 1999


      CH                            SIP-RS                           MS
      |                               |                              |
      |      SIP INVITE               |                              |
      |------------------------------>|                              |
      | 302: Moved Temporarily        |                              |
      |<------------------------------|                              |
      |            SIP INVITE         |                              |
      |-------------------------------|----------------------------->|
      |                               |             SIP OK           |
      |<------------------------------|------------------------------|
      |          User Data            |                              |
      |-------------------------------|----------------------------->|
      |                               |                              |

   Figure 8.  The signaling flow for location service

   The corresponding host sends a SIP INVITE message to the mobile
   station. A redirect server that has intercepted the INVITE message
   sends a 302 (i.e., moved temporarily) redirection message to the
   corresponding host with the mobile's new/temporary address as its
   Contact header field. The corresponding host sends a SIP INVITE
   message to the new address, the mobile responds with a SIP OK, and
   the data transfer begins. Since the DHCP dynamically updates the DNS
   mappings, new TCP connections are established using the most recent
   IP address of the mobile.

4.2.2 Hand-off

   To ensure soft hand-off, HMMP should re-establish a new session
   between the corresponding host and the mobile station (MS) at its new
   location, and create a short-lived tunnel for forwarding the
   transient data of the session to the mobile station's new location.
   When the MS moves to a new location during the session, The MS re-
   registers (using either of registration methods described in Section
   4.1) and obtains a new address. Then, HMMP provides means of hand-off
   as follows:

   + A new session with the same session ID is created between
     corresponding host (CH) and the mobile. In order to create a new
     session, the MS (or SIP server) re-invites the corresponding host to
     the new address of the MS.
   + The MS or SIP server uses the SIP INFO method to create a
     short-lived tunnel between the previous MSC and the new MSC to
     reduce the loss of session transient data. In order to create the
     tunnel
     - The MS or SIP server sends an INFO message to the previous MSC
       (P-MSC) which is the same as the default gateway of the MS before
       getting its new address, and



ITSUMO Group                                                   [Page 21]


Internet-Draft     Host Mobility Management Protocol        October 1999


     - binds the old address of the mobile with its new one, so that
       transient messages are forwarded to the new address of the MS, and
       packet loss is reduced. The expire filed of the INFO method is used
       to specify the tunnel lifetime (i.e., a time-out period after which
       the tunnel is discontinued). The exact algorithm for determining the
       tunnel lifetime requires further study.
   + The MS SIP user agent also sends an INFO message to the SIP user
     agent of any corresponding host whose address is in the MS's SIP-EYE
     record of ongoing TCP connections so that each corresponding host
     binds the original IP address of the MS to its current (i.e., new)
     IP address.

   Note that the P-MSC uses IP encapsulation [19, 20] to create a tunnel
   for forwarding the transient packets to the mobile's new location.
   The key requirement for the realization of the tunneling process is
   that each MSC SHALL have a SIP user agent. The signaling flow for
   hand-off is shown in Figure 9.

            MS has already registered as shown in Figures 6 or 7.
     MS                               CH                            P-MSC
     |                                 |                              |
     |        SIP INVITE               |                              |
     |-------------------------------->|                              |
     |                                 |            SIP INFO          |
     |---------------------------------|----------------------------->|
     |        SIP INFO                 |                              |
     |-------------------------------->|                              |
     |                   SIP OK        |                              |
     |<--------------------------------|                              |
     |                                 |             SIP OK           |
     |<--------------------------------|------------------------------|
     |        User Data                |                              |
     |-------------------------------->|                              |
     |                                 |                              |

   Figure 9.  The signaling flow for hand-off

   It is worth noting that Figure 9 shows an instance of the signaling
   flow for hand-off.  The exact sequence of SIP OK responses from the
   P-MSC and CH SIP user agent to the MS SIP user agent depends on the
   round trip delay between these entities as well as the network
   traffic these messages encounter as they traverse the network. In
   summary, additional requirements for supporting hand-off are the
   following.

   - The SIP user agent SHALL be equipped with a SIP_EYE agent that
     tracks TCP connections in the MS.  - The SIP_EYE agent SHALL
   maintain a state comprising the <original MS



ITSUMO Group                                                   [Page 22]


Internet-Draft     Host Mobility Management Protocol        October 1999


     IP address, previous MS IP address, current MS IP address, original
     corresponding host IP address> per TCP connection within the SIP
     user agent of the MS.  - The SIP user agent SHALL keep the address
   of the last default
     gateway (i.e., previous MSC) before hand-off).  - The SIP user
   agent SHALL understand address binding INFO messages
     and take necessary actions. - The SIP INFO method SHALL support
   address bindings, i.e., understand
     a "Bind [address 1] to [address 2] " instruction in the method
     message body.

5. The SIP_EYE Agent

   The whole premise of the SIP_EYE agent is to ensure that HMMP
   supports TCP as is without any modifications to TCP. SIP_EYE SHALL be
   a simple TCP tacking/monitoring agent with small footprint residing
   within the SIP user agents of mobile stations (MSs) and corresponding
   hosts (CHs). Its functions are to

   a) identify and track ongoing TCP connections of a mobile station, and
   b) maintain a list of ongoing TCP connection identifiersand their
      respective corresponding hosts so that the SIP user agent of the
      mobile sends them INFO messages to bind the original IP address of
      the mobile with its current one.

   The SIP_EYE agent tracks both the transmitted and received TCP
   packets concurrently to create and update the list of ongoing TCP
   connections in the MS. It runs two concurrent monitoring and updating
   processes, one for tracks the transmitted packets, and the other
   received ones. The role of SIP_EYE in hand-off of TCP connections has
   already been discussed in detail. The following pseudo-code describes
   the basic TCP tracking operation of the SIP_EYE agent for the
   simplest case.


       // SA: Source address of a packet.
       // DA: Destination address of a packet.
       // SYN: Synchronization code bit
       // ACKB: Acknowledgment code bit
       // FIN: Sender end of byte stream code bit
       // SEQ: Sequence number
       // ACKN: Acknowledgement number

       // Auxiliary variables
       //  CL_ID: Connection Label ID
       //  STAT: Connection Status
       //     STATUS takes values, Setup_Req, Setup_Prog, Established,
       //     Release_Req, Release Ack, Release Accpet, Disconnect)



ITSUMO Group                                                   [Page 23]


Internet-Draft     Host Mobility Management Protocol        October 1999


       //
       // The TX SIP_EYE Entity.

   for (;;) {
                  Capture the header of transmitted TCP packets;
      if (SYN = 1 & ACKB = 0) {
       Add a TCP entry as follows to the temporary list of connections
            <    original MS IP address = SA;
                 previous MS IP address = SA;
                 current MS IP address = SA;
                 original corresponding IP address = DA;
                 CL_ID = SEQ;
                 STAT = Setup_Req; >
                 }
       else if (ACKB = 1 & SYN =0) {
         Get the STAT of the TCP entry,
               < original MS IP address = SA;
                 previous MS IP address = SA;
                 current MS IP address = SA;
                 original corresponding IP address = DA;
                 CL_ID = ACKN-1;
                 STAT  =   **; >
                 if  ( STAT = Setup Prog ) Set STAT = Established;

       // A TCP connection is added to the table of ongoing connections.
                 if else (STAT = Release_Ack) {
                 Set STAT = Disconnect;
                 Remove the TCP entry from the table of ongoing connections.
                 }
                 else
                 Error!;
         }
       else if { ACKB =1 & FIN = 1 ) {
        Reset the CL_ID and STAT of the ongoing TCP entry,
        < original MS IP address = SA;
          previous MS IP address = previous MS IP address;
          current MS IP address = current IP address of the mobile;
          original corresponding IP address = DA;
          CL_ID = ** ;
          STAT = Established; >
       to
          CL_ID = SEQ;
          STAT = Release_Req;
         }
    }






ITSUMO Group                                                   [Page 24]


Internet-Draft     Host Mobility Management Protocol        October 1999


        // The RX SIP_EYE Entity. It is similar to TX entity and they
        // both run concurrently to manage a single TCP connection list.

   for(;;) {
      Capture the header of  received TCP packets;
        if (SYN = 1 & ACKB = 1) {
          Reset the STAT of the TCP entry ;
          < original MS IP address = DA;
            previous MS IP address = DA;
            current MS IP address = DA;
            original corresponding IP address = SA;
            CL_ID = ACKN-1;
            STAT = Setup_Req; >
      to
            STAT =  Setup_prog;
            }
        else if (SYN = 0 & ACKB =1) {
          Reset the STAT of  TCP_entry;
           < original MS IP address = DA;
             previous MS IP address = DA;
             current MS IP address = DA;
             original corresponding IP address = SA;
             CL_ID = ACKN-1;
             STAT = Release_Req; >
       to
             STAT = Release_Ack;
         }
         else if { ACKB =1 & FIN = 1) {
         Reset the STAT of TCP entry
           < original MS IP address = DA;
             previous MS IP address = previous MS IP address;
             current MS IP address = current IP address of the mobile;
             original corresponding IP address = SA;
             CL_ID = ACKN-1;
             STAT = Release_Ack; >
      to
             STAT = Release_ACK;
          }

     }

       // Update of ongoing TCP connection list upon hand-off.
       // new  MS IP address: The new address that has been assigned to the
       // mobile upon hand-off.

   if (hand-off) {
     while (!eof ongoing list) {
     <  original MS IP address = original MS IP address;



ITSUMO Group                                                   [Page 25]


Internet-Draft     Host Mobility Management Protocol        October 1999


        previous MS IP address = current MS IP address;
        current MS IP address = new MS IP address;
        original corresponding IP address = original corresponding IP address;
        CL_ID = **;
        STAT = Established;
     }


   The preceding pseudo-code describes the basic operation of SIP_EYE in
   an environment whose packet error or loss ratio is negligible and no
   connection set-up message of TCP is lost or corrupted. It shall be
   refined further so that it becomes robust enough for use in a
   wireless environment that has relatively (compared to wireline
   networks) high packt loss and error and TCP set up messages may be
   lost or corrupted.  Furthermore, the interactions of the SIP_EYE
   agent with the entities of current SIP user agent as well as its
   integration within the SIP user agent require further study.

6. Impact of Mobility on SIP Specifications

   Having described HMMP, let us summarize requirements for supporting
   mobility on SIP via HMMP or other protocols. The requirements are the
   following.

   **  The SIP INFO method SHALL be able to convey the question, "Is the
       profile [....] valid? ", to the HR in the message body of INFO
       method.
   **  The SIP INFO method SHALL support address bindings, i.e.,
       understand a "Bind [address 1] to [address 2] " instruction in the
       message body of the INFO method.
   **  The SIP REGISTER method SHALL designate a "RHO" CONTACT that
       allows the registrar to obtain a new address from the DHCP on
       behalf of the mobile.
   **  The SIP user agent SHALL be equipped with a SIP_EYE agent that
       tracks TCP connection.
   **  The SIP_EYE agent SHALL maintain a state comprising the <original
       MS IP address, previous MS IP address, current MS IP
       address, original corresponding IP address> per TCP connection.
   **  The SIP user agent SHALL keep the address of the last default
       gateway (i.e., previous MSC) before hand-off).
   **  The SIP user agent SHALL understand address binding INFO messages
       and take necessary actions.
   **  The DHCP sever of VR SHALL either update the DNS dynamically or a
       new protocol be developed to allow applications to use SIP
       registrar for name to address and address to name mappings.

   Except for the interaction between DHCP and DNS, SIP specifications
   SHALL support other functions/requirements so that SIP can support



ITSUMO Group                                                   [Page 26]


Internet-Draft     Host Mobility Management Protocol        October 1999


   signaling needs of roaming users in 3G-IP networks.

7. Summary and Open Issues

   This document has presented the preliminary specifications of HMMP,
   and identified the impact of mobility on SIP and proposed necessary
   extensions to ensure that SIP can support roaming users adequately.
   HMMP is a protocol that supports real-time and non-real-time
   multimedia applications on mobile terminals of 3G-IP networks. HMMP
   utilizes as well as extends session initiation protocol (SIP) to
   provide means of domain hand-off (i.e., roaming), and subnet-off
   (i.e., macro mobility) so that users can access the network from any
   location using their own mobile terminal.  HMMP can spoof constant
   endpoints for mobile TCP connections and supports mobile TCP
   applications without any changes to the TCP. Among the open issues
   that may influence SIP specifications and require further study are:


   -- the specifications of a resource reservation mechanism for
      supporting real-time multimedia applications of roaming users in a
      3G-IP network whose signaling system is built on SIP,
   -- the extension of the SIP_EYE specifications so that it is able
      to account for error in and loss of the TCP connection set-up
      packets, and to interact and co-operate with the current SIP user
      agent as defined in RFC 2543,
   -- the specifications of AAA entity, and
   -- interworking with the PSTN.

8. Acknowledgments

   The authors wish to acknowledge the contributions of other members of
   the ITSUMO(TM) team from Telcordia (P. Agrawal, , S. Das, D.
   Famolari, A. McAuley, P. Ramanathan, and R. Wolff) and Toshiba
   America Research Incorporated (T. Kodama).

   (TM): ITSUMO (Internet Technology Supporting Universal Mobile
   Operation) is a trademark of Telcordia. It is a joint research
   project of Telcordia Technologies and Toshiba America Research Inc.
   (TARI). It envisions an end-to-end wireless/wireline IP platform for
   supporting real-time and non-real-time multimedia services in the
   future.  Its goal is to use IP and third generation wireless
   technologies to design a wireless platform that allows mobile users
   to access multimedia services on a next generation Internet. In
   Japanese, ITSUMO means anytime, always.

9. References

   1. D. Barboza, "Motorola and Sun to Build Joint System for Net



ITSUMO Group                                                   [Page 27]


Internet-Draft     Host Mobility Management Protocol        October 1999


   Access", The New York Times, June 10, 1999.

   2. Cnnfn Industry Watch, "NOKIA: Industry leaders for focus group to
      promote third generation wireless IP Technology", June 11, 1999.

   3. Telcordia Technologies, "Voice Over Packet in Next Generation
      Networks: An Architectural Framework", Bellcore SR-4717, Issue1,
      January 1999.

   4. ITU-R Rec. M.687-2, "International Mobile Telecommunications-2000
      (IMT-2000)", 1997.

   5. ITU-R Rec. M.817, "International Mobile Telecommunications-2000
      (IMT-2000)", Network Architectures", 1992.

   6. ITSUMO Group, "Evolution of Wireless Telephony towards Voice over
      3G-IP", 3GPP2- P00-19990824-010, August 23, 1999.

   7. ITSUMO Group, "A Service Profile for 3G-IP Wireless Networks",
      3GPP2-P00-19990927-009, September 27, 1999.

   8. ITU-R Rec. M.816-1, "Framework for Services Supported on
      International Mobile Telecommunications-2000 (IMT-2000)", 1992.

   9. IETF, "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   10. IETF, "SDP: Session Description Protocol", RFC 2327, April 1998.

   11. IETF, "Dynamic Host Reconfiguration Protocol", RFC 2131, March
       1997.

   12. S. Donavon, "The SIP INFO Method",
       <draft-ietf-mmusic-sip-info-method-01.txt>, work in progress,
        June 1999.

   13. D. Lam, Y. Cui, D.C. Cox, and J. Widom, "A Location Management
       Technique To Support Lifelong Numbering in Personal
       Communications", January 1998.

   14. A. McAuley, S. Das, and S. Baba, Y. Shobatake, "Dynamic
       Registration and Configuration Protocol for Mobile Hosts",
       <draft-itsumo-drcp-00.txt>, work in progresss, October 1999.

   15. Y. Rekhter, and M. Stapp, "Interaction between DHCP and DNS",
       <draft-ietf-dhc-dhcp-dns-10.txt>, work in progress, June 1999.



ITSUMO Group                                                   [Page 28]


Internet-Draft     Host Mobility Management Protocol        October 1999


   16. E. Wedlund, and H. Schulzrinne, "Mobility Support using SIP", ACM
       Multimedia Workshop, Seattle, August 1999.

   17. IETF, "IP Mobility Support", RFC 2002, October 1996.

   18. C. Perkins, and D. B. Johnson, "Route Optimization in Mobile IP",
       <draft-ietf-mobileip-optim-08.txt>, February 25, 1999.

   19. IETF, "IP Encapsulation within IP", RFC 2003, October 1996.

   20. IETF, "Minimal Encapsulation within IP", RFC 2004, October 1996.

   21. IETF, "Resource reSerVation Protocol (RSVP) -- Version 1
       Functional Specification", RFC 2205, September 1997.
   22. DCS Group, "Integration of Resource Management and Call
       Signaling for IP Telephony", <draft-dcsgroup-mmusic-resoure
       -00.txt>, work in progress, August 1999.

10. Authors' Addresses

   Faramak Vakil
   farm@research.telcordia.com
   Telcordia Technologies, Rm 1C-135B,
   445 South Street, Morristown,  NJ  07960-6438.

   Ashutosh Dutta,
   adutta@research.telcordia.com
   Telcordia Technologies, Rm 1B-217B
   445 South Street, Morristown,  NJ  07960-6438.

   Jyh-Cheng Chen,
   jcchen@research.telcordia.com
   Telcordia Technologies, Rm 1G-236B,
   445 South Street, Morristown,  NJ  07960-6438.

   Shinichi Baba
   sbaba@tari.toshiba.com
   Toshiba Research America Inc. (TARI)
   P. O. Box 136
   Convent Station, NJ 07961-0136

   Yasuro Shobatake
   yasuro.shobatake@toshiba.co.jp
   Toshiba Research America Inc. (TARI)
   P. O. Box 136
   Convent Station, NJ 07961-0136
















ITSUMO Group                                                   [Page 29]