Internet Engineering Task Force F. Vakil
INTERNET DRAFT A. Dutta
draft-itsumo-sip-mobility-req-02.txt J-C. Chen
Date: December 2000 Telcordia Technologies
Expires: June 2001
S. Baba
N. Nakajima
Y. Shobatake
Toshiba America Research, Inc.
H. Schulzrinne
Columbia University
Mobility Management in a SIP Environment
Requirements, Functions and Issues
<draft-itsumo-sip-mobility-req-02.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-mobility-req-02.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 (2000). All Rights Reserved.
ABSTRACT
ITSUMO Group [Page 1]
Internet-Draft Mobility Management in a SIP Environment December 2000
Mobility is rapidly becoming a rule rather than an exception in
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 rather than an exception, and mobile wireless
applications and appliances are becoming predominant. Several
technical forums (e.g., 3GPP, 3GPP2, and MWIF) that are working on
the specifications of a mobile wireless Internet have chosen SIP as
the basic session management protocol. 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 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
ITSUMO Group [Page 2]
Internet-Draft Mobility Management in a SIP Environment December 2000
** 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
of the end-to-end wireless/wireline IP infrastructure of a mobile Internet.
In Section 3, we define the terminal, service and personal aspects of
mobility. Section 4 includes the general system requirements and
considerations for mobility management. Section 5 focuses on necessary
functions for supporting mobility as well as their requirements.
Section 6 identifies some of the open issues involved in supporting
roaming users in a SIP environment, and Section 7 summarizes the document.
2. Architecture of a Mobile Internet
We envision that all services, real-time and non-real-time will
eventually migrate onto a mobile Internet. The users have IP
stationary 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 packet platform of a mobile Internet
which comprises all IP wireless 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 wireline Internet. Besides mobile
stations/terminals, a wireless access network also comprises a radio
access network (RAN), and an edge router and controller (ERC) [2]. In order
to support the needs of its users, a wireless access network interacts
with the network control entities that are shown as Domain Control
Agent (DCA) in Figure 1. What follows is a brief description of these
elements and their functions.
2.1. Mobile Station (MS)
It is the user mobile terminal that allows users to communicate,
and also provides means of interactions and control between users
and the network.
2.2. Radio Access Network (RAN)
The radio access network (RAN) represents the wireless and
back-haul infrastructure that provides MSs with wireless access to
the wireline infrastructure. A RAN usually comprises a set of base
stations and base station controllers. In IMT-2000 [3, 4], RANs
use programmable software radios to provide flexibility across
frequency bands at the MS and across the RAN. It is desirable to
remain independent from the underlying RAN technology and to
minimize the restriction (or requirements) that it places on (or
ITSUMO Group [Page 3]
Internet-Draft Mobility Management in a SIP Environment December 2000
expects from) a RAN.
2.3. Edge Router & Controller (ERC)
An ERC is a routing and control system that connects a wireless
access network to a regional wireline IP network. Although Figure 1
depicts one RAN per ERC, in practice, each ERC may support several
RANs. An ERC comprises two functional entities, an edge router
(ER) and an edge control agent (ECA). The ER is an IP router,
while the ECA is an intelligent agent that interacts with the
domain control agent (DCA) to control the RANs as well as support
necessary network-wide control tasks. In the IP parlance, each ERC
is the default gateway of all IP MSs that are supported by RANs
that are connected to it.
2.4. Domain Control Agent (DCA)
The domain control agent (DCA) provides session management as well
as means for interaction between users and network control system
and interaction among network control entities. Furthermore, the
DCA also supports: (1) Mobility management, (2) Authentication,
Authorization, and Accounting (AAA), and (3) QoS management, in
summary MAAAQ, 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. As Figure 1
indicates the home and visited DCA entities may either interact
directly or via a third party Inter-Domain Control Agent (IDCA) on
the global Internet. In the latter case, the IDCA entity serves as
a trusted broker between the home and visiting network DCAs.
<-- Visited Network --> <---- Home Network ---->
+-----+
| IDR |
+-----+
|
| Inter-Domain
| Control Domain
| +---------------+
+--| MAAAQ |
|---------------|
| Control Agent |
ITSUMO Group [Page 4]
Internet-Draft Mobility Management in a SIP Environment December 2000
+---------------+
+----+ | +----+
| VR | | | HR |
+----+ | +----+
| | |
| | |
Domain| | Domain|
Control|Agent | Control|Agent
+---------------+ | +---------------+
| MAAAQ | | | MAAAQ |
+---------------+ | +---------------+
| SIP Server | | | SIP Server |
+---------------+ | +---------------+
| | |
___|___ ___|___ ___|___
/ \ / \ / \
/ \ / \ / \
/Regional IP\___________/ Internet \___________/Regional IP\
\ Network / \ / \ Network /
\ / \ / \ /
---\_______/--- \_______/ ---\_______/---
| | | |
+-----+ +-----+ +-----+ +-----+
| ERC | | ERC | | ERC | | ERC |
+-----+ +-----+ +-----+ +-----+
| | | |
| | | |
| | | |
__|__ __|__ __|__ __|__
/ \ / \ / \ / \
/ Radio \ / Radio \ / Radio \ / Radio \
/ Access \ / Access \ / Access \ / Access \
\ Network / \ Network / \ Network / \ Network /
\ / \ / \ / \ /
\_____/ \_____/ \_____/ \_____/
| | | |
| | | |
+----+ +----+ +----+ +----+
| MS | | MS | | MS | | MS |
+----+ +----+ +----+ +----+
Figure 1. Architecture of a mobile Internet
As shown in Figure 1, DCA entity of the mobile wireless/wireless IP
network is built around SIP [1]. It comprises comprises SIP servers
and agents, MAAAQ entities, and SIP registrars. 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 each DCA
represents the set of SIP proxies and SIP redirect servers within a
ITSUMO Group [Page 5]
Internet-Draft Mobility Management in a SIP Environment December 2000
regional IP network. 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 capabilities 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
entities comprise a set of distributed agents. Similarly, the SIP
registrars (i.e., HR, VR, and IDR) 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 wireless-wireline infrastructure.
3. Different Facets of Mobility: Definitions
In principle a mobility management protocol provides means of terminal,
session and service, and personal mobility, where:
1. Terminal Mobility: refers to an end user's ability to use her/his
own terminal in any location and the ability of the network to
maintain the user's ongoing communication as she/he roams across
radio cells within the same subnet, subnets within the same
administrative and or different administrative domains.
2. Service Mobility: refers to the end user's ability to maintain
ongoing sessions and obtain services in a transparent manner.
For instance, the user of a mobile terminal should be able to
move a specific session to a laptop/DSL terminal without losing
the session. The service mobility includes the ability of the
home service provider to either maintain control the services it
provides to the user in the visited network or transfer their
control to the visited network.
3. Personal Mobility: refers to the ability of end users to originate
and receive calls and access subscribed network services on any
terminal in any location in a transparent manner, and the ability
of the network to identify end users as they move across
administrative domains.
4. Framework Requirements for Mobility Management
In general, the mobility management scheme of wireless IP networks
satisfies the following requirements [2, 5, 6].
ITSUMO Group [Page 6]
Internet-Draft Mobility Management in a SIP Environment December 2000
I. It supports means of personal, service, and terminal mobility,
i.e., it allows users to access network services anywhere, as
well as to continue their ongoing communication and 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 should 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 authentication, authorization, and accounting (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 and maintained as users roam around.
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.
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 efficiently 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].
ITSUMO Group [Page 7]
Internet-Draft Mobility Management in a SIP Environment December 2000
5. 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 with minimal (if any at all) QoS
degradation 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.
5.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 time. 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.
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).
ITSUMO Group [Page 8]
Internet-Draft Mobility Management in a SIP Environment December 2000
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
- perform the necessary AAA process to verify users' identities and
their rights to requested resources, and ensure correct and
non-repudiatable accounting.
ii. All three hand-off processes strive ensure service mobility as the MS
roams around. In order to do so, they strive to
a. maintain the QoS of ongoing sessions, when mandatory, through
minimizing the loss of transient data during the hand-off,
ITSUMO Group [Page 9]
Internet-Draft Mobility Management in a SIP Environment December 2000
as well as satisfying the delay requirements of real-time
applications as a MS roams around, and
b. 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.
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
propagation 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
configuration 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.
5.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
ITSUMO Group [Page 10]
Internet-Draft Mobility Management in a SIP Environment December 2000
(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 administrative 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.
5.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 [21, 22], if necessary.
The latter is necessary when the MS is a server for a protocol, and also
ensures that the new TCP connections are established using MS's current
address. 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.
5.4 Dynamic Address Binding
ITSUMO Group [Page 11]
Internet-Draft Mobility Management in a SIP Environment December 2000
Dynamic address binding is a process for allowing an MS to maintain a
constant identifier (e.g., a constant URL) regardless of its point of
attachment to the network (e.g., its IP address). 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 (e.g., its IP
address), 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.
5.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.
5.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 (link layer)| Yes
-------------|--------------|---------------|-----------------|------------
Subnet | NO | Yes | Yes | Yes
Intra-domain | | | |
-------------|--------------|---------------|-----------------|------------
Domain | Yes | Yes | Yes | Yes
Inter-domain | | | |
-------------|--------------|---------------|-----------------|------------
ITSUMO Group [Page 12]
Internet-Draft Mobility Management in a SIP Environment December 2000
Table 1. Required functions for supporting different levels of hand-off
6. 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.
6.1 Supporting macro and global mobility for multimedia applications
of roaming users
In principle, mobile IP [8, 9] 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 [8, 15], or the development of
a new SIP based mobility management protocol [11] have been proposed.
However, the interaction and harmonization of mobile IP with 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 [17] applications to accept packets with the same
synchronization source (SSRC) but different source IP address.
6.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 [13] or mobile IP [8] 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.
ITSUMO Group [Page 13]
Internet-Draft Mobility Management in a SIP Environment December 2000
Another alternative is the SIP registration process [12] that uses SIP
REGISTER method and possible interactions of SIP registrars of different
domains with one another through the AAA entities of the home and
visited networks to verify a user's identity and rights and grant or
or deny the registration. In this case, SIP registrars should 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. [14] and Basilier,
et al. [20] for further details on AAA requirements and constraints.
6.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. [16] 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, due to its collision detection procedure, 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) [13] 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. The rationale for the
dynamic updating of DNS is to ensure that new non-SIP (e.g., TCP)
in-bound sessions are established with correct and current address
of the MS.
6.4 Providing location service
As the MS roams around it should update its location so that authorized
users can direct their new calls/sessions to 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
ITSUMO Group [Page 14]
Internet-Draft Mobility Management in a SIP Environment December 2000
SIP methods.
6.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
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. Since the
correct realization of the soft hand-off procedure in IP-centric environments
is complex, some have suggested not to use it in IP wireless networks [18].
However, we believe supporting soft-hand-off is essential because it
improves the capacity and performance of CDMA wireless networks. We have
developed a virtual soft hand-off scheme [19] that uses SIP to extend the
ongoing session to the new location of the MS, and drop the old location
after a limited period of time. The performance - complexity trade-off of
the proposed virtual soft hand-off schemes requires further study.
6.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. This task force should address security issues
in the context of wireline as well as wireless networks.
7. Summary and Conclusions
This document focused on supporting mobility in a SIP signaling and
control environment. 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.
8. 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). We also thank P. Zablocky
(now with GeoWorks) and J. C. Liberti from Telcordia for helpful
discussions on soft hand-off procedures. Special thanks are due to
Glenn Morrow from Nortel Networks for his comments on the
version 00 of this document.
ITSUMO Group [Page 15]
Internet-Draft Mobility Management in a SIP Environment December 2000
(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.
9. References
1. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg,
"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", <draft-
ietf-mobileip-cellular-requirements-02.txt>, 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, <draft-ietf-mobileip-optim-09.txt>,
February 15, 2000.
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, <draft-itsumo-hmmp-00.txt>, work in progress,
ITSUMO Group [Page 16]
Internet-Draft Mobility Management in a SIP Environment December 2000
October 1999.
12. H. Schulzrinne, "SIP Registration", <draft-schulzrinne-sip-
register-00.txt>, work in progress, October 2000.
13. A. McAuley, S. Das, S. Baba, and Y. Shobatake, "Dynamic
Registration and Configuration Protocol for Mobile Hosts",
Internet Draft, <draft-itsumo-drcp-01.txt>, work in progress,
July 2000.
14. A. McAuley, S. Das, S. Baba, and Y. Shobatake, "Authentication,
Authorization, and Accounting Requirements for Roaming Nodes
using DHCP", Internet Draft, <draft-ietf-dhc-aaa-requirements-
00.txt>, work in progress, March 2000.
15. E. Wedlund, and H. Schulzrinne, "Mobility Support using SIP
and RTP", ACM Multimedia Workshop, Seattle, August 1999.
16. A. McAuley, S. Das, S. Baba, and Y. Shobatake, "Requirements for
Extending DHCP into New Environments", Internet Draft, <draft-
ietf-dhc-enhance- requirements-00.txt>, work in progress,
March 2000.
17. H. Schulzrinne, S. Casner, R. Fredrick, and V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", RFC 1889, January
1996.
18. J. Kempf, P. McCann, and P. Roberts, "IP Mobility and CDMA Radio
Access Networks: Applicability Statement for Soft Hand-off",
<draft-kempf-cdma-appl-01.txt>, July 2000.
19. F. Vakil, D. Famolari, S. Baba, and T. Maeda, "Virtual Soft
Hand-off in IP-Centric Wireless CDMA Networks", work in progress,
Submitted for publication.
20. H. Basilier, P. R. Calhoun, M. Holdrege, T. Johansson, and
J. Kempf, "AAA Requirements for IP Telephony/Multimedia",
<draft-calhoun-sip-aaa-reqs-00.txt>, work in progress, July 2000.
21. P. Vixie, Editor, S. Thomson, Y. Rekhter, and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
22. M. Stapp, and Y. Rekhter, "Interaction between DHCP and DNS",
<draft-ietf-dhc-dhcp-dns-12.txt>, work in progress, March 2000.
10. Authors' Addresses
ITSUMO Group [Page 17]
Internet-Draft Mobility Management in a SIP Environment December 2000
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
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
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 18]