Internet Engineering Task Force F. Vakil INTERNET DRAFT A. Dutta draft-itsumo-sip-mobility-service-00.txt M. Tauil Date: December 2000 Telcordia Technologies Expires: June 2001 S. Baba N. Nakajima Y. Shobatake Toshiba America Research, Inc. H. Schulzrinne Columbia University Supporting Service Mobility with SIP 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 (1999). All Rights Reserved. ABSTRACT ITSUMO Group [Page 1] Internet-Draft Supporting Service Mobility with SIP December 2000 Session Initiation Protocol (SIP) can be used to provide means of personal, terminal, and service mobility in a mobile Internet. This document describes two schemes for supporting service mobility in a SIP environment. The first assumes that call states are maintained and stored within the network and home network always controls calls and services of its subscribers. The second assumes that call states are stored in the mobile stations (MSs) and managed in a distributed manner, and the visited network controls users' calls and services. 1. Purpose and Scope Service Mobility refers to the end user's ability to maintain ongoing sessions and obtain services in a transparent manner regardless of the end user's point of attachment [2]. The service mobility includes the ability of the home service provider to either maintain control of services it provides to the user in the visited network or transfer their control to the visited network. In order to support service mobility, one strives to i. maintain the QoS of ongoing sessions as the user (MS) roams around, and ii. 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. The QoS can be maintained through appropriate resource allocation during the hand-off, and SIP REGISTER [2] alongside with necessary AAA functions [5, 6] can be used to ensure users access to subscribed services. In principle, supporting the latter requires complete registration with the home or visited network. Unlike today's mobile telephony where service mobility, particularly for supplementary services, is primarily supported from the MS's home network, SIP is flexible enough to support service mobility either from home or visited networks. The objective of this document is to describe two schemes for supporting service mobility with SIP. The first maintains the service and call control in the home network, while the second transfers them to the visited network. The document is organized as follows: Section 2 states the basic assumption. Section 3 focuses on the service mobility scheme that maintains control at the home network, while Section 4 describes the one that transfers control to the visited network. Finally, Section 5 concludes the document with a summary and a few open issues for further study. ITSUMO Group [Page 2] Internet-Draft Supporting Service Mobility with SIP December 2000 2. Assumptions The underlying assumptions are identical to those set forward in Section 2 of the draft, [4]. Furthermore, in message details throughout the rest of this document we assume that ** Alice (sip:Alice@MS.home.com) is the mobile user who is communicating with Bob (sip: Bob@CH.wondernet.com), ** the domain name for a visited subnet within the same administrative domain is still "home.com", and ** the domain name for a visited network within a different administrative domain is denoted as "visited_adm.com". 3. Service Mobility with Control from Home Network The home network always maintains the control of end users' sessions and services regardless of whether the user is at home or in a visited network. In order to support service mobility, end users always register with their home networks. In this scenario, the call state is stored in stateful proxies within the network and storing the call state in the MS is pointless. The MS registers with its home network that always controls the calls and provides all services to the MS regardless of its current location. An MS initiates a complete registration with home network, upon its attachment to a network (home or visisted) or upon a domain hand-off while roaming. As described in [4] and shown in Figure 1, the complete registration with the home network proceeds as follows: ** The MS sends a SIP REGISTER message to the home registrar (HR) with appropriate values in the To, From, and Contact fields of the REGISTER message as well as the MS's (or user's) profile in the REGISTER message body (F1). If the MS is at home, then the To, From, and Contact fields are are set to the user's SIP URL. Otherwise, the To, and From are set to the user's SIP URL, while the Contact field contains the user's temporary address in the visited network. ** the HR sends a query containing the MS's profile to the home network AAA requesting verification of the MS credentials and rights (F2), and ** upon receiving a positive (or negative) response from AAA (F3), the HR sends a 200 OK (or a 401 unauthorized) response to the MS (F4). ITSUMO Group [Page 3] Internet-Draft Supporting Service Mobility with SIP December 2000 MS HR AAA(h) | SIP REGISTER F1 | | |----------------------------->| Query F2 | | |--------------------->| | | | | | | | | Response F3 | | |<---------------------| | 200 OK F4 | | |<-----------------------------| | | | | AAA(h): AAA entity of the home network Figure 1. Complete registration with the home network. A key open issue that needs further study is how an MS discovers its home registrar while it is in a visited network. Assuming that the AAA is built around DIAMETER [6], then the Query (F2) and Respone (F3) messages should contain the required Attribute Value Parameters (AVP) for completing HMMP registration. Further study is needed to specify the Attributes Value Parameters (AVP) for complete registration of an MS with SIP. *** Message Details for Figure 1 F1 REGISTER MS --> Home Registrar REGISTER sip:reg.home.com SIP/2.0 Via: SIP/2.0/UDP venus.home.com:5060 From: Alice To: Alice Call_ID: 82946@venus.home.com Cseq: 1 REGISTER Contact:Alice@10.12.14.16 Content Length: 0 F2 DIAMETER_Query HR --> AAA(h) Query_AAA (AVP) F3 DIAMETER_Response AAA(h) --> HR Respone_AAA (Results) Examples AVP parameters are user URL, MS hostname, MS IP address, and ITSUMO Group [Page 4] Internet-Draft Supporting Service Mobility with SIP December 2000 MS's requested service(s), while examples of "Results" parameters include Yes (or no), and j list of subscriber's rights (e.g., subscribed services). F4 200 OK Home Registrar --> MS SIP/2.0 200 OK Via: SIP/2.0/UDP venus.home.com From: Alice To: Alice Call_ID: 82946@venus.home.com Cseq: 1 REGISTER Contact:Alice@10.12.14.16 Content Length: 0 Note that if the registration is for attachment to a network the Contact is set to "Alice@MS.home.com" in F1 and F4. The above messages show registration during a hand-off process. The advantages of this approach are its easier call control and accounting, and better security. It allows home operator to maintain the state, and record necessary accounting data at a stateful proxy server within the home network. Furthermore, unlike distributed call state management, there is no chance of tampering with the call state in this case. Its key drawbacks are that its reliance on the home network increases the hand-off delay of ongoing sessions, and it requires discovery of the stateful proxy holding states of ongoing calls. 4. Service Mobility with Control from Visited Network In this scenario, the MS always registers with a local registrar in the visited network. The control of ongoing sessions are transferred to the visisted network upon roaming, and the visited network also controls new sessions of visiting users. Moreover, in this scenario, a. the home and visiting networks share identical agreed upon private keys for call state encryption, b. an encrypted and signed copy of the user's registration with the HR is stored in the MS, and b. the call states of ongoing sessions are is encrypted, signed, and maintained in the MS. As the MS moves into a visited network it register with a local visited registrar. As described in [4 and shown in Figure 2, it sends ITSUMO Group [Page 5] Internet-Draft Supporting Service Mobility with SIP December 2000 the encrypted signed result of its original registration to the VR within the body of the REGISTER message (F1). The VR forwards this information to the AAA(v) entity (F2). Since AAA(v) shares the same private key with AAA(h), it can use this encrypted data to complete the registration by itself in the visited network. Note that AAA(v) updates the registration results as necessary, and sends an encrypted signed copy of it to VR in the Response (F3) for forwarding to the MS in the body of 200 OK (F4). MS VR AAA(v) | REGISTER F1 | | |---------------->| Query F2 | | |--------------->| | | | | | | | | | | | | | | | | |<---------------| |<----------------| Response F3 | | 200 OK F4 | | AAA(v): AAA entity of the visited network. Figure 2. Complete registration process with the visited network *** Message Details for Figure 2 F1 REGISTER MS --> Visited Registrar REGISTER sip:regv.visited_adm.com SIP/2.0 Via: SIP/2.0/UDP plato.vistited_adm.com:5060 From: Alice To: Alice Call_ID: 8294628@ara.visited_adm.com Cseq: 1 REGISTER Contact:Alice@10.12.14.16 Content-Type: Application/DIAMETER Content-Length: .... . . DIAMETER AVP for MS's registration with visited network and distributed state management. . . ITSUMO Group [Page 6] Internet-Draft Supporting Service Mobility with SIP December 2000 F2 DIAMETER_Query VR --> AAA(v) Query_AAA (AVP) F3 DIAMETER_Response AAA(v) --> VR Respone_AAA (Results) Examples parameters of DIAMETER AVP for MS's registration with distributed state management are user URL, MS hostname, MS IP address, and MS's requested service(s) and encrypted results of the recent call and/or registration state, while examples of "Results" parameters include Yes (or no), list of user's rights (e.g., subscribed services), and an encrypted copy of the new call/registration state. F4 200 OK Visited Registrar --> MS SIP/2.0 200 OK Via: SIP/2.0/UDP ara.visisted_adm.com From: Alice To: Alice Call_ID: 8294628@ara.visited_adm.com Cseq: 1 REGISTER Contact:Alice@10.12.14.16 Content-Type:Application/DIAMETER Content-Length: ... . . AAA Response, user's rights, and encrypted registration state . . Note that in this scenario, the encrypted registration and/or call state stored within the MS contain all necessary information so that the visited network can support the user adequately. The registration (and call state) state should include user's profile, the service profile, current state of the call, etc. For instance, the user profile may contain user's name, MS host name, IP address, etc, while the service profile contains list of all subscribed services as well as any other service related information (e.g., balance of a user's account for a pre-paid service), etc. Further study is needed to determine the exact structure of a call or registration state for this approach. The advantages of this approach is reducing domain hand-off delay and the fact that the user relies on the visited network, and does not ITSUMO Group [Page 7] Internet-Draft Supporting Service Mobility with SIP December 2000 need to discover its home registrar. Its disadvantages are that its realization require more memory in the MS and increases the power consumptions of the MS. 5. Summary and Conclusions In summary, we have described two approaches for supporting service mobility with SIP, one with a centralized call state management, and another with a distributed one. Among key issues for further study are ** the performance complexity trade-off of the proposed schemes, ** a method for HR discovery from the visited network, and ** the exact definition of the registration and call states for distributed state management. 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, and Y. Ohba). (TM): ITSUMO (Internet Technology Supporting Universal Mobile Operation) is a trademark of Telcordia. It is a joint research project of Telcordia Technologies and Toshiba America Research Inc. (TARI). It envisions an end-to-end wireless/wireline IP platform for supporting real-time and non-real-time multimedia services in the future. Its goal is to use IP and third generation wireless technologies to design a wireless platform that allows mobile users to access multimedia services on a next generation Internet. In Japanese, ITSUMO means anytime, always. 7. References 1. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. 2. H Schulzrinne, "SIP Registration", , work in progress, October 2000. 8. W. Marshall, K. Ramakrishnan, E. Miller, G. Russel, B. Beser, M. Mannette, K. Steinbrenner, D. Oran, F. Andreasen, J. Pickens, P. Lalwaney, J. Fellows, and K. Kelly, "SIP Extensions for Supporting Distributed Call State", , work in progress, July 2000. ITSUMO Group [Page 8] Internet-Draft Supporting Service Mobility with SIP December 2000 4. F. Vakil, A. Dutta, J-C. Chen, S. Baba, N. Nakajima, Y. Shobatake, and H. Schulzrinne, "Supporting Mobility for Multimedia with SIP", , work in progress, December 2000. 5. H. Sinnreich, S. Donovan, D. Rawlins, and S. Thomas, "Interdomain IP Communication with QoS, Authorization, and Usage Reporting", , work in progress, February 2000. 6. P. R. Calhoun, G. Zorn, P. Pan, and H. Akhtar, "DIAMETER Framework Document", , work in progress, June 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 Miriam Tauil Telcordia Technologies, Rm 1E-209R 445 South Street, Morristown, NJ 07960-6438 miriam@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 ITSUMO Group [Page 9] Internet-Draft Supporting Service Mobility with SIP December 2000 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 10]