Subject: I-D draft-itsumo-sip-mobility-req-01.txt

From: Faramak Vakil <[email-masked]>
Date: Fri, 24 Mar 2000 14:01:39 -0500

After posting version 00 of the above, we
received several comments. We have updated
the draft accordingly and will post it on the
IETF site after the Adelaide meeting. In the mean-time
attached is a copy for those who are interested.

Regards, Faramak

Internet Engineering Task Force                                  F.Vakil
INTERNET DRAFT                                                  A. Dutta
draft-itsumo-sip-mobility-req-01.txt                      Jyh-Cheng Chen
Date: March 2000                                  Telcordia Technologies
Expires: August 2000
                                                           Shinichi Baba
                                                        Yasuro Shobatake
                                           Toshiba America Research,Inc.

                                                     Henning Schulzrinne
                                                     Columbia University

               Mobility Management in a SIP Environment
                   Requirements, Functions and Issues
                 <draft-itsumo-sip-mobility-req-01.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-mobility-req-01.txt>, and expires August, 2000. Please send
   comments to [email-masked] or [email-masked], or
   [email-masked].

Copyright Notice

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

ABSTRACT

   Mobility is rapidly becoming a rule rather than an exception in

ITSUMO Group                                                    [Page 1]

Internet-Draft  Mobility Management in a SIP Environment      March 2000

   communication services and SIP is gaining widespread acceptance as
   the signaling protocol for multimedia applications on the Internet.
   Thus, it is essential to develop a mobility management scheme that
   utilizes salient features and capabilities of SIP as well as other
   protocols (e.g., mobile IP) to support mobile services efficiently.
   Without providing any specific solution, this document presents
   preliminary requirements and identifies the issues that need to be
   resolved in order to develop a mobility management scheme for
   supporting multimedia applications in a SIP signaling and control
   environment.

1. Purpose and Scope

   The increasing demand for mobile telephony, and the explosive growth
   of the Internet are driving forces behind the current boom in the
   communication industry. On the one hand, mobile wireless telephony is
   rapidly becoming ubiquitous. The difference between the prices of
   mobile and fixed telephone services is diminishing and users demand
   for continuous connectivity is on the rise. Thus, mobility is rapidly
   becoming a rule/norm rather than an exception, and mobile wireless
   applications and appliances are becoming predominant.  On the other
   hand, service/network providers/operators are rapidly expanding their
   IP infrastructure to support the explosive growth of the data traffic
   of the Internet users. The growth of data service market is much
   faster than that of telephony, and providers will invest much more in
   expanding the IP infrastructure than in expanding PSTN. Due to this
   lop-sided growth of the IP infrastructure, it is reasonable to expect
   that mobile and fixed Internet telephony will initially complement
   the 1G/2G mobile and PSTN services in the near future and will
   inevitably displace/replace them in a much longer term. Since SIP [1]
   is gaining acceptance as the signaling protocol of multimedia and
   Internet telephony, it is essential to develop a mechanism for
   supporting multimedia mobile applications in a SIP signaling and
   control environment.

   The key objectives of this document are to

   ** describe the frame work requirements for mobility management in
      general, as well as the mobility management functions and
      requirements in particular,

   ** identify open issues involved in supporting application of roaming
      users in a SIP signaling and control environment, and

   ** include the relevant issues in the agenda of the SIP WG and/or
      other appropriate WGs in the IETF.

   This document is organized as follows: Section 2 provides the overview

ITSUMO Group                                                    [Page 2]

Internet-Draft  Mobility Management in a SIP Environment      March 2000

   of an end-to-end wireless/wireline IP infrastructure. In Section 3, we
   present the general system requirements and considerations for mobility
   management. Section 4 focuses on necessary functions for supporting
   mobility as well as their requirements. Section 5 identifies some of the
   open issues involved in supporting roaming users in a SIP environment,
   and Section 6 summarizes the document.

