One document matched: draft-itsumo-hmmp-00.txt
Internet Engineering Task Force Faramak Vakil
INTERNET DRAFT Ashutosh Dutta
draft-itsumo-hmmp-00.txt Jyh-Cheng Chen
Date: October 1999 Telcordia Technologies
Expires: April 2000
Shinichi Baba
Yasuro Shobatake
Toshiba Research America,Inc.
Host Mobility Management Protocol
Extending SIP to 3G-IP Networks
<draft-itsumo-hmmp-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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-hmmp-00.txt>, and expires April, 2000. Please send comments to
either farm@research.telcordia.com or sbaba@tari.toshiba.com.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
ABSTRACT
Host mobility management protocol (HMMP) is a protocol for supporting
real-time and non-real-time multimedia applications on mobile
terminals of 3G-IP networks. HMMP utilizes as well as extends session
initiation protocol (SIP) to provide means of domain hand-off (i.e.,
roaming), and subnet hand-off (i.e., macro mobility) so that users
can access the network from any location using their own mobile
ITSUMO Group [Page 1]
Internet-Draft Host Mobility Management Protocol October 1999
terminal. An advantage of HMMP is that it can spoof constant
endpoints for mobile TCP connections and supports mobile TCP
applications in a SIP environment without any changes to the TCP.
The objective of this document is to present the preliminary
specifications of HMMP, identify the impact of mobility on SIP, and
propose necessary extensions to ensure that SIP can support roaming
users adequately. Specifically, it proposes that
a. the SIP INFO method provides a means of profile verification
and/or replication, and address binding, b. the SIP REGISTER
method designates a "RHO"
CONTACT that allows the registrar to obtain a new address from the
DHCP on behalf of the mobile, c. the SIP user agent is equipped
with a SIP_EYE agent that maintains
a record of ongoing TCP connections of the mobile, and d. the SIP
user agent understands address binding INFO messages and
takes necessary actions.
Furthermore, it proposes that either the DHCP interact with the DNS
and update it dynamically, or a new protocol be developed to allow
applications to use SIP registrar for name to address and address to
name mappings.
1.Introduction
1.1 The Rationale
Driving the trend towards third generation wireless IP (3G-IP)
technology are users' demand for perpetual ubiquitous access to the
Internet, rapid proliferation of mobile Internet appliances, and
providers' desire for deploying a flexible wireless and wireline IP
platform that supports heterogeneous services economically [1, 2, 3].
Furthermore, the current wisdom is that the existing circuit switched
and 1G/2G (i.e., 1G and 2G) wireless systems will eventually evolve
and merge into an end-to-end IP platform that provides ubiquitous
real-time as well as non-real-time services. In a nutshell, it is
envisioned that an end-to-end wireless/wireline IP platform
comprising 3G wireless access networks and a wireline IP backbone
will support real-time and non-real-time multimedia services in the
future. Thus, supporting roaming users is an essential feature of the
end-to-end signaling and control system of IP networks as well as a
critical topic for consideration in the IETF SIP working group.
1.2 3G-IP Requirements and Issues
A 3G-IP network is a wireless platform that will enable mobile users'
IP appliances to access multimedia services on end-to-end
ITSUMO Group [Page 2]
Internet-Draft Host Mobility Management Protocol October 1999
wireline/wireless IP platforms in future [6]. We envision that it
will
- eventually be built upon the packet mode capabilities of the 3G
wireless technologies such as IMT-2000 [4, 5],
- support mobile real-time and non-real-time services such as mobile
telephony, mobile web access, and mobile data services [7, 8],
- provide means of global roaming, offer intelligent services (e.g.,
call forwarding, etc.) similar to those of today's intelligent
networks,
- strive to ensure that the quality (and price) of their service
offerings will be comparable to those of today's wireless
telephony and data services, and
- be built upon enhancements of the current IETF standards to the
extent possible so that the design and development cycle is
minimized.
Among the key issues in the design of the signaling and control
system of 3G-IP networks are how to
+ support terminal as well as personal/user mobility,
+ satisfy the quality of service (QoS) requirements of services,
particularly those of real-time applications for roaming users,
+ ensure privacy and security of the users as well as the network
resources,
+ perform billing and accounting, and
+ maintain smooth interworking with the public switched telephone
network (PSTN) and its 1G/2G wireless access networks.
Although each of these issues may have some impact on the signaling
protocols of IP networks that are being developed in the SIP working
group, addressing all of them is beyond the scope of this document.
This document exclusively focuses on the specifications of a mobility
management protocol that uses an extended version of SIP to support
multimedia services of roaming users.
1.3 Scope and Purpose
The objective of this document is to present the preliminary
specifications of host mobility management protocol (HMMP). We
ITSUMO Group [Page 3]
Internet-Draft Host Mobility Management Protocol October 1999
- build upon the personal mobility feature of SIP to design HMMP that
suppots terminal as well as personal mobility,
- identify the impact of mobility on SIP, and
- propose necessary extensions to ensure that SIP can support roaming
users via HMMP adequately.
HMMP is a protocol for supporting real-time and non-real-time
multimedia applications on mobile terminals. It provides means of
domain hand-off (i.e., roaming), and subnet hand-off (i.e., macro
mobility). However, HMMP primarily relies on the link layer to
support the cell-hand-off (i.e., micro-mobility). HMMP also spoofs
constant endpoints for mobile TCP connections and supports mobile TCP
applications in a SIP environment without any changes to the TCP.
1.4 Related IETF Documents
HMMP is primarily built upon the session initiation protocol (SIP) as
specified in RFC 2543. Other related IETF documents are
- SDP: Session Description Protocol (RFC 2327),
- DHCP: Dynamic Host configuration Protocol (RFC 2131),
- IP Encapsulation within IP (RFC 2003), and
- Minimal Encapsulation within IP (RFC2004).
1.5 Organization of the Document
This document is organized as follows. HMMP's assumptions on the
underlying network environment are summarized in Section 2, where
Section 2.1 describes the architecture of a 3G-IP network, and
Section 2.2 summarizes its signaling architecture that is the
substrate of HMMP. Section 3 provides an overview of the HMMP
operation and underscores the need for augmenting the SIP user agent
with a SIP_EYE agent that tacks ongoing TCP connections of the mobile
station. Section 4 contains the detailed specifications of HMMP
where we describe how HMMP utilizes SIP to provide means of
registration, location service, and hand-off to roaming users. The
function and basic operation of the SIP_EYE agent are described in
Section 5. In Section 6, we summarize the impact of supporting
mobility via HMMP on SIP specifications, and highlight necessary
extensions for supporting mobility with SIP. Finally, Section 7
concludes the document with open issues for further study.
2. Assumptions: A 3G-IP Environment
This Section provides an overview of a 3G-IP network and its
signaling architecture that serves as the foundation of HMMP.
2.1 Architecture of a 3G-IP Network
ITSUMO Group [Page 4]
Internet-Draft Host Mobility Management Protocol October 1999
Figure 1 depicts the end-to-end packet platform of a 3G-IP network,
which comprises 3G-IP 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 Internet. Besides mobile
stations/terminals, a wireless access network usually comprises a set
of base stations, base station controllers, and mobile switching
centers [3]. In order to support the needs of its users, a wireless
access network interacts with the network control and signaling
entities that are shown as "Signaling & MAAAQ" in Figure 1. What
follows is a brief description of these elements and their functions.
Mobile Station (MS)
It is the user mobile terminal that allows users to communicate, and
also provides means of interaction (i.e., signaling) between users
and the network.
Base Station (BS)
It is an adaptive remote radio multiplexer/demultiplexer that
provides physical and link layer functions and essentially serves as
a MAC layer repeater. In IMT-2000 programmable software radios can
be used to provide flexibility across frequency bands at the MS and
the BS.
Base Station Controller (BSC)
It is a multi-port bridge (or switch) with an IP interface to MSC
that interacts with the network control and management system (via
the MSC) to control and manage base stations. A BSC may control one
or more BSs.
Mobile Switching Center (MSC)
An MSC is an IP router that connects the wireless access network and
the regional wireline IP network. In the IP parlance, each MSC is
the default gateway of all IP MSs that are supported by BSCs that are
connected to it. A couple of points are worth noting. First,
different BSCs may be connected to different ports of an MSC.
Second, the BSC and MSC functions may be implemented either in a
single physical entity, or as two separate entities.
ITSUMO Group [Page 5]
Internet-Draft Host Mobility Management Protocol October 1999
+-----------+
-->| Signaling |<--
/ | & MAAAQ | \
/--------/ +-----------+ \--------\
/ | \
\/ | \/
+-----------+ | +----------+
| Signaling | | | Signaing |
| & MAAAQ | <-------------|---------------> | & MAAAQ |
+-----------+ | +----------+
| | |
___|___ ____|__ ___|___
/ \ / \ / \
/ \ / \ / \
/Regional IP\________/ Internet \_________ /Regional IP\
\ Network / \ / \ etwork /
\ / \ / \ /
\_______/ \_______/ \_______/
| |
| |
+-----+ +-----+
| MSC | | MSC |
+-----+ +-----+
| |
| |
+----------+ +----------+
| BSC | | BSC |
+----------+ +----------+
| | | |
| | | |
+----+ +----+ +----+ +----+
| BS | | BS | | BS | | BS |
+----+ +----+ +----+ +----+
| | |
| | |
+-----+ +-----+ +-----+
| MS | | MS | | MS |
+-----+ +-----+ +-----+
Figure 1. End-to-end network architecture of a 3G-IP network
Signaling & MAAAQ
Signaling provides connection management as well as means of
interaction between users and network control system and interaction
among network control entities. MAAAQ (Mobility, Authentication,
Authorization, Accounting, and QoS) entities support mobility
management, AAA, and QoS management functions for mobile users. These
functional entities usually reside on the wireline backbone, and are
ITSUMO Group [Page 6]
Internet-Draft Host Mobility Management Protocol October 1999
part of the overall signaling and control system of the end-to-end
platform. As Figure 1 indicates the home and visiting signaling &
MAAAQ entities may either interact directly or via a third party
signaling & MAAAQ entity on the global Internet. In the latter case,
the third party signaling & MAAAQ entity serves as a trusted broker
between the home and visiting network signaling and MAAAQ entities.
2.2 A Signaling Architecture for 3G-IP Networks
The overall signaling architecture of a 3G-IP is shown in Figure 2.
It uses session initiation protocol (SIP) [9, 10] as the basis of its
end-to-end signaling and control architecture. The rationales for the
choice of SIP are that:
- SIP is a lightweight end-to-end protocol with a small set of
messages that can be used for user as well as network node
signaling.
- SIP uses a single request message for session initiation, and scales
well over wide-area networks.
- SIP is ideal for IP mobiles, enables mobiles to perform some
intelligent networking functions themselves, and supports non-IP
mobiles via a customer gateway.
- SIP provides a means of personal mobility that is a crucial part of
mobility management in wireless environments.
Visiting Network Home Network
<--------------------> <-------------------->
Visiting Registrar Home Registrar
+----+ +----+
| VR | | HR |
+----+ +----+
| |
| |
+-----------+ +-----------+
| MAAAQ | | MAAAQ |
+-----------+ +-----------+
| SIP Server| <-----------------------------> | SIP Server|<...
+-----------+ +-----------+ .
| | .
___|___ _______ ___|___ .
/ \ / \ / \ .
/ \ / \ / \ .
/Regional IP\________/ Internet \_________ /Regional IP\ .
\ Network / \ / \ Network / .
\ / \ / \ / .
\_______/ \_______/ \_______/ .
| | SIP
ITSUMO Group [Page 7]
Internet-Draft Host Mobility Management Protocol October 1999
| | .
___|___ ___|___ .
/ \ / \ .
/ \ / \ .
/ 3G Access \ / 3G Acces \ .
\ Network / \ Network / .
\ / |\ /| .
\_______/ | \_______/ | .
| | | .
| | | .
| | | .
| | | .
+-----+ +-----+ +-----+..
| MS | | MS | | MS |
+-----+ +-----+ +-----+
Figure 2. A signaling architecture for 3G-IP networks
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 2, the SIP
server entity of a regional IP network represents the set of SIP
proxy and SIP redirect servers within the regional network that
perform the network control and signaling functions. Similarly, the
registrar represents the server (or set of servers) that accepts
(accept) SIP REGISTER requests and provides (provide) location
services that are similar to those of the home/visiting location
registries (HLR/VLR) in today's wireless telephony. As Figure 2 shows
the MAAAQ entity is built on top of SIP, and uses the location and
signaling services of SIP to support roaming users.
The illustration of the MAAAQ entities and SIP server as a single
module in Figure 2 shall not be interpreted as a requirement for
having a centralized SIP server or MAAAQ entity per regional network.
Figure 2 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 and VR) may be implemented as either
central or distributed databases.
The remainder of this document focuses primarily on the
specifications of a HMMP for the mobility management entity as well
as necessary extensions to SIP for supporting roaming users.
3. An Overview of HMMP
Figure 3 depicts an end-to-end 3G-IP platform in relative detail. Let
us consider the scenario where a corresponding host communicates with
a mobile host. For the sake of discussion, let us assume that
ITSUMO Group [Page 8]
Internet-Draft Host Mobility Management Protocol October 1999
- the mobile has already registered with its home network using SIP
REGISTER method, and
- its communication with the corresponding host starts when it is at
point A and continues as it moves towards point D.
In general, a mobility management protocol shall provide three
functions to the mobile users. These functions are
i.cell hand-off (micro mobility): that allows users to move from a
cell to another, i.e., moving between base stations from A to B,
ii.subnet hand-off (macro mobility): that allows users to move
between different subnets within the same administrative domain
from B to C, and
iii.roaming (global mobility): that allows users to roam between
different subnets that belong to different administrative domains
from C to D.
Visiting Network Home Network
<--------------------> <-------------------->
Visiting Registrar Home Registrar
+----+ +----+
| VR | | HR |
+----+ +----+
| |
| |
+-----------+ +-----------+
| MAAAQ | | MAAAQ |
+-----------+ +-----------+
| SIP Server| <-----------------------------> | SIP Server|
+-----------+ +-----------+
| |
| |
| |
___|___ ______ ___|___
/ \ / \ / \ +----+
/ \ / \ / \----| CH |
/Regional IP\________/ Internet \_ ________ /Regional IP\ +----+
\ Network / \ / \ Network /
\ / \ / |\ /|*
\______/ \______/ | \_______/ |*
| | |* | | |*
| | |*
+-------+ +-------+ +-------+
| MSC 3 | | MSC 2 | | MSC 1 |
+-------+ +-------+ +-------+
| | |*
| | |*
+----------+ +-------+ +----------+
| BSC 3 | | BSC 2 | | BSC 1 |
ITSUMO Group [Page 9]
Internet-Draft Host Mobility Management Protocol October 1999
+----------+ +-------+ +----------+
| | | |* |
| | | |* |
+----+ +----+ +----+ +----+ +----+
| BS | | BS | | BS | | BS | | BS |
+----+ +----+ +----+ +----+ +----+
| | |* |
| | |* |
+-----+ +-----+ +-----+ +-----+
| MS | | MS | | MS | | MS |
+-----+ +-----+ +-----+ +-----+
D C B A
Figure 3. Cell hand-off in HMMP
The cell hand-off (i.e., micro mobility) is not part of HMMP and is
usually handled at the link layer, while HMMP uses SIP to provide the
subnet hand-off (i.e., macro mobility) and roaming (i.e., global
mobility) functions for mobile hosts on 3G-IP networks. What follows
is a walk through the operation of HMMP using this example.
3.1 Cell hand-off
As the mobile moves from A to B, then the link layer mobility
management entity
* binds the mobile's MAC address (or CDMA sequence) to the BSC port
destined for base station B, and
* updates the label translation table in BSC 1, so that the
information destined for the mobile host is routed to base station
B. Note that the label translation table refers to a table in the
BSC that contains the binding of mobile's MAC addresses to BSC
ports.
If the mobile can communicate with two adjacent base stations
simultaneously, the mobile's binding to base station A may be
maintained for a time-out period after the hand-off so that the
hand-off is soft and transient packets are not lost. Note that the IP
address of the mobile remains the same.
3.2 Subnet hand-off
The mobile moves further from B to C, and it is still registered with
the network. HMMP supports subnet hand-off (i.e., macro mobility)
during the session as follows.
+ The mobile asks a new temporary address from DHCP. The mobile
ITSUMO Group [Page 10]
Internet-Draft Host Mobility Management Protocol October 1999
requests a new address either directly (see Section 4.1.1) or via a
SIP registrar (see Section 4.1.2). The DHCP gives the mobile a
temporary IP address, the address of its default gateway, and the
subnet mask. Furthermore, the DHCP updates the domain name system
(DNS) simultaneously.
+ In public networks, the network authenticates the mobile as a
protection against fraud. In principle, it is always desirable to
authenticate a mobile before assigning network resources such as
adresses to it. For instance, PPP has its own registration scheme
using CHAP during session initiation and the MIP extension using
NAI for registration prpose has been proposed. The registration
approach described in Section 4.1.2 as well as the Dynamic
Registration and Configuration Protocol(DRCP) proposed in McAuley,
et.al [14] both can authenticate and assign an address to
it simultaneously.
+ The mobile or SIP server re-invites the corresponding host to the
temporary address (similar to the approach proposed by Wedlund and
Schulzrinne [16]).
+ SIP server and network resource reservation scheme should create a
new route with adequate resources between the corresponding host
and the mobile.
a. This new route with adequate resources is only created for
real-time applications like voice. There have been several
proposal for the use of Resource ReServation Protocol
(RSVP)[21] for resource reservation in wireline networks that
have SIP signaling [22]. However, due to its receiver
initiated reservation scheme, RSVP is not suitable for a mobile
wireless netwok. The specifications of a resource reservation
mechanism for supporting real-time mobile applications and its
interaction with SIP require further study, and are beyond the
scope of this document.
b. The non-real-time applications are allowed to traverse the
network hop-by-hop.
+ The mobile or SIP server ensures that the transient data is
forwarded to the new address, i.e., it creates a short-lived tunnel
between MSC 1 and MSC 2 to reduce loss of the transient data due to
hand-off. In order to create this tunnel, the mobile or SIP server
informs MSC-1 to bind the previous address of the mobile to its
current one for a time-out period. This requires
* SIP user agents at all MSCs (i.e., subnet routers), and
* the address of the most recent MSC which is the most recent
default gateway.
Visiting Network Home Network
<--------------------> <-------------------->
Visiting Registrar Home Registrar
+----+ +----+
ITSUMO Group [Page 11]
Internet-Draft Host Mobility Management Protocol October 1999
| VR | | HR |
+----+ +----+
| |
| |
+-----------+ +-----------+
| MAAAQ | | MAAAQ |
+-----------+ +-----------+
| SIP Server| <-----------------------------> | SIP Server|
+-----------+.... ....+-----------+
| | | |
| +----+ +----+ |
| |DHCP| |DHCP| |
| +----+ +----+ |
___|___ | _______ _ | ___|___
/ \.... / \ _ ..../ \ +----+
/ \ / \ _ **/*********\----| CH |
/Regional IP\________/ Internet \__________*/Regional IP\ +----+
\ Network / \ / *\ Network /|
\ / \ / *|\ / |
\_______/ \ ______/ *| \______/ |
| *| |
| *| |
| *| |
+-------+ +-------+ +-------+
| MSC 3 | | MSC 2 |====| MSC 1 |
+-------+ +-------+ +-------+
| *| |
| *| |
+----------+ +-------+ +----------+
| BSC 3 | | BSC 2 | | BSC 1 |
+----------+ +-------+ +----------+
| | *| | |
| | *| | |
+----+ +----+ +----+ +----+ +----+
| BS | | BS | | BS | | BS | | BS |
+----+ +----+ +----+ +----+ +----+
| *| | |
| *| | |
+-----+ +-----+ +-----+ +-----+
| MS | | MS | | MS | | MS |
+-----+ +-----+ +-----+ +-----+
D C B A
Figure 4. Subnet hand-off in HMMP
ITSUMO Group [Page 12]
Internet-Draft Host Mobility Management Protocol October 1999
3.3 Roaming
Except for the fact that the mobile SHALL always be autheticated,
roaming in HMMP is similar to subnet hand-off described in Section
3.2. As the mobile moves further to D, HMMP operates as follows:
+ The mobile requests for a temporary address and receives one from
DHCP. The DHCP updates the DNS simultaneously.
+ The mobile re-registers with its temporary address in the new domain
using the SIP REGISTER method.
* The mobile profile is added to the visiting registrar (VR),
i.e., its profile is replicated either through interaction of
the VR with the HR or by pre-planned profile replications [13]
in the neighboring VRs. The pre-planned profile replications
reflect the mobility pattern of the mobile, and its effective
realization requires continuous monitoring of users' mobility
patterns.
+ The mobile or SIP server re-invites the corresponding host to the
temporary address (similar to the approach proposed by Wedlund and
Schulzrinne [16]).
+ SIP server and network resource reservation scheme should create a
new route with adequate resources between the corresponding host and
the mobile.
a. This new route with adequate resources is only created for
real-time applications like voice. The specifications of a
resource reservation mechanism for supporting real-time mobile
applications and its interaction with SIP require further
study, and are beyond the scope of this document.
b. The non-real-time applications are allowed to traverse the
network hop-by-hop.
+ The mobile or SIP server ensures that the transient data is
forwarded to the new address, i.e., it creates a short-lived tunnel
between MSC 2 and MSC 3 to reduce loss of the transient information
+ The mobile or SIP server informs MSC-2 to bind the previous address
of the mobile to its current one for a time-out period. This
requires
* SIP user agents at all MSCs (i.e., subnet routers), and
* the address of the most recent MSC which is the most recent
default gateway.
Visiting Network Home Network
<--------------------> <-------------------->
Visiting Registrar Home Registrar
+----+ +----+
| VR | | HR |
+----+ +----+
| |
ITSUMO Group [Page 13]
Internet-Draft Host Mobility Management Protocol October 1999
| |
+-----------+ +-----------+
| MAAAQ | | MAAAQ |
+-----------+ +-----------+
| SIP Server| <-----------------------------> | SIP Server|
+-----------+.... ....+-----------+
| | | |
| +----+ +----+ |
| |DHCP| |DHCP| |
| +----+ +----+ |
___|___ | _______ | ___|___
/ \.... / \ ..../ \ +----+
/*********\***********/*********\*************/*********\----| CH |
/Regional IP\_________/ Internet \__________ /Regional IP\ +----+
\*Network / \ / \ Network /
\* / \ / |\ /|
*\_______/ \______ / | \_______/ |
*| | |
*| | |
*| | |
+-------+ +-------+ +-------+
| MSC 3 |===============================| MSC 2 | | MSC 1 |
+-------+ +-------+ +-------+
*| | |
*| | |
+----------+ +-------+ +----------+
| BSC 3 | | BSC 2 | | BSC 1 |
+----------+ +-------+ +----------+
| *| | | |
| *| | | |
+----+ +----+ +----+ +----+ +----+
| BS | | BS | | BS | | BS | | BS |
+----+ +----+ +----+ +----+ +----+
*| | | |
*| | | |
+-----+ +-----+ +-----+ +-----+
| MS | | MS | | MS | | MS |
+-----+ +-----+ +-----+ +-----+
D C B A
Figure 5. Roaming in HMMP
3.4 Supporting TCP Applications with HMMP
Internet applications that require a reliable service from the
transport mechanism, e.g., file transfer protocol (FTP), primarily
use TCP. Thus, it is essential that HMMP support mobile TCP
ITSUMO Group [Page 14]
Internet-Draft Host Mobility Management Protocol October 1999
applications without requiring any changes to the TCP.
Although the fundamental abstraction of both SIP and TCP is the
connection, they identify it differently. A session/call ID
identifies a SIP connection/session, while a pair of endpoints
identifies a TCP connection. Each TCP endpoint is identified with a
pair of integers (host, port) where host is IP address of the
endpoint, and port is the TCP port on the host. However, as a mobile
roams, its IP address, i.e., the host integer of its TCP endpoint
changes. In order to support TCP applications properly, HMMP shall
spoof constant TCP endpoints despite changes in their host integers
(i.e., IP addresses) due to roaming of the mobiles. The spoofing
process is akin to mobile IP with route optimization [17, 18], and
its underlying idea is that
- the mobile informs the corresponding TCP endpoints about its new
address,
- the corresponding host(s) binds (bind) the initial IP address of the
mobile with its new temporary (i.e., care of address) IP address,
and
- the corresponding host(s) uses (use) encapsulation to send the TCP
packets bearing the initial source and destination addresses to the
current location/address of the mobile.
In order to support TCP applications on HMMP without modifying TCP,
the SIP user agent SHALL be augmented with a SIP_EYE agent that
tracks TCP connection set-ups and releases within the mobile. The
SIP_EYE agent enables the SIP user agent to maintain a record of
mobile's ongoing TCP connections, and their identifiers. SIP_EYE
operates as follows:
i. It examines headers of TCP packets to monitor the birth and death
of TCP connections as well as identify their endpoints, i.e., the
source and destination IP addresses and port numbers of these
connections.
ii. It maintains a current record of the mobile's ongoing TCP
connections' identifiers, and the address of the current and last
(i.e., most recent) MSCs (i.e., default gateways) within the
mobile's SIP user agent.
iii. SIP_EYE records a state comprising four integers, <original
MS IP address, previous MS IP address, current MS IP
address, original corresponding IP address>, per TCP
connection. The original MS IP address is the IP address of
the mobile at the beginning of the TCP session, previous mobile
IP address is the last IP address of the mobile just before its
current one, and current MS IP address is the current IP
address of the mobile. The original corresponding IP address is
the IP address of the corresponding host at the beginning of the
ITSUMO Group [Page 15]
Internet-Draft Host Mobility Management Protocol October 1999
TCP session.
iv. Upon a mobile station's successful registration with the visiting
network, its SIP user agent sends
(a) an INFO message (messages) to the SIP user agent(s) of
corresponding host(s) to request binding of the original
address of the mobile with its current one, and
(b) also sends a INFO message to last MSC for binding the
previous host address to the new one so that a short-lived
tunnel is created for forwarding transient data to the
mobile's location.
v. The corresponding host and the MSC use IP encapsulation (either
within IP [19] or minimal [20]) to forward the TCP information to
the mobile's current location.
The key advantage of this approach is that TCP stays as is; though
the required IP encapsulation reduces the bandwidth efficiency of the
channel.
Since the DHCP interacts with DNS to dynamically update the name to
address and address to name mappings, new TCP connections will be
established using the current address of the mobile. Another
alternative for name to address mapping and vice-versa is that
instead of a dynamic DNS, one develops a new protocol that allows
applications to use SIP registrar for name to address and address to
name mappings. The specifications of this alternative and its
comparison with a dynamic DNS scheme require further study, and is
beyond the scope of this docuement.
4. HMMP on SIP
SIP supports personal mobility function. HMMP builds upon the
personal mobility feature of SIP to enable users to access the
network from any location using their own mobile terminal. The two
main functions of HMMP are registration, and mobility support. The
registration involves assigning new address to a roaming mobile and
authenticating it whenever necessary; while the mobility support
comprises re-invitation, and/or tunneling via address binding. Let us
explain how one can utilize and extend SIP to perform these
functions.
4.1 Registration
SIP REGISTER method allows users to register with the network and
enable them to access the network from any terminal on the network.
HMMP utilizes SIP to register and configure mobile terminals. There
are two ways to use SIP for mobile registration. The first approach
requires no extension/modifications of SIP, while the second requires
certain modifications and extensions of SIP.
ITSUMO Group [Page 16]
Internet-Draft Host Mobility Management Protocol October 1999
4.1.1 Registration: Approach 1
The first registration approach utilizes the dynamic host
configuration protocol (DHCP) [11], and SIP REGISTER and recently
proposed INFO method [12] to perform the registration. It operates
as follows.
+ The mobile station (MS) requests a new address from DHCP.
+ DHCP assigns a temporary address to the MS.
+ The MS uses SIP REGISTER method with its temporary IP address as
CONTACT in the REGISTER method. Note that if this registration is
trigrred by the roaming of the MS in the middle of an ongoing
session (i.e., re-registration), then the visiting registrar (VR)
shall authenticate it with the home registrar (HR).
The signaling flow for the registration is depicted in Figure 6. The
MS broadcasts a DHCPDISCOVER message to the DHCP servers. Several
servers offer a new address to MS via DHCPOFFER; the MS selects one
and sends a DHCPREQUEST to the corresponding DHCP server. The DHCP
server send a DHCPACK to confirm the assignment of the address to the
MS. Simultaneously, the DHCP SHALL update the DNS address to name
and name to address mappings. For instance, the DHCP can use the
Dynamic DNS updates mechanism [RFC 2136] to perform the DNS mapping
update [15]. Figure 6, does not show the DNS update in detail. The
MS sends a SIP REGISTER message whose CONTACT is set to the MS's new
address to the visiting registrar (VR) that contains the service
profile of the MS. The VR uses the SIP INFO method to send MS's
profile to the HR for authentication. The HR responds to the VR with
a SIP OK if authentication is successful, otherwise, HR responds with
a "603 Decline" response. Then, the VR sends a SIP OK to the MS to
confirm its registration with the visiting network. Therefore,
additional requirements for supporting this registration approach are
the followings.
- The DHCP SHALL interact with the DNS and update it dynamically.
- The SIP INFO method SHALL be able to convey the question "Is profile
[....] valid? " to the HR in the method message body.
MS DHCP (several servers) VR HR
| DHCP DISCOVER | | |
|---------------------->| | |
| DHCP OFFER | | |
|<----------------------| | |
| DHCP REQUEST | | |
|---------------------->| | |
| DHCP ACK | DNS Update | |
|<----------------------|------------> | |
| | | |
ITSUMO Group [Page 17]
Internet-Draft Host Mobility Management Protocol October 1999
| SIP REGISTER | | |
|-----------------------|------------------->| |
| | | SIP INFO |
| | |----------------->|
| | | SIP OK |
| | |<-----------------|
| | SIP OK | |
|<----------------------|--------------------| |
| | | |
Figure 6. The signaling flow for the registration: Approach 1
Assuming that the processing time is negligible, the maximum
registration time using this approach equal to sum of the round trip
(MS-DHCP-MS), the round trip (MS-VR-MS), and the round trip (VR-HR-
VR) delays. The first term represents the time it takes to get a new
address, the second and third is the registration time. The
registration time comprises the time for mobile's interaction with
the SIP registrar as well as the time it takes the VR to communicate
with the HR in order to authenticate the mobile.
In order to reduce the impact of roaming on the performance of
interactive real-time services, it is essential to minimize the
registration time of a mobile in a visiting network. As Figure 6
indicates this goal can be achieved through minimizing the mobile
authentication time as well address acquisition time. The mobile
authentication can be expedited through replicating a mobile's
profile in networks that are most likely to be visited by the mobile
[13]. This profile replication reduces the registration time by a
VR-HR-VR round trip, though it increases the control load due to
profile administration, and its effective realization requires
continuous monitoring of user's mobility patterns. An approach that
augments the SIP registrar with DHCP functions and reduces the
address acquisition time is described in Section 4.1.2.
4.1.2 Registration: Approach 2
In a nutshell, this approach equips the SIP registrar with DHCP
functions so that the address acquisition time is reduced.
Realization of this approach requires the modification of SIP
REGISTER method so that if the CONTACT field is set to a default
registration/hand-off (i.e., "RHO") value , the SIP registrar (i.e.,
registration server) shall also ask for a temporary address for the
mobile. The registrars shall be equipped with a DHCP client as well
as shall be co-located with a DHCP server that allows it to assign IP
addresses to the mobiles. This registration algorithm operates as
follows:
ITSUMO Group [Page 18]
Internet-Draft Host Mobility Management Protocol October 1999
+ The mobile uses a SIP REGISTER method with CONTACT = "RHO" to
re-register as well as get it a new address. When the visiting
registrar (VR) receives this message
- the VR assigns a new temporary address to the mobile, i.e., its DHCP
client ask for an address from its DHCP server,
- the VR and HR interact to authenticate the mobile, if the
authentication fails, VR sends a 603 Decline message to the mobile,
otherwise,
* the VR DHCP server updates the DNS, and
* the VR send the temporary address to the mobile in the 200
response as Contact header field.
Assuming negligible processing time, the maximum registration time
equals the sum of the round trip (MS-VR-MS), and round trip round
trip (VR-HR-VR) delays. Like approach 1, a profile replication method
may be used to eliminate the round trip delay (VR-HR-VR) involved in
authentication, and minimize the registration time. The key
advantages of this scheme (compared to approach 1) are that it
a. reduces the address acquistion time becuase the registrar itself
can assign new address, and
b. protects network resources against fraud because the registrar
authenticates the MS before sending the MS its new assigned
address.
The signaling flow of this registration procedure is shown in Figure
7. Note that Figure 7 does not depict DNS update process in detail.
MS VR HR
| | |
| SIP REGISTER | |
| CONTACT="RHO" | |
|------------------------------>| |
| | SIP INFO |
| |------------------------------>|
| | SIP OK |
| |<------------------------------|
| | |
| SIP OK | DNSUpdate |
|<------------------------------|----------> |
| | |
| | |
Figure 7. The signaling flow for registration: Approach 2
The followings are additional requirements for supporting this
registration approach with SIP.
ITSUMO Group [Page 19]
Internet-Draft Host Mobility Management Protocol October 1999
** The SIP REGISTER method SHALL designate a "RHO" CONTACT that allows
the registrar to obtain a new address from the DHCP on behalf of
the mobile.
** The DHCP sever of VR SHALL either update the DNS dynamically or a
new protocol be developed to allow applications to use SIP
registrar for name to address and address to name mappings.
An interesting question is how does the SIP registrar inform the
mobile about its new address? The answer is exactly the way DHCP
does it. The TCP(UDP)/IP software should accept and forward to the IP
layer any IP packets delivered to the mobile's hardware address
before its IP address is configured. The SIP registrar may use the
limited broadcast IP address to force the IP layer to broadcast the
registrar's response on the subnet so that it is delivered to the
mobile's hardware address before the TCP(UDP)/IP software of the
mobile is configured. If mobiles can accept hardware unicast
datagrams before their TCP(UDP)/IP software are configured, the
registrar may use this capability to deliver the mobile's
new/temporary address.
I believe the fact that VR is equipped with DHCP client and server
capabilities is consistent with RFC 2543 requirement that explicitly
states a SIP registrar cannot act as a SIP client. However, this
point should be examined further.
4.2 Mobility Support
The mobility support comprises two functions, i): location service,
i.e., locating mobile users in response to new incoming session
requests, and ii): hand-off, i.e., ensuring soft hand-off as the
mobile user roams across subnets and/or domains. What follows
describes how HMMP uses SIP to support these functions.
4.2.1 Location Service
The mobile has moved to a new location when a corresponding host
initiates a session. In this case, HMMP sets up the session as
follows:
- The corresponding host invites the mobile station (i.e., MS),
- A SIP redirect server (SIP-RS) answers that the mobile is moved to a
new location (i.e., temporary address),
- The corresponding host re-invites the mobile at the temporary
address, and
- a session is set up between the corresponding and mobile hosts, and
the data transfer begins.
Figure 8 depicts the signaling flow for location service.
ITSUMO Group [Page 20]
Internet-Draft Host Mobility Management Protocol October 1999
CH SIP-RS MS
| | |
| SIP INVITE | |
|------------------------------>| |
| 302: Moved Temporarily | |
|<------------------------------| |
| SIP INVITE | |
|-------------------------------|----------------------------->|
| | SIP OK |
|<------------------------------|------------------------------|
| User Data | |
|-------------------------------|----------------------------->|
| | |
Figure 8. The signaling flow for location service
The corresponding host sends a SIP INVITE message to the mobile
station. A redirect server that has intercepted the INVITE message
sends a 302 (i.e., moved temporarily) redirection message to the
corresponding host with the mobile's new/temporary address as its
Contact header field. The corresponding host sends a SIP INVITE
message to the new address, the mobile responds with a SIP OK, and
the data transfer begins. Since the DHCP dynamically updates the DNS
mappings, new TCP connections are established using the most recent
IP address of the mobile.
4.2.2 Hand-off
To ensure soft hand-off, HMMP should re-establish a new session
between the corresponding host and the mobile station (MS) at its new
location, and create a short-lived tunnel for forwarding the
transient data of the session to the mobile station's new location.
When the MS moves to a new location during the session, The MS re-
registers (using either of registration methods described in Section
4.1) and obtains a new address. Then, HMMP provides means of hand-off
as follows:
+ A new session with the same session ID is created between
corresponding host (CH) and the mobile. In order to create a new
session, the MS (or SIP server) re-invites the corresponding host to
the new address of the MS.
+ The MS or SIP server uses the SIP INFO method to create a
short-lived tunnel between the previous MSC and the new MSC to
reduce the loss of session transient data. In order to create the
tunnel
- The MS or SIP server sends an INFO message to the previous MSC
(P-MSC) which is the same as the default gateway of the MS before
getting its new address, and
ITSUMO Group [Page 21]
Internet-Draft Host Mobility Management Protocol October 1999
- binds the old address of the mobile with its new one, so that
transient messages are forwarded to the new address of the MS, and
packet loss is reduced. The expire filed of the INFO method is used
to specify the tunnel lifetime (i.e., a time-out period after which
the tunnel is discontinued). The exact algorithm for determining the
tunnel lifetime requires further study.
+ The MS SIP user agent also sends an INFO message to the SIP user
agent of any corresponding host whose address is in the MS's SIP-EYE
record of ongoing TCP connections so that each corresponding host
binds the original IP address of the MS to its current (i.e., new)
IP address.
Note that the P-MSC uses IP encapsulation [19, 20] to create a tunnel
for forwarding the transient packets to the mobile's new location.
The key requirement for the realization of the tunneling process is
that each MSC SHALL have a SIP user agent. The signaling flow for
hand-off is shown in Figure 9.
MS has already registered as shown in Figures 6 or 7.
MS CH P-MSC
| | |
| SIP INVITE | |
|-------------------------------->| |
| | SIP INFO |
|---------------------------------|----------------------------->|
| SIP INFO | |
|-------------------------------->| |
| SIP OK | |
|<--------------------------------| |
| | SIP OK |
|<--------------------------------|------------------------------|
| User Data | |
|-------------------------------->| |
| | |
Figure 9. The signaling flow for hand-off
It is worth noting that Figure 9 shows an instance of the signaling
flow for hand-off. The exact sequence of SIP OK responses from the
P-MSC and CH SIP user agent to the MS SIP user agent depends on the
round trip delay between these entities as well as the network
traffic these messages encounter as they traverse the network. In
summary, additional requirements for supporting hand-off are the
following.
- The SIP user agent SHALL be equipped with a SIP_EYE agent that
tracks TCP connections in the MS. - The SIP_EYE agent SHALL
maintain a state comprising the <original MS
ITSUMO Group [Page 22]
Internet-Draft Host Mobility Management Protocol October 1999
IP address, previous MS IP address, current MS IP address, original
corresponding host IP address> per TCP connection within the SIP
user agent of the MS. - The SIP user agent SHALL keep the address
of the last default
gateway (i.e., previous MSC) before hand-off). - The SIP user
agent SHALL understand address binding INFO messages
and take necessary actions. - The SIP INFO method SHALL support
address bindings, i.e., understand
a "Bind [address 1] to [address 2] " instruction in the method
message body.
5. The SIP_EYE Agent
The whole premise of the SIP_EYE agent is to ensure that HMMP
supports TCP as is without any modifications to TCP. SIP_EYE SHALL be
a simple TCP tacking/monitoring agent with small footprint residing
within the SIP user agents of mobile stations (MSs) and corresponding
hosts (CHs). Its functions are to
a) identify and track ongoing TCP connections of a mobile station, and
b) maintain a list of ongoing TCP connection identifiersand their
respective corresponding hosts so that the SIP user agent of the
mobile sends them INFO messages to bind the original IP address of
the mobile with its current one.
The SIP_EYE agent tracks both the transmitted and received TCP
packets concurrently to create and update the list of ongoing TCP
connections in the MS. It runs two concurrent monitoring and updating
processes, one for tracks the transmitted packets, and the other
received ones. The role of SIP_EYE in hand-off of TCP connections has
already been discussed in detail. The following pseudo-code describes
the basic TCP tracking operation of the SIP_EYE agent for the
simplest case.
// SA: Source address of a packet.
// DA: Destination address of a packet.
// SYN: Synchronization code bit
// ACKB: Acknowledgment code bit
// FIN: Sender end of byte stream code bit
// SEQ: Sequence number
// ACKN: Acknowledgement number
// Auxiliary variables
// CL_ID: Connection Label ID
// STAT: Connection Status
// STATUS takes values, Setup_Req, Setup_Prog, Established,
// Release_Req, Release Ack, Release Accpet, Disconnect)
ITSUMO Group [Page 23]
Internet-Draft Host Mobility Management Protocol October 1999
//
// The TX SIP_EYE Entity.
for (;;) {
Capture the header of transmitted TCP packets;
if (SYN = 1 & ACKB = 0) {
Add a TCP entry as follows to the temporary list of connections
< original MS IP address = SA;
previous MS IP address = SA;
current MS IP address = SA;
original corresponding IP address = DA;
CL_ID = SEQ;
STAT = Setup_Req; >
}
else if (ACKB = 1 & SYN =0) {
Get the STAT of the TCP entry,
< original MS IP address = SA;
previous MS IP address = SA;
current MS IP address = SA;
original corresponding IP address = DA;
CL_ID = ACKN-1;
STAT = **; >
if ( STAT = Setup Prog ) Set STAT = Established;
// A TCP connection is added to the table of ongoing connections.
if else (STAT = Release_Ack) {
Set STAT = Disconnect;
Remove the TCP entry from the table of ongoing connections.
}
else
Error!;
}
else if { ACKB =1 & FIN = 1 ) {
Reset the CL_ID and STAT of the ongoing TCP entry,
< original MS IP address = SA;
previous MS IP address = previous MS IP address;
current MS IP address = current IP address of the mobile;
original corresponding IP address = DA;
CL_ID = ** ;
STAT = Established; >
to
CL_ID = SEQ;
STAT = Release_Req;
}
}
ITSUMO Group [Page 24]
Internet-Draft Host Mobility Management Protocol October 1999
// The RX SIP_EYE Entity. It is similar to TX entity and they
// both run concurrently to manage a single TCP connection list.
for(;;) {
Capture the header of received TCP packets;
if (SYN = 1 & ACKB = 1) {
Reset the STAT of the TCP entry ;
< original MS IP address = DA;
previous MS IP address = DA;
current MS IP address = DA;
original corresponding IP address = SA;
CL_ID = ACKN-1;
STAT = Setup_Req; >
to
STAT = Setup_prog;
}
else if (SYN = 0 & ACKB =1) {
Reset the STAT of TCP_entry;
< original MS IP address = DA;
previous MS IP address = DA;
current MS IP address = DA;
original corresponding IP address = SA;
CL_ID = ACKN-1;
STAT = Release_Req; >
to
STAT = Release_Ack;
}
else if { ACKB =1 & FIN = 1) {
Reset the STAT of TCP entry
< original MS IP address = DA;
previous MS IP address = previous MS IP address;
current MS IP address = current IP address of the mobile;
original corresponding IP address = SA;
CL_ID = ACKN-1;
STAT = Release_Ack; >
to
STAT = Release_ACK;
}
}
// Update of ongoing TCP connection list upon hand-off.
// new MS IP address: The new address that has been assigned to the
// mobile upon hand-off.
if (hand-off) {
while (!eof ongoing list) {
< original MS IP address = original MS IP address;
ITSUMO Group [Page 25]
Internet-Draft Host Mobility Management Protocol October 1999
previous MS IP address = current MS IP address;
current MS IP address = new MS IP address;
original corresponding IP address = original corresponding IP address;
CL_ID = **;
STAT = Established;
}
The preceding pseudo-code describes the basic operation of SIP_EYE in
an environment whose packet error or loss ratio is negligible and no
connection set-up message of TCP is lost or corrupted. It shall be
refined further so that it becomes robust enough for use in a
wireless environment that has relatively (compared to wireline
networks) high packt loss and error and TCP set up messages may be
lost or corrupted. Furthermore, the interactions of the SIP_EYE
agent with the entities of current SIP user agent as well as its
integration within the SIP user agent require further study.
6. Impact of Mobility on SIP Specifications
Having described HMMP, let us summarize requirements for supporting
mobility on SIP via HMMP or other protocols. The requirements are the
following.
** The SIP INFO method SHALL be able to convey the question, "Is the
profile [....] valid? ", to the HR in the message body of INFO
method.
** The SIP INFO method SHALL support address bindings, i.e.,
understand a "Bind [address 1] to [address 2] " instruction in the
message body of the INFO method.
** The SIP REGISTER method SHALL designate a "RHO" CONTACT that
allows the registrar to obtain a new address from the DHCP on
behalf of the mobile.
** The SIP user agent SHALL be equipped with a SIP_EYE agent that
tracks TCP connection.
** The SIP_EYE agent SHALL maintain a state comprising the <original
MS IP address, previous MS IP address, current MS IP
address, original corresponding IP address> per TCP connection.
** The SIP user agent SHALL keep the address of the last default
gateway (i.e., previous MSC) before hand-off).
** The SIP user agent SHALL understand address binding INFO messages
and take necessary actions.
** The DHCP sever of VR SHALL either update the DNS dynamically or a
new protocol be developed to allow applications to use SIP
registrar for name to address and address to name mappings.
Except for the interaction between DHCP and DNS, SIP specifications
SHALL support other functions/requirements so that SIP can support
ITSUMO Group [Page 26]
Internet-Draft Host Mobility Management Protocol October 1999
signaling needs of roaming users in 3G-IP networks.
7. Summary and Open Issues
This document has presented the preliminary specifications of HMMP,
and identified the impact of mobility on SIP and proposed necessary
extensions to ensure that SIP can support roaming users adequately.
HMMP is a protocol that supports real-time and non-real-time
multimedia applications on mobile terminals of 3G-IP networks. HMMP
utilizes as well as extends session initiation protocol (SIP) to
provide means of domain hand-off (i.e., roaming), and subnet-off
(i.e., macro mobility) so that users can access the network from any
location using their own mobile terminal. HMMP can spoof constant
endpoints for mobile TCP connections and supports mobile TCP
applications without any changes to the TCP. Among the open issues
that may influence SIP specifications and require further study are:
-- the specifications of a resource reservation mechanism for
supporting real-time multimedia applications of roaming users in a
3G-IP network whose signaling system is built on SIP,
-- the extension of the SIP_EYE specifications so that it is able
to account for error in and loss of the TCP connection set-up
packets, and to interact and co-operate with the current SIP user
agent as defined in RFC 2543,
-- the specifications of AAA entity, and
-- interworking with the PSTN.
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).
(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.
9. References
1. D. Barboza, "Motorola and Sun to Build Joint System for Net
ITSUMO Group [Page 27]
Internet-Draft Host Mobility Management Protocol October 1999
Access", The New York Times, June 10, 1999.
2. Cnnfn Industry Watch, "NOKIA: Industry leaders for focus group to
promote third generation wireless IP Technology", June 11, 1999.
3. Telcordia Technologies, "Voice Over Packet in Next Generation
Networks: An Architectural Framework", Bellcore SR-4717, Issue1,
January 1999.
4. ITU-R Rec. M.687-2, "International Mobile Telecommunications-2000
(IMT-2000)", 1997.
5. ITU-R Rec. M.817, "International Mobile Telecommunications-2000
(IMT-2000)", Network Architectures", 1992.
6. ITSUMO Group, "Evolution of Wireless Telephony towards Voice over
3G-IP", 3GPP2- P00-19990824-010, August 23, 1999.
7. ITSUMO Group, "A Service Profile for 3G-IP Wireless Networks",
3GPP2-P00-19990927-009, September 27, 1999.
8. ITU-R Rec. M.816-1, "Framework for Services Supported on
International Mobile Telecommunications-2000 (IMT-2000)", 1992.
9. IETF, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
10. IETF, "SDP: Session Description Protocol", RFC 2327, April 1998.
11. IETF, "Dynamic Host Reconfiguration Protocol", RFC 2131, March
1997.
12. S. Donavon, "The SIP INFO Method",
<draft-ietf-mmusic-sip-info-method-01.txt>, work in progress,
June 1999.
13. D. Lam, Y. Cui, D.C. Cox, and J. Widom, "A Location Management
Technique To Support Lifelong Numbering in Personal
Communications", January 1998.
14. A. McAuley, S. Das, and S. Baba, Y. Shobatake, "Dynamic
Registration and Configuration Protocol for Mobile Hosts",
<draft-itsumo-drcp-00.txt>, work in progresss, October 1999.
15. Y. Rekhter, and M. Stapp, "Interaction between DHCP and DNS",
<draft-ietf-dhc-dhcp-dns-10.txt>, work in progress, June 1999.
ITSUMO Group [Page 28]
Internet-Draft Host Mobility Management Protocol October 1999
16. E. Wedlund, and H. Schulzrinne, "Mobility Support using SIP", ACM
Multimedia Workshop, Seattle, August 1999.
17. IETF, "IP Mobility Support", RFC 2002, October 1996.
18. C. Perkins, and D. B. Johnson, "Route Optimization in Mobile IP",
<draft-ietf-mobileip-optim-08.txt>, February 25, 1999.
19. IETF, "IP Encapsulation within IP", RFC 2003, October 1996.
20. IETF, "Minimal Encapsulation within IP", RFC 2004, October 1996.
21. IETF, "Resource reSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
22. DCS Group, "Integration of Resource Management and Call
Signaling for IP Telephony", <draft-dcsgroup-mmusic-resoure
-00.txt>, work in progress, August 1999.
10. Authors' Addresses
Faramak Vakil
farm@research.telcordia.com
Telcordia Technologies, Rm 1C-135B,
445 South Street, Morristown, NJ 07960-6438.
Ashutosh Dutta,
adutta@research.telcordia.com
Telcordia Technologies, Rm 1B-217B
445 South Street, Morristown, NJ 07960-6438.
Jyh-Cheng Chen,
jcchen@research.telcordia.com
Telcordia Technologies, Rm 1G-236B,
445 South Street, Morristown, NJ 07960-6438.
Shinichi Baba
sbaba@tari.toshiba.com
Toshiba Research America Inc. (TARI)
P. O. Box 136
Convent Station, NJ 07961-0136
Yasuro Shobatake
yasuro.shobatake@toshiba.co.jp
Toshiba Research America Inc. (TARI)
P. O. Box 136
Convent Station, NJ 07961-0136
ITSUMO Group [Page 29]
| PAFTECH AB 2003-2026 | 2026-04-23 20:18:03 |