Internet Engineering Task Force F. Vakil INTERNET DRAFT A. Dutta draft-itsumo-sip-mobility-req-02.txt J-C. Chen Date: December 2000 Telcordia Technologies Expires: June 2001 S. Baba N. Nakajima Y. Shobatake Toshiba America Research, Inc. H. Schulzrinne Columbia University Mobility Management in a SIP Environment Requirements, Functions and Issues Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 , and expires June, 2001. Please send comments to farm@research.telcordia.com or sbaba@tari.toshiba.com, or Schulzrinne@cs.columbia.edu. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. ABSTRACT ITSUMO Group [Page 1] Internet-Draft Mobility Management in a SIP Environment December 2000 Mobility is rapidly becoming a rule rather than an exception in 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 rather than an exception, and mobile wireless applications and appliances are becoming predominant. Several technical forums (e.g., 3GPP, 3GPP2, and MWIF) that are working on the specifications of a mobile wireless Internet have chosen SIP as the basic session management protocol. 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 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 ITSUMO Group [Page 2] Internet-Draft Mobility Management in a SIP Environment December 2000 ** 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 of the end-to-end wireless/wireline IP infrastructure of a mobile Internet. In Section 3, we define the terminal, service and personal aspects of mobility. Section 4 includes the general system requirements and considerations for mobility management. Section 5 focuses on necessary functions for supporting mobility as well as their requirements. Section 6 identifies some of the open issues involved in supporting roaming users in a SIP environment, and Section 7 summarizes the document. 2. Architecture of a Mobile Internet We envision that all services, real-time and non-real-time will eventually migrate onto a mobile Internet. The users have IP stationary 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 packet platform of a mobile Internet which comprises all IP wireless 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 wireline Internet. Besides mobile stations/terminals, a wireless access network also comprises a radio access network (RAN), and an edge router and controller (ERC) [2]. In order to support the needs of its users, a wireless access network interacts with the network control entities that are shown as Domain Control Agent (DCA) in Figure 1. What follows is a brief description of these elements and their functions. 2.1. Mobile Station (MS) It is the user mobile terminal that allows users to communicate, and also provides means of interactions and control between users and the network. 2.2. Radio Access Network (RAN) The radio access network (RAN) represents the wireless and back-haul infrastructure that provides MSs with wireless access to the wireline infrastructure. A RAN usually comprises a set of base stations and base station controllers. In IMT-2000 [3, 4], RANs use programmable software radios to provide flexibility across frequency bands at the MS and across the RAN. It is desirable to remain independent from the underlying RAN technology and to minimize the restriction (or requirements) that it places on (or ITSUMO Group [Page 3] Internet-Draft Mobility Management in a SIP Environment December 2000 expects from) a RAN. 2.3. Edge Router & Controller (ERC) An ERC is a routing and control system that connects a wireless access network to a regional wireline IP network. Although Figure 1 depicts one RAN per ERC, in practice, each ERC may support several RANs. An ERC comprises two functional entities, an edge router (ER) and an edge control agent (ECA). The ER is an IP router, while the ECA is an intelligent agent that interacts with the domain control agent (DCA) to control the RANs as well as support necessary network-wide control tasks. In the IP parlance, each ERC is the default gateway of all IP MSs that are supported by RANs that are connected to it. 2.4. Domain Control Agent (DCA) The domain control agent (DCA) provides session management as well as means for interaction between users and network control system and interaction among network control entities. Furthermore, the DCA also supports: (1) Mobility management, (2) Authentication, Authorization, and Accounting (AAA), and (3) QoS management, in summary MAAAQ, 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. As Figure 1 indicates the home and visited DCA entities may either interact directly or via a third party Inter-Domain Control Agent (IDCA) on the global Internet. In the latter case, the IDCA entity serves as a trusted broker between the home and visiting network DCAs. <-- Visited Network --> <---- Home Network ----> +-----+ | IDR | +-----+ | | Inter-Domain | Control Domain | +---------------+ +--| MAAAQ | |---------------| | Control Agent | ITSUMO Group [Page 4] Internet-Draft Mobility Management in a SIP Environment December 2000 +---------------+ +----+ | +----+ | VR | | | HR | +----+ | +----+ | | | | | | Domain| | Domain| Control|Agent | Control|Agent +---------------+ | +---------------+ | MAAAQ | | | MAAAQ | +---------------+ | +---------------+ | SIP Server | | | SIP Server | +---------------+ | +---------------+ | | | ___|___ ___|___ ___|___ / \ / \ / \ / \ / \ / \ /Regional IP\___________/ Internet \___________/Regional IP\ \ Network / \ / \ Network / \ / \ / \ / ---\_______/--- \_______/ ---\_______/--- | | | | +-----+ +-----+ +-----+ +-----+ | ERC | | ERC | | ERC | | ERC | +-----+ +-----+ +-----+ +-----+ | | | | | | | | | | | | __|__ __|__ __|__ __|__ / \ / \ / \ / \ / Radio \ / Radio \ / Radio \ / Radio \ / Access \ / Access \ / Access \ / Access \ \ Network / \ Network / \ Network / \ Network / \ / \ / \ / \ / \_____/ \_____/ \_____/ \_____/ | | | | | | | | +----+ +----+ +----+ +----+ | MS | | MS | | MS | | MS | +----+ +----+ +----+ +----+ Figure 1. Architecture of a mobile Internet As shown in Figure 1, DCA entity of the mobile wireless/wireless IP network is built around SIP [1]. It comprises comprises SIP servers and agents, MAAAQ entities, and SIP registrars. 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 each DCA represents the set of SIP proxies and SIP redirect servers within a ITSUMO Group [Page 5] Internet-Draft Mobility Management in a SIP Environment December 2000 regional IP network. 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 capabilities 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 entities comprise a set of distributed agents. Similarly, the SIP registrars (i.e., HR, VR, and IDR) 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 wireless-wireline infrastructure. 3. Different Facets of Mobility: Definitions In principle a mobility management protocol provides means of terminal, session and service, and personal mobility, where: 1. Terminal Mobility: refers to an end user's ability to use her/his own terminal in any location and the ability of the network to maintain the user's ongoing communication as she/he roams across radio cells within the same subnet, subnets within the same administrative and or different administrative domains. 2. Service Mobility: refers to the end user's ability to maintain ongoing sessions and obtain services in a transparent manner. For instance, the user of a mobile terminal should be able to move a specific session to a laptop/DSL terminal without losing the session. The service mobility includes the ability of the home service provider to either maintain control the services it provides to the user in the visited network or transfer their control to the visited network. 3. Personal Mobility: refers to the ability of end users to originate and receive calls and access subscribed network services on any terminal in any location in a transparent manner, and the ability of the network to identify end users as they move across administrative domains. 4. Framework Requirements for Mobility Management In general, the mobility management scheme of wireless IP networks satisfies the following requirements [2, 5, 6]. ITSUMO Group [Page 6] Internet-Draft Mobility Management in a SIP Environment December 2000 I. It supports means of personal, service, and terminal mobility, i.e., it allows users to access network services anywhere, as well as to continue their ongoing communication and 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 should 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 authentication, authorization, and accounting (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 and maintained as users roam around. 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. 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 efficiently 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]. ITSUMO Group [Page 7] Internet-Draft Mobility Management in a SIP Environment December 2000 5. 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 with minimal (if any at all) QoS degradation 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. 5.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 time. 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. 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). ITSUMO Group [Page 8] Internet-Draft Mobility Management in a SIP Environment December 2000 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 - perform the necessary AAA process to verify users' identities and their rights to requested resources, and ensure correct and non-repudiatable accounting. ii. All three hand-off processes strive ensure service mobility as the MS roams around. In order to do so, they strive to a. maintain the QoS of ongoing sessions, when mandatory, through minimizing the loss of transient data during the hand-off, ITSUMO Group [Page 9] Internet-Draft Mobility Management in a SIP Environment December 2000 as well as satisfying the delay requirements of real-time applications as a MS roams around, and b. ensure that MS has access to all of its subscribed network services and features (e.g., pre-paid services) regardless of its point of attachement. 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 propagation 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 configuration 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. 5.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 ITSUMO Group [Page 10] Internet-Draft Mobility Management in a SIP Environment December 2000 (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 administrative 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. 5.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 [21, 22], if necessary. The latter is necessary when the MS is a server for a protocol, and also ensures that the new TCP connections are established using MS's current address. 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. 5.4 Dynamic Address Binding ITSUMO Group [Page 11] Internet-Draft Mobility Management in a SIP Environment December 2000 Dynamic address binding is a process for allowing an MS to maintain a constant identifier (e.g., a constant URL) regardless of its point of attachment to the network (e.g., its IP address). 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 (e.g., its IP address), 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. 5.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. 5.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 (link layer)| Yes -------------|--------------|---------------|-----------------|------------ Subnet | NO | Yes | Yes | Yes Intra-domain | | | | -------------|--------------|---------------|-----------------|------------ Domain | Yes | Yes | Yes | Yes Inter-domain | | | | -------------|--------------|---------------|-----------------|------------ ITSUMO Group [Page 12] Internet-Draft Mobility Management in a SIP Environment December 2000 Table 1. Required functions for supporting different levels of hand-off 6. 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. 6.1 Supporting macro and global mobility for multimedia applications of roaming users In principle, mobile IP [8, 9] 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 [8, 15], or the development of a new SIP based mobility management protocol [11] have been proposed. However, the interaction and harmonization of mobile IP with 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 [17] applications to accept packets with the same synchronization source (SSRC) but different source IP address. 6.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 [13] or mobile IP [8] 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. ITSUMO Group [Page 13] Internet-Draft Mobility Management in a SIP Environment December 2000 Another alternative is the SIP registration process [12] that uses SIP REGISTER method and possible interactions of SIP registrars of different domains with one another through the AAA entities of the home and visited networks to verify a user's identity and rights and grant or or deny the registration. In this case, SIP registrars should 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. [14] and Basilier, et al. [20] for further details on AAA requirements and constraints. 6.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. [16] 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, due to its collision detection procedure, 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) [13] 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. The rationale for the dynamic updating of DNS is to ensure that new non-SIP (e.g., TCP) in-bound sessions are established with correct and current address of the MS. 6.4 Providing location service As the MS roams around it should update its location so that authorized users can direct their new calls/sessions to 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 ITSUMO Group [Page 14] Internet-Draft Mobility Management in a SIP Environment December 2000 SIP methods. 6.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 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. Since the correct realization of the soft hand-off procedure in IP-centric environments is complex, some have suggested not to use it in IP wireless networks [18]. However, we believe supporting soft-hand-off is essential because it improves the capacity and performance of CDMA wireless networks. We have developed a virtual soft hand-off scheme [19] that uses SIP to extend the ongoing session to the new location of the MS, and drop the old location after a limited period of time. The performance - complexity trade-off of the proposed virtual soft hand-off schemes requires further study. 6.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. This task force should address security issues in the context of wireline as well as wireless networks. 7. Summary and Conclusions This document focused on supporting mobility in a SIP signaling and control environment. 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. 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, and Y. Ohba). We also thank P. Zablocky (now with GeoWorks) and J. C. Liberti from Telcordia for helpful discussions on soft hand-off procedures. Special thanks are due to Glenn Morrow from Nortel Networks for his comments on the version 00 of this document. ITSUMO Group [Page 15] Internet-Draft Mobility Management in a SIP Environment December 2000 (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. 9. References 1. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "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", , 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, , February 15, 2000. 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, , work in progress, ITSUMO Group [Page 16] Internet-Draft Mobility Management in a SIP Environment December 2000 October 1999. 12. H. Schulzrinne, "SIP Registration", , work in progress, October 2000. 13. A. McAuley, S. Das, S. Baba, and Y. Shobatake, "Dynamic Registration and Configuration Protocol for Mobile Hosts", Internet Draft, , work in progress, July 2000. 14. A. McAuley, S. Das, S. Baba, and Y. Shobatake, "Authentication, Authorization, and Accounting Requirements for Roaming Nodes using DHCP", Internet Draft, , work in progress, March 2000. 15. E. Wedlund, and H. Schulzrinne, "Mobility Support using SIP and RTP", ACM Multimedia Workshop, Seattle, August 1999. 16. A. McAuley, S. Das, S. Baba, and Y. Shobatake, "Requirements for Extending DHCP into New Environments", Internet Draft, , work in progress, March 2000. 17. H. Schulzrinne, S. Casner, R. Fredrick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. 18. J. Kempf, P. McCann, and P. Roberts, "IP Mobility and CDMA Radio Access Networks: Applicability Statement for Soft Hand-off", , July 2000. 19. F. Vakil, D. Famolari, S. Baba, and T. Maeda, "Virtual Soft Hand-off in IP-Centric Wireless CDMA Networks", work in progress, Submitted for publication. 20. H. Basilier, P. R. Calhoun, M. Holdrege, T. Johansson, and J. Kempf, "AAA Requirements for IP Telephony/Multimedia", , work in progress, July 2000. 21. P. Vixie, Editor, S. Thomson, Y. Rekhter, and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. 22. M. Stapp, and Y. Rekhter, "Interaction between DHCP and DNS", , work in progress, March 2000. 10. Authors' Addresses ITSUMO Group [Page 17] Internet-Draft Mobility Management in a SIP Environment December 2000 Faramak Vakil Telcordia Technologies, Rm 1C-135B 445 South Street, Morristown, NJ 07960-6438 farm@research.telcordia.com Ashutosh Dutta Telcordia Technologies, Rm 1C-227B 445 South Street, Morristown, NJ 07960-6438 adutta@research.telcordia.com Jyh-Cheng Chen Telcordia Technologies, Rm 1G-236B 445 South Street, Morristown, NJ 07960-6438 jcchen@research.telcordia.com Shinichi Baba Toshiba America Research Inc. (TARI) P. O. BOX 136 Convent Station, NJ 07961-0136 sbaba@tari.toshiba.com Nobuyasu Nakajima Toshiba America Research Inc. (TARI) P. O. BOX 136 Convent Station, NJ 07961-0136 nobuyasu@tari.research.telcordia.com Yasuro Shobatake Toshiba America Research Inc. (TARI) P. O. BOX 136 Convent Station, NJ 07961-0136 yasuro.shobatake@toshiba.co.jp Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY, 10027 schulzrinne@cs.coumbia.edu ITSUMO Group [Page 18]