2. Architecture of an End-to-End Wireless/Wireline IP Infrastructure

   We envision that all services, real-time and non-real-time will
   eventually migrate onto an end-to-end wireless/wireline platform.
   The users have IP stationary and/or mobile appliances and use
   end-to-end IP transport and signaling/control from user terminal
   to user terminal including possible use of IP transport and
   control on the air interface.

   Figure 1 depicts the end-to-end signaling/control and transport
   platform of a wireless/wireline network. It comprises third
   generation (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. The
   3G wireless IP networks allow mobile stations (MSs) to access the
   wireline infrastructure. In order to support the needs of its users,
   a wireless access network interacts with the control entities of
   the end-to-end network.

   As shown in Figure 1, SIP [1] is the basis of the overall control
   architecture of the end-to-end wireline/wireless network. The
   overall control systems comprises SIP servers and agents, MAAAQ
   (mobility management, Authentication, Accounting and Qos management),
   and SIP registrars.  SIP provides connection management as well as
   means of interaction between users and network control system and
   interaction among network control entities. MAAAQ entities support
   mobility management, AAA, and QoS management functions for mobile users.
   These functional entities usually reside on the wireline backbone, and
   are part of the overall control system of the end-to-end platform.

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

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

ITSUMO Group                                                    [Page 3]

Internet-Draft  Mobility Management in a SIP Environment      March 2000

            |                                            |
       +-----------+                                 +-----------+
       |  MAAAQ    |                                 |  MAAAQ    |
       +-----------+                                 +-----------+
       | SIP Server| <-----------------------------> | SIP Server|<....
       +-----------+                                 +-----------+     .
             |                                           |             .
          ___|___              _______                ___|___          .
         /       \            /       \              /       \         .
        /         \          /         \            /         \        .
       /Regional IP\________/  Internet \__________/Regional IP\       .
       \ Network   /        \           /          \ Network   /       .
        \         /          \         /            \         /        .
         \_______/            \_______/              \_______/         .
             |                                             |         SIP
             |                                             |           .
          ___|___                                       ___|___        .
         /       \                                     /       \       .
        /         \                                   /         \      .
       / 3G Access \                                 / 3G Acces  \     .
       \ Network   /                                 \ Network   /     .
        \         /                                  |\         /|     .
         \_______/                                   | \_______/ |     .
             |                                       |           |     .
             |                                       |           |     .
             |                                       |           |     .
             |                                       |           |     .
          +-----+                                 +-----+      +-----+..
          | MS  |                                 | MS  |      |  MS |
          +-----+                                 +-----+      +-----+

      Figure 1.  The end-to-end control and network architecture.

   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 1, the SIP
   server entity of a regional IP network represents the set of SIP
   proxy and SIP redirect servers within the regional network 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) necessary functions, similar
   to those of the home/visiting location registries (HLR/VLR) in today's
   wireless telephony to roaming users. As Figure 1 shows the MAAAQ entity
   uses SIP features and capbilities to support roaming users.  The
   illustration of the MAAAQ entities and SIP server as a single module in
   Figure 1 should not be interpreted as a requirement for having a
   centralized SIP server or MAAAQ entity per regional network. Figure 1
   only shows the required functions, though each of the SIP and MAAAQ

ITSUMO Group                                                    [Page 4]

Internet-Draft  Mobility Management in a SIP Environment      March 2000

   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 requirements,
   functions, and issues that arise in supporting roaming users in such
   an IP wirless-wireline infrastructure.

3. Framework Requirements for Mobility Management

   In general, the mobility management scheme of wireless IP networks
   satisfies the following requirements [2, 6].

      I. It supports means of personal as well as terminal mobility,
         i.e., it allows users to access the network services
         anywhere using their own mobile terminal/station (referred to
         as the mobile station or simply MS, hereafter).

     II. It supports global roaming, i.e., it shall allow users
         to roam across different technology platforms, and across
         subnets within the same administrative domain as well as across
         subnets that belong to different administrative domains.

    III. It is wireless "technology-independent", i.e., it should
         remain independent of the underlying wireless technology.
         This requirement allows the ISPs and network operators to
         upgrade their sub-systems independently and build multi-vendor
         solutions. Furthermore, this requirement ensures that the
         mobility management scheme can be transported over all members
         of the IMT-2000 family which comprises several wireless
         technologies such as W-CDMA, TDMA, etc. [3, 4].

     IV. It supports both real-time and non-real-time multimedia
         services such as mobile telephony, mobile web access, and mobile
         data services in a way that their prices and performance are
         comparable to those of their counterparts in today's mobile
         voice and data services. In order to do so, the mobility
         management scheme should interact effectively with the QoS management
         and authetication, authorization, and authentitcation (AAA) schemes
         of the end-to-end network to verify the users' identities and rights,
         as well as to ensure that the QoS requirements of applications
         are satisfied.

      V. It transparently supports current TCP-based Internet application.
         It should support TCP as is without requiring any changes to TCP
         protocol or TCP-based applications, i.e., it should spoof/maintain
         constant end-points for TCP connections.

