Internet DRAFT - draft-itsumo-sip-mobility-service
draft-itsumo-sip-mobility-service
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
<draft-itsumo-sip-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-sip-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
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, <draft-itsumo-sip-multimedia-00.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 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 <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
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 <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
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 <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
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 <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
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", <draft-schulzrinne-sip-
register-00.txt>, 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", <draft-dcsgroup-sip-state-02
.txt>, 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",
<draft-itsumo-sip-mobility-multimedia-00.txt>, work in progress,
December 2000.
5. H. Sinnreich, S. Donovan, D. Rawlins, and S. Thomas, "Interdomain
IP Communication with QoS, Authorization, and Usage Reporting",
<draft-sinnreich-interdomain-sip-qos-osp-01.txt>, work in
progress,
February 2000.
6. P. R. Calhoun, G. Zorn, P. Pan, and H. Akhtar, "DIAMETER Framework
Document", <draft-calhoun-diameter-framework-08.txt>, 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]
