[-Internet Engineering Task Force F. Vakil INTERNET DRAFT A. Dutta draft-itsumo-sipping-mobility-service-00.txt M. Tauil Date: July 2001 Telcordia Technologies Expires: December 2001 S. Baba N. Nakajima 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-] {+has been deleted. Unrevised+} documents [-of-] {+placed in+} 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-] {+directories have+} a maximum {+life+} 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 Session Initiation Protocol (SIP) can be used to provide means of ITSUMO Group [Page 1] Internet-Draft Supporting Service Mobility with SIP July 2001 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-] {+months. After+} that [-call states-] {+time, they+} are [-maintained and stored within the network and home network always controls calls and services of its subscribers. The second assumes that call states-] {+deleted. This Internet-Draft was not published as an RFC. Internet-Drafts+} 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-] {+not an archival document series,+} 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-] {+expired drafts, such+} 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. Notice that 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-] {+one, are not available; please do not ask+} 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.-] {+copies... they are not available.+} The [-document is organized-] {+Secretariat does not have information+} 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 July 2001 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-] {+future plans+} of [-whether-] the [-user is at home-] {+authors+} 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-] {+working groups WRT+} the [-MS regardless of its current location. An MS initiates a complete registration with home network, upon its attachment to a network (home or visited)-] {+deleted Internet-Draft. For more information+} 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-] {+copy+} 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-] {+document, contact+} 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 July 2001 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; expires 3600, Alice@10.8.3.243; expires 0 Content Length: 0 F2 DIAMETER_Query HR --> AAA(h) Query_AAA (AVP) F3 DIAMETER_Response AAA(h) --> HR Respone_AAA (Results) ITSUMO Group [Page 4] Internet-Draft Supporting Service Mobility with SIP July 2001 Examples AVP parameters are user URL, MS hostname, MS IP address, and 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; expires 3600 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 visited 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 ITSUMO Group [Page 5] Internet-Draft Supporting Service Mobility with SIP July 2001 visited registrar. As described in [4 and shown in Figure 2, it sends 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.visited_adm.com:5060 From: Alice To: Alice Call_ID: 8294628@ara.visited_adm.com Cseq: 1 REGISTER Contact:Alice@10.12.14.16; expires 3600, Alice@10.8.3.243; expires 0 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 July 2001 . 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.visited_adm.com From: Alice To: Alice Call_ID: 8294628@ara.visited_adm.com Cseq: 1 REGISTER Contact: Alice@10.12.14.16; expires 3600 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. ITSUMO Group [Page 7] Internet-Draft Supporting Service Mobility with SIP July 2001 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 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 iss