ITSUMO Group                                                    [Page 5]

Internet-Draft  Mobility Management in a SIP Environment      March 2000

     VI. It allows a mobile station/user to decide whether it conveys its
         location to correspondent hosts or not. This requirement allows
         users to enhance their confidentiality and privacy, when necessary.

    VII. It supports multicast and anycast trees efficeinetly as mobile
         stations/users move around.

   VIII. Last but not least, it interworks smoothly with PSTN and today's
         1G/2G wireless telephony to facilitate interworking of new operators'
         all IP platforms with PSTN and the existing 1G/2G wireless telephony [5].

4. Mobility Management Functions and Requirements

   Simply speaking, a roaming MS should be able to receive (and send)
   calls/data from (and to) anyone in any place, and maintain its
   ongoing communications with others regardless of its point of
   attachment to the network.  In order to achieve this goal, the
   mobility management scheme shall support hand-off, registration,
   configuration, dynamic address binding, and location management
   whenever necessary. The remainder of this section describes these
   functions as well as their performance requirements in more detail.

4.1 Hand-off

   Hand-off (or handover) is a process that allows a established
   call/session to continue when a MS moves from one cell to another
   (intercell) or between radio channels in the same cell (intracell)
   without interruptions in the call/session. The hand-off process can
   be either hard or soft. In the hard hand-off the mobile receives and
   accepts only one radio signal from a radio channel or base station
   within a single cell.  As the mobile moves into a new cell, its signal
   is abruptly handed over from its current cell (or base station) to the
   new one rapidly in a few seconds.

   With soft hand-off the MS continues to receive and accept radio
   signals from the base stations within its previous as well as its new
   cell for a limited period of timer. Signal reception from the old base
   station ceases when the signal strength drops/reduces below a certain
   threshold. As its name indicates, soft hand-off smoothly transfers the
   MS's session from its old base station to the new one.  All third
   generation CDMA wireless technologies use soft hand-off. The soft
   hand-off process can take a relatively long period (i.e., several seconds),
   particularly, when it includes the entire process of pilot strength
   measurement, issuing of pilot strength measurement message (PSMM) on
   the uplink, and addition of new pilot to active set. In principle,
   soft hand-off is not always a transient process, and may take a long
   time depending on MS's request and requirements.

ITSUMO Group                                                    [Page 6]

Internet-Draft  Mobility Management in a SIP Environment      March 2000

   In order to take advantage of the soft hand-off feature of the third
   generation CDMA wirless technologies in mobile IP packet networks,
   during the soft hand-off period, the packets which are destined for
   a MS shall be routed to both its previous and current locations.
   This routing of packets to the current and previous locations of a
   MS constitutes a logical/virtual soft hand-off at the IP layer.

   The hard hand-off process should take only a few second, while the soft
   hand-off process can take much longer (i.e., about several seconds).
   Nevertheless, in order to ensure the wireless "technology independence"
   requirement of mobility management schemes, we require a maximum acceptable
   hand-off time (MAHT) a few seconds (i.e., MAHT = 2-3 seconds). This
   requirement is acceptable for both hard and soft hand-off mechanisms,
   though it can be relieved significantly in the case of soft hand-off.

   We identify three levels of logical/virtual hand-off: cell, subnet, and
   domain.

   a. Cell hand-off (or micro-mobility): It allows a MS to move from a cell
      to another in a subnet within an administrative domain.

   b. Subnet hand-off (or macro-mobility): It allows a MS to move from a cell
      within a subnet to an adjacent cell within another subnet that belongs
      to the same administrative domain.

   c. Domain hand-off (or global mobility): It allows a MS to move from one
      subnet within an administrative domain to another in a different
      administrative domain.

