INTERNET DRAFT F.Vakil, et al Internet Engineering Task Force F.Vakil INTERNET DRAFT A. Dutta draft-itsumo-sip-mobility-req-00.txt Jyh-Cheng Chen Date: March 2000 Telcordia Technologies Expires: August 2000 Shinichi Baba Yasuro Shobatake Toshiba America Research,Inc. Henning Schulzerinne 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 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 , and expires August, 2000. Please send comments to farm@research.telcordia.com or sbaba@tari.toshiba.com, or Schulzerinne@cs.columbia.edu. 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 as work items in the agenda of the SIP WG and/or other appropriate WGs in the IETF. This document is organized as follows: In Section 2, we present the ITSUMO Group [Page 2] Internet-Draft Mobility Management in a SIP Environment March 2000 general system requirements and considerations for mobility management. Section 3 focuses on necessary functions for supporting mobility as well as their requirements. Section 4 identifies some of the open issues involved in supporting roaming users in a SIP environment, and Section 5 summarizes the document. 2. Framework Requirements for Mobility Management 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. In general, the mobility management scheme of wireless IP networks shall satisfy the following framework requirements [2, 6]. I. It shall support means of personal as well as terminal mobility, i.e., it shall allow 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 shall support 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 shall be wireless "technology-independent", i.e., it shall remain independent of the underlying wireless technology to the extent possible. 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 shall support both real-time and non-real-time multimedia services such as mobile telephony, mobile web access, and mobile data services in away 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 shall 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. V. It shall transparently support current TCP-based Internet ITSUMO Group [Page 3] Internet-Draft Mobility Management in a SIP Environment March 2000 application. It shall support TCP as is without requiring any changes to the TCP, i.e., it shall spoof/maintain constant end-points for TCP connections. VI. Last but not least, it shall ensure smooth interworking with PSTN and today's 1G/2G wireless telephony to preserve incumbent providers' investments in the PSTN and existing 1G/2G infrastructure and allow new operators' all IP platforms to interwork with those of the incumbent ones [5]. 3. Mobility Management Functions and Requirements Simply speaking, a roaming MS shall 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. 3.1 Hand-off Hand-off (or 2hand-over) 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. In the 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 is ceased 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 [16, 17]. Note that 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 4] Internet-Draft Mobility Management in a SIP Environment March 2000 In order to take advantage of the soft hand-off feature of the 3G CDMA wireless 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 several seconds. Nevertheless, in order to ensure the wireless "technology independence" requirement of mobility management schemes, we place an upper bound of a few seconds (i.e., 2-3 seconds) on the hand-off latency. 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 hand-off, subnet hand-off, and domain hand-off. 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 shall be transparent to users and shall satisfy the following requirements. i. All three hand-off processes shall ensure the integrity, privacy and confidentiality of users' information as well as prevent fraud and theft of service. They should - 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 5] 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 shall strive to maintain the QoS of the session as the MS roams around. For instance, they shall 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 shall not exceed a few seconds (e.g., 2-3 seconds) to ensure continuity of real-time sessions. iv. The subnet hand-off latency shall not exceed a few seconds (e.g., 2-3 seconds), 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 sum of 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 is about 2-3 seconds. The address binding latency is at most an end-to-end (source - destination - source) round trip queueing and 1 delay. The round trip propagation delay for continental U.S. is about 50 ms (i.e., New York - San Francisco - New York). 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 1  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 shall take roughly a few 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 axioms of framework requirements, the hand-off processes shall minimize their reliance on the link layer. To achieve this goal, the subnet and domain hand-off processes shall remain completely independent from the link layer, while the cell hand-off (i.e., micro-mobility) shall minimally depend on the link layer specifications. ITSUMO Group [Page 6] Internet-Draft Mobility Management in a SIP Environment March 2000 3.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 1 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 shall not take more than a few seconds (e.g., ~2s) to be performed, and the expedited registration process shall take much less than the complete registration process. 3.3 Configuration Configuration is a process by which a MS updates its IP address as well as its profile 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 another one), 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 ** shall not take more than a few hundred milliseconds to complete, and ** shall 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. 3.4 Dynamic Address Binding ITSUMO Group [Page 7] 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 shall be secure to ensure privacy and location confidentiality and protect users against fraud. 3.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. Key requirements of location management are accuracy, being up to date, and confidentiality of the location information. The location information -- shall 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 -- shall only be disclosed to authorized users and relevant authorities within the scope of the law. 4. 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. 4.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 ITSUMO Group [Page 8] Internet-Draft Mobility Management in a SIP Environment March 2000 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 shall be able to spoof constant endpoints for TCP connections and support TCP as is without any modification. 4.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 accomplish verify a user's identity and rights using an AAA mechanism and 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. 4.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 the 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 the 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] has been proposed to reduce the reconfiguration delay of a MS. Moreover, the 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 ITSUMO Group [Page 9] Internet-Draft Mobility Management in a SIP Environment March 2000 appropriate solutions for these issues. 4.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 approach seems to have any impact on SIP specifications, though the latter should be built upon the SIP specifications and use SIP methods. 4.5 Supporting the soft hand-off procedure The third generation 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. 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. 4.6 Providing secure signaling for mobile users Due to the ease of "wire-tapping" in a wireless environment, the signaling and user data shall be particularly shall be encrypted to ensure privacy and confidentiality of users and their profiles and protect them against fraud and theft of service. The SIP WG is aware of this problem, and has chartered a task force to deal with this issue. The SIP security task force shall address this problem in the context of wireline as well as wireless networks. 5. Summary and Conclusions This document focused on supporting mobility in a SIP signaling and control 1. 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. ITSUMO Group [Page 10] Internet-Draft Mobility Management in a SIP Environment March 2000 6. 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, all the time. 7. References 1. IETF, "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. IETF, "Dynamic Host Reconfiguration Protocol", RFC 2131, March 1997. 8. IETF, "IP Mobility Support", RFC 2002, October 1996. 9. C. Perkins, and D. B. Johnson, "Route Optimization in Mobile IP", , February 25, 1999. 10. P. R. Calhoun, and J. Kempf, " Mobility Management and Authentication in an All-IP Network", mwif00.009, January ITSUMO Group [Page 11] Internet-Draft Mobility Management in a SIP Environment March 2000 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", , work in progress, October 1999. 12. A. McAuley, S. Das, S. Baba, and Y. Shobatake, "Dynamic Registration and Configuration Protocol for Mobile Hosts", , 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", , work in progress, March 2000. 14. E. Wedlund, and H. Schulzrinne, "Mobility Support using SIP 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", , work in progress, March 2000. 16. P. Zablocky, "Private Communications", February 18, 2000. 17. J. C. Liberti, "Private Communications", March 8, 2000. 8. Authors' Addresses 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 ITSUMO Group [Page 12] Internet-Draft Mobility Management in a SIP Environment March 2000 Yasuro Shobatake Toshiba America Research Inc. (TARI) P. O. BOX 136 Convent Station, NJ 07961-0136 yasuro.shobatake@toshiba.co.jp Henning Schulzerinne schulzerinne@cs.coumbia.edu Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY, 10027 ITSUMO Group [Page 13]