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 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 Schulzrinne@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 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", , 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 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, , 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, , 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, , 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, , 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 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 Yasuro Shobatake Toshiba America Research Inc. (TARI) P. O. BOX 136 Convent Station, NJ 07961-0136 yasuro.shobatake@toshiba.co.jp Henning Schulzrinne schulzrinne@cs.coumbia.edu Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY, 10027 ITSUMO Group [Page 15]