In general, the cell hand-off is more frequent than subnet hand-off and subnet
   hand-off is more frequent than the domain hand-off. The hand-off process is
   built upon the registration, configuration, dynamic address binding, and
   location management functions. Hand-off process is transparent to users
   and satisfies the following requirements.

     i. All three hand-off processes ensure the integrity, privacy and
        confidentiality of users' information as well as prevent fraud and
        theft of service. They

         -  ensure the security of signaling (e.g., registration) messages to
            prevent eavesdropping and theft of users' data and service
            profiles as well as maintain confidentiality of users' locations,
            and

ITSUMO Group                                                    [Page 7]

Internet-Draft  Mobility Management in a SIP Environment      March 2000

         -  perform the necessary AAA process to verify users' identities and
            their rights to requested resources, and ensure correct and
            non-repudiatable accounting, and

    ii. All three hand-off processes strive to maintain the QoS of the session
        as the MS roams around. For instance, they strive to

         a. minimize the loss of transient data during the hand-off, and

         b. satisfy the delay requirements of real-time applications as a
            MS roams around.

   iii. The domain hand-off latency should not exceed MAHT to ensure continuity
        of real-time sessions.

    iv. The subnet hand-off latency shall not exceed MAHT, though it should be
        much less than domain hand-off latency because it does not usually
        involve AAA process.

   A few points are worth noting. First, the domain hand-off process is
   functionally equivalent to the sum of subnet hand-off and AAA processes.

   Second, the domain hand-off latency is the sum of the registration,
   configuration, and address binding latencies, while location management
   process can be performed after (or concurrent with) the hand-off. Let
   us use a qualitative and intuitive discussion to estimate rough upper
   bounds of the registration and configuration latencies. Let us assume that
   processing delay is negligible, and the upper bound on the soft hand-off
   latency, MAHT is about 2-3 seconds.  The address binding latency is at
   most an end-to-end (source - destination - source) round trip queueing and
   propoagation delay. The round trip propagation delay for continental U.S.
   is about 50 ms (i.e., New Seattle - Miami - Seattle). Assuming an address
   binding delay of 1 second, we are left with less than 1-2 seconds
   for both registration and configuration delays. The goal is to get the
   confiuration latency down to millisecond (e.g., a few hundred milliseconds,
   and bounded mostly by the speed of the access link) [15].  Thus, with soft
   hand-off registration latency shall not exceed 1-2 seconds. The preceding
   back of the envelop calculation indicates that that registration and
   configuration should take roughly 1-2 seconds though thorough measurements
   are needed to establish precise upper bounds on the registration and
   configuration latencies.

   Third, in order to satisfy the "wireless-independence" and global roaming
   requirements, the hand-off processes minimize their reliance on the
   link layer.  To achieve this goal, the subnet and domain hand-off processes
   remain completely independent from the link layer, while the cell hand-off
   (i.e., micro-mobility) strives to minimize its dependence on the link layer
   specifications.

ITSUMO Group                                                    [Page 8]

Internet-Draft  Mobility Management in a SIP Environment      March 2000

4.2 Registration

   Registration is a process by which a network becomes aware of the existence
   and the location of an MS and its associated user. When an MS becomes active
   (i.e., is turned on) in a network or roams into a new subnet or domain, it
   shall register with the network. This process comprises sending a
   registration request from the MS to the network, and performing an AAA
   (i.e., authentication, authorization, and accounting) process by the network,
   and sending appropriate responses to the MS as well as location management
   entities to ensure that the network is aware of MS's current location.
   There are two types of registration, complete and expedited (or partial).

   a. Complete Registration: This process occurs when a user turn on its MS
      or roams into a new administartive domain (i.e., during domain hand-off).
      In this case, the network shall perform AAA, and send appropriate
      responses to the MS and location management entities.

   b. Expedited/Partial Registration: This process is invoked when a user
      moves from one subnet to another within the same administrative domain
      (i.e., subnet hand-off). It does not include AAA process of complete
      registration, and its main objective is to keep the location information
      up to date.

   The complete registration process should not take more than 1-2 seconds
   to be performed. The expedited registration process usually takes much less
   than the complete registration process.

