Internet DRAFT - draft-itsumo-sipping-mobility-service
draft-itsumo-sipping-mobility-service
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
<draft-itsumo-sipping-mobility-service-00.txt>
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 <draft-
itsumo-sipping-mobility-service-00.txt>, 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 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. 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 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 July 2001
2. Assumptions
The underlying assumptions are identical to those set forward in
Section 2 of the draft, <draft-itsumo-sipping-multimedia-01.txt> [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 visited) 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 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 <sip:Alice@MS.home.com>
To: Alice <sip:Alice@MS.home.com>
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 <sip:Alice@MS.home.com>
To: Alice <sip:Alice@MS.home.com>
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 <sip:Alice@MS.home.com>
To: Alice <sip:Alice@MS.home.com>
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 <sip:Alice@MS.home.com>
To: Alice <sip:Alice@MS.home.com>
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 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", <draft-ietf-sip-rfc2543bis
-03.pdf>, work in progress, May 2001.
2. H Schulzrinne, "SIP Registration", <draft-schulzrinne-sip-
register-01.txt>, work in progress, April 2001.
3. W. Marshall, K. Ramakrishnan, E. Miller, G. Russel, B. Beser,
M. Mannette, K. Steinbrenner, D. Oran, F. Andreasen, J. Pickens,
P. Lalwaney, J. Fellows, D. Evas and K. Kelly, "SIP Extensions
ITSUMO Group [Page 8]
Internet-Draft Supporting Service Mobility with SIP July 2001
for Supporting Distributed Call State", <draft-ietf-sip-state-01
.txt>, work in progress, February 2001.
4. F. Vakil, A. Dutta, J-C. Chen, S. Baba, N. Nakajima, and
H. Schulzrinne, "Supporting Mobility for Multimedia with SIP",
<draft-itsumo-sipping-mobility-multimedia-00.txt>, work in
progress, July 2001.
5. G Gross, H. Sinnreich, D. Rawlins, and S. Thomas, "QoS and AA
Usage with SIP-based IP Communications", <draft-gross-sipaq-
01.txt>, work in progress, April 2001.
6. P. R. Calhoun, G. Zorn, P. Pan, and H. Akhtar, "DIAMETER Framework
Document", <draft-calhoun-diameter-framework-09.txt>, work in
progress, February 2001.
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
ITSUMO Group [Page 9]
Internet-Draft Supporting Service Mobility with SIP July 2001
Henning Schulzrinne
Department of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY, 10027
schulzrinne@cs.columbia.edu
ITSUMO Group [Page 10]