4.3 Configuration

   Configuration is a process by which a MS updates its IP address as it roams
   between subnets either within the same administrative domain or in different
   administrative domains. As an MS moves between subnets (either within the
   same domain or in different ones), it needs to acquire a new IP address,
   possibly new default gateway, subnet mask, etc. as well, and to reconfigure
   itself accordingly.

   The key requirements of the reconfiguration process are that it

   ** should not take more than a few hundred milliseconds to complete, and

   ** should update the DNS to reflect the current address to name and name
      to address mappings, if necessary.

   If the underlying wireless platform supports soft hand-off, the reconfiguration
   process can take more time. However, a few hundred milliseconds upper bound
   should be acceptable for both soft hand-off and hard hand-off.

4.4 Dynamic Address Binding

ITSUMO Group                                                    [Page 9]

Internet-Draft  Mobility Management in a SIP Environment      March 2000

   Dynamic address binding is a process for allowing an MS to maintain a
   constant identifier regardless of its point of attachment to the network.
   Dynamic address binding

   ** allows a user to maintain a universal identifier (e.g., a SIP URL)
      regardless of its point of attachment to the network, and

   ** facilitates support of TCP-based applications by informing each endpoint
      about the current address of the other one.

   Needless to say that required signaling for dynamic address binding should
   be secure to ensure privacy and location confidentiality and protect users
   against fraud.

4.5 Location Management

   Location management is a process by which the network updates the location
   database and supports location/redirect services to authorized users and
   authorities. The location service is essential only for new inbound sessions.
   Key requirements of location management are accuracy, being up to date,
   and confidentiality of the location information. The location information

   ** should be up to date and accurate, e.g., the domain name service shall
      ensure correct name to address and/or address to name mapping as soon
      as possible, and

   ** should only be disclosed to authorized users and relevant authorities
      within the scope of the law.

4.6 Required Functions for Cell, Subnet, and Domain Hand-off

   Table 1 summarizes the functions that are needed for supporting each level
   of hand-off, cell, subnet and domain.

   -------------|--------------|---------------|-----------------|------------
   Hand-off type| Registration | Configuration | Address Binding | Location
                |              |               |                 | Management
   -------------|--------------|---------------|-----------------|------------
   Cell         |  NO          | NO            |  Yes            | Yes
   -------------|--------------|---------------|-----------------|------------
   Subnet       |  NO          | Yes           |  Yes            | Yes
   Intra-domain |              |               |                 |
   -------------|--------------|---------------|-----------------|------------
   Domain       |  Yes         | Yes           |  Yes            | Yes
   Inter-domain |              |               |                 |
   -------------|--------------|---------------|-----------------|------------

   Table 1. Required functions for supporting different levels of hand-off

ITSUMO Group                                                   [Page 10]

Internet-Draft  Mobility Management in a SIP Environment      March 2000

5. Issues in Supporting Mobility in a SIP Environment

   Having described mobility management and its requirements, let us identify
   a preliminary list of open issues that arise in supporting these
   requirements in a SIP control environment for further study.

5.1 Supporting macro and global mobility for multimedia applications
    of roaming users

   In principle, mobile IP provides means of macro and global mobility for
   non-real-time services. It provides means of terminal mobility as well as
   dynamic address assignment using network access identifier (NAI). However,
   mobile IP by itself does not provide means of personal mobility and
   location service. Furthermore, the impact of the triangular routing (in
   classic mobile IP) and route optimization scheme on the QoS requirements
   of real-time services requires further study. Different approaches for
   either coexistence of SIP and mobile IP [10, 14], or the development of
   a new SIP based mobility management protocol [11] have been proposed.
   However, the interaction of mobile IP with and its impact on the SIP
   signaling scheme of real-time services requires further study to determine
   the best approach for combining the salient features of mobile IP terminal
   mobility with those of the SIP personal mobility. Such an approach should

   ** spoof constant endpoints for TCP connections and support TCP as is without
      any modification to TCP protocol or TCP-based applications, and

   ** require RTP [16] applications to accept packets with the same
      synchronization source (SSRC) but different source IP address.

5.2 Complete registration in less than a few seconds

   Registration in a mobile environment has two objectives, informing
   the network about the MS (or user) and its location, and verifying
   the MS identity and services that the MS is entitled to. Using SIP
   REGISTER method, one can adequately achieve the former in the MS's
   home network. However, the latter is an essential required function
   that allows MSs to roam among different administrative domains. One
   can conceive several alternatives for performing complete registration.

   One alternative is that the MS utilizes a separate protocol such as
   DRCP [12] or mobile IP [10] to register with the network, and then
   uses the SIP REGISTER method to register with a SIP registrar that
   provides location service as well. In this case, the registration
   process places no additional requirements on SIP.

   Another alternative is that the registration process is done via SIP
   and SIP registrars of different domain interact with one another to
   verify a user's identity and rights using an AAA mechanism and

ITSUMO Group                                                   [Page 11]

Internet-Draft  Mobility Management in a SIP Environment      March 2000

   acknowledge or deny the registration. In this case, SIP registrars
   shall be able to utilize/interact with an AAA scheme to adequately
   perform mobile registration. Moreover, though NOT necessarily a SIP
   issue, it essential to have a fast and scalable AAA mechanism for wide
   area networks that can authenticate and authorize a MS and its user in
   less than a few seconds. See McAuley, et-al. [13] for further details
   on AAA requirements and constraints.

5.3 Reconfiguration in fractions of a second

   This requirement is an important one. It does not seem to impose any
   requirements on SIP, however, it places significant requirements on
   DHCP (see McAuley, et al. [15] for further details). As the MS roams
   into a new subnet or a new administrative domain, it may need to acquire
   a new address before being able to register. In order to do so, the MS
   interacts with DHCP [7] to obtain a new IP address, and reconfigure
   itself. Currently, it takes DHCP several seconds to reconfigure a host. This
   latency is usually too much for mobile users. Different schemes such as
   fast DHCP that does not perform conflict resolution, and or novel schemes
   such as dynamic registration and configuration (DRCP) [12] have been
   proposed to reduce the reconfiguration delay of a MS. Moreover, DHCP
   may need to interact with DNS and update it dynamically so that the name
   to address mappings remain current. Further study is needed to arrive at
   appropriate solutions for these issues.

5.4 Providing location service

   As the MS roams around it should update its location so that authorized
   users can direct their new calls/sessions the MS's current location. Among
   the approaches for providing location service are

    a. the dynamic update of the DNS, and

    b. the development of a brand new protocol that allows applications
       to use SIP registrar for name to address and address to name
       mappings.

   Neither of these approaches seems to have any impact on SIP specifications,
   though the latter should be built upon the SIP specifications and use
   SIP methods.

5.5 Supporting the soft hand-off procedure

   The third generation CDMA wireless technologies all support soft hand-off
   procedure which allows a roaming MS to receive and accept signals from
   both its new base station as well the old one simultaneously during the
   soft hand-off period (about several seconds). In order to utilize this
   feature the macro and global mobility scheme shall emulate a virtual soft

ITSUMO Group                                                   [Page 12]

Internet-Draft  Mobility Management in a SIP Environment      March 2000

   hand-off at the IP layer via forwarding the session's packets to the old
   as well as the new location of the MS during the soft hand-off. In order
   to support virtual soft hand-off, SIP shall be able to extend the ongoing
   session to the new location of the MS, and drop the old location after a
   limited period of time. The exact mechanism for realizing virtual soft
   hand-off requires further study.

5.6 Providing secure signaling for mobile users

   Due to the ease of "wire-tapping" in a wireless environment, the signaling
   and user data should be encrypted to ensure privacy and confidentiality of
   users and protect them against fraud and theft of service. SIP messages can
   already be encrypted. Nevertheless, the SIP WG has chartered a task force to
   identify and address issues (e.g., key management) that arise in enhancing
   SIP security mechanisms. The SIP security task force should address this
   problem in the context of wireline as well as wireless networks.

6. Summary and Conclusions

   This document focused on supporting mobility in a SIP signaling and
   control environement. It identified the functions, requirements, and
   open issues so that they are included in the agenda of the SIP WG as
   well as other appropriate WGs of IETF in a timely manner.

7. 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). We also thank P. Zablocky
   and J. C. Liberti from Telcordia for helpfull discussions on soft
   hand-off procedures.  Special thanks are due to Glenn Morrow from
   Nortel Networks for his comments on version 00 of this document.

   (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, all the time.

8. References

   1. M. Handly, H. Schulzrinne, E. Schooler, and J. Rosenberge,

ITSUMO Group                                                   [Page 13]

Internet-Draft  Mobility Management in a SIP Environment      March 2000

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

   2. ITSUMO Group, "Benchmarking of ITSUMO's All IP Wireless
       Architecture", mwif2000.028, January 28, 2000.

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

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

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

   6. E. Gustafson, A.Johnson, E. Hubbard, J. Malmkvist, and A. Roos,
      "Requirements on Mobile IP from a Cellular Perspective", <draft-
      ietf-mobileip-cellular-requirements-02.txt>, work in progress,
      June 1999.

   7. R. Droms, "Dynamic Host Reconfiguration Protocol", RFC 2131,
      March 1997.

   8. C. Perkins, "IP Mobility Support", RFC 2002, October 1996.

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

   10. P. R. Calhoun, and J. Kempf, " Mobility Management and
       Authentication in an All-IP Network", mwif00.009, January
       17, 2000.

   11. F. Vakil, A. Dutta, J-C. Chen, S. Baba, and Y. Shobatake, "Host
       Mobility Management Protocol: Extending SIP to 3G-IP Networks",
       Internet Draft, <draft-itsumo-hmmp-00.txt>, work in progress,
       October 1999.

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

   13. A. McAuley, S. Das, S. Baba, and Y. Shobatake, "Authentication,
       Authorization, and Accounting Requirements for Roaming Nodes
       using DHCP", Internet Draft, <draft-ietf-dhc-aaa-requirements-
       00.txt>, work in progress, March 2000.

   14. E. Wedlund, and H. Schulzrinne, "Mobility Support using SIP

ITSUMO Group                                                   [Page 14]

Internet-Draft  Mobility Management in a SIP Environment      March 2000

       and RTP", ACM Multimedia Workshop, Seattle, August 1999.

   15. A. McAuley, S. Das, S. Baba, and Y. Shobatake, "Requirements for
       Extending DHCP into New Environments", Internet Draft, <draft-
       ietf -dhc-enhance- requirements-00.txt>, work in progress,
       March 2000.

   16. H. Schulzrinne, S. Casner, R. Fredrick, and V. Jacobson, "RTP: A
       Transport Protocol for Real-Time Applications", RFC 1889, January
       1996.

9. Authors' Addresses

   Faramak Vakil
   Telcordia Technologies, Rm 1C-135B
   445 South Street, Morristown,  NJ  07960-6438
   [email-masked]

   Ashutosh Dutta
   Telcordia Technologies, Rm 1C-227B
   445 South Street, Morristown,  NJ  07960-6438
   [email-masked]

   Jyh-Cheng Chen
   Telcordia Technologies, Rm 1G-236B
   445 South Street, Morristown,  NJ  07960-6438
   [email-masked]

   Shinichi Baba
   Toshiba America Research Inc. (TARI)
   P. O. BOX 136
   Convent Station, NJ 07961-0136
   [email-masked]

   Yasuro Shobatake
   Toshiba America Research Inc. (TARI)
   P. O. BOX 136
   Convent Station, NJ 07961-0136
   [email-masked]

   Henning Schulzrinne
   [email-masked]
   Department of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY, 10027

ITSUMO Group                                                   [Page